Archive for July, 2009
ASM的争论
Thursday, July 30th, 2009
今天下午部门里的几个达人针对ASM发生了激烈的争论，其实观点上大同小异，只是表达上理解的有点偏差
ASM实例其实就是一个LVM，负责对OS一级磁盘的管理，这里把磁盘说成lun更准确点，因为磁盘容易让人理解
为最底层的存储上的铁疙瘩，而ASM只会认识LUN，至于这个LUN下面由多少个小盘组成，怎么做stripe是不关心的，
在这点上几位大牛的观点是一致的，但还是吵了半天
ASM完成的是一个翻译工作，他本身并不负责到LUN上获取数据来返回给oracle用户进程，因为要这么操作的话，
ASM必须针对前面的oracle进程，建立对应的服务进程来服务，而ASM实例启动后，进程数量不会发生大的数量，
如果是以这么少的进程服务于前台所有的IO请求，肯定会成为瓶颈，通过实际的fuser观察，用户进程查询时，
也是自己的进程关联上/dev下的设备，在这个过程中，ASM会将oracle请求的文件号，块号翻译成他所管理的LUN
上的对应地址，转交给oracle用户进程，用户拿了这些地址，再去LUN上做IO请求，这些请求如何到达最末端的
真实磁盘，oracle不关心，也管不着
最后一个问题，既然是由oracle进程自己去请求这些数据块，那ASM的访问就应该是串行的，因为一个进程同时只能做一个
事情，这点上我觉得应该还是并行访问，因为用户进程可以批量的发送IO请求，不会等待这个IO完成了，再发送下一个IO，
一批IO下去，各个磁盘自觉认领，我等你们大家的结果就可以了，最后返回给上层，继续发IO请求，周而复始
oracle asm lib中使用multipath的陷井
Friday, July 24th, 2009
今天，查看一个数据库时，发现这个数据库没有使用到powerpath提供的多路径盘上。
这个数据库使用EMC的存储，操作系统是Linux，使用了asm lib包。
查看/dev/oracleasm/disks下的盘时：
#cd /dev/oracleasm/disks
#ls -l
admin@dbrac1:/dev/oracleasm/disks>ls -l
total 0
brw-rw—- 1 oracle dba 65, 17 Jun 18 16:44 ASM_VOL1
brw-rw—- 1 oracle dba 65, 1 Jun 18 16:44 ASM_VOL10
brw-rw—- 1 oracle dba 65, 33 Jun 18 16:44 ASM_VOL11
brw-rw—- 1 oracle dba 8, 113 Jun 18 16:44 ASM_VOL12
brw-rw—- 1 oracle dba 8, 225 Jun 18 16:44 ASM_VOL13
brw-rw—- 1 oracle dba 8, [...]
Oracle11g Direct NFS 测试
Friday, July 24th, 2009
这几天测试了一下oracle11g Direct NFS 的功能，发现ORACLE Direct NFS是通过建立多个到NFS Server的TCP连接来提高IO的并发能力的。前面，我们提过，NFS的IO能力不高的原因是，NFS client端到NFS Server的操作是串行的，正常的NFS client到NFS Server端只建立一个连接，而且只有等前一个请求处理完成后，后一个请求才能处理，这样在随机读IO上就上不去。而Oracle Directd NFS与NFS Server建立多个TCP连接，处理就可以并发进行了，这样从理论上说就可以大大提高NFS的性能。
而在实际发现Direct NFS读的时候很快，实测到达到了400Mbytes/s，基本没有发现瓶颈，但写的时候，发现比较慢，
insert数据时，写流量只有3.4Mbytes/s左右，写为何这么慢原因不明，估计是Linux的NFS Server与Oracle Direct NFS配合不好导致。
当使用rman备份时，如果备份的路径在Direct NFS指定的路径中时，也会自动走到Direct NFS模式下。
测试过程：
先修改odm库，启动支持Direct nfs的odm库：
[oracle@nfs_client lib]$ ls -l *odm*
-rw-r–r– 1 oracle oinstall 54764 Sep 11 2008 libnfsodm11.so
lrwxrwxrwx 1 oracle oinstall 12 Jul 8 18:55 libodm11.so -> libodmd11.so
-rw-r–r– 1 oracle oinstall 12755 Sep 11 2008 libodmd11.so
[oracle@nfs_client lib]$ rm libodm11.so
[oracle@nfs_client lib]$ ln [...]
NFS随机IOPS性能不高的分析(Editor:osdba)
Tuesday, July 7th, 2009
最近做FS3，一直对nfs的随机IOPS性能不高所困扰，所以细细分析了nfs的运行机制：
NFS做数据传输是通过RPC调用来完成了。RPC调用的特点为，发起调用的进程会等待服务器端完成调用，在服务器端完成调用之前，
发起调用的进程是会一直被阻塞的。
同时对于NFS来说，一个nfs client端到一个nfs Server端只会建立一个连接。nfs服务请求的处理过程是，只有上一个请求处理完成后，
才能处理下一个请求。所以处理过程是串行的，而不是并发的，这就导致了NFS处理随机IO能力不高。例如：
目前SAS硬盘的随机读写的寻道时间大约为4-5ms，所以当把这样的多块硬盘做成一个raid0，单个IO的响应时间也不会低于4ms，
由于NFS处理是串行的，所以这时读IOPS最多只能达到1000ms/4ms每个＝250 IOPS。对于本地的raid磁盘组，虽然单个IO的响应时间为4ms，但由于是可以并发处理的，
也就是说，多个IO是同时发到各个硬盘上去的，这样总体的IOPS会很高，而对于NFS时，由于NFS处理是串行的，所以其IOPS不会因raid而更高。
另，由于很多NFS Server对于写操作，不必等真正写到磁盘中去时，才返回，所以写IOPS可以远远高于读IOPS。
结论：NFS的读IOPS与单个随机读IO的响应时间成反比，响应时间越短，读IOPS越高。所以ssd盘做nfs的IOPS大大高于普通硬盘的IOPS。
《MySQL性能调优与架构设计》最新勘误
Monday, July 6th, 2009
推荐序二
“当年加入淘宝的毕业生成了淘宝开发 DBA 的主管,他就是本书的作者” -> “当年加入淘宝的毕业生成了淘宝开发DBA的主管，而当年加入阿里巴巴B2B的毕业生，就是本书的作者”
P90
“假设 id 为 100″ -> “假设 id 为 1″
“取出前20个” -> “取出第100至120个”
“通过调用存储引擎借口来获取” -> “通过调用存储引擎接口来获取”
P91
代码 6-4 的解决方案一中 “LIMIT” 之前增加 “ORDER BY gmt_create desc”， 也就是在 P91 的第2行和第3行之间插入1行：ORDER BY gmt_create DESC
P112
最后一行的 “quuery” -> “query”
P117
“尽两减少大的复杂 Query” -> “尽量减少大的复杂 Query”
P152
“不仅 user_group 表的访问从 ref 变成了 ALL” -> “不仅 group_message_content 表的访问从 ref 变成了 ALL”
P167
代码 8-31 替换成如下：
sky@localhost : example 03:12:45> [...]
11G real time query
Friday, July 3rd, 2009
11G standby提供了real time query的功能，通过这个功能，我们可以结合lgwr+async来做到实时standby查询，
给我们做读写分离提供了遐想空间，最近和老郑测试了下这个功能的实时性，希望对大家有所帮助
测试环境：
redhat linux as 4.7(64bit)
11.1.0.7.0 lgwr + async 20480 + real time query
主库：10组512M的联机日志
备库：11组512M的standby logfile
测试方法：
循环插入记录，为了增大日志量，起了6个进程，插入test1-test6
declare v_counter pls_integer := 0;
begin
for i in 1..100000000 loop
insert into $1 (id,mdate,mm) values(i,sysdate,’wo shi ni ba’);
v_counter := v_counter + 1;
if v_counter = 10 then
commit;
v_counter := 0;
end if;
end loop;
end;
/
以表test1为参考，每隔1秒查询主库和备库的最大ID，还有插入的时间，如果是完全实时，这两个数值应该相等，
通过两边的max(id)和maxid对应的时间，可以看出real time query的延迟，采样结果保存于rquery_time表
测试的日志量大家可以自己加压设置，本次测试日志量是37M/S,让我有点吃惊，但多次statspack统计的结果和日志切换的频率计算，
就是如此
Load Profile Per [...]
