应用DBA的价值
有16人发表了评论 | 赶紧发表评论吧 | 作者：grassbell
关于应用DBA的价值 和对团队的贡献，前几天在一个小范围作了个讨论，以下是我做的一个整理（70%引自大师）：
产品DBA和应用DBA不过是阿里巴巴DBA在成长路线上的两种方式。因为我们以前都是纵向的在技能方面深入，所以最近两年比较强调横向的东西。横向的协调、沟通、推动，远比一个人去学习技能困难的多，而这种能力实际上是可以放到更多的环境中去施展的。技能却只能在这一个领域。主机、os、存储，相信以大家的悟性，1-2年经历足够让你觉得够没劲！
应用dba在当前更关注具体业务，所以涉及的范围也和具体业务部门相关。产品dba已经做到标准化，所以他们的职能是如何进一步提高所有数据库的管理效率。从长远看，应用dba不应该局限于简单的sql优化、项目跟进 甚至数据订正，更应该站在应用的角度思考数据存放和读取的问题。Cobar是一个典型的例子，这应该是应用dba今后需要关注和发展的方向。Db今后的线性扩展和高可用方案，不可能只依赖于db本身的功能，更应该依赖应用架构本身解决这些问题。所以今后应用dba应该和架构部门密切合作，不断创造和发展这样的架构模型，真正解决数据库面临的问题，这也是对团队最大的贡献。
如何让团队在公司发挥重要作用，重要的是影响其他部门，让更多的部门收益，这样dba team才能在公司赢得尊重。记得上次半年奖项评选，有个部门的头居然不推荐自己团队的人，而是要跨部门推荐DBA，这件事情未获得andy的许可，因为这个结果会给其团队的人巨大的打击，老大不认可自己部门的人认可其他部门的人！但是在这个事情的现场我是很感激团队兄弟的努力，能让dba team赢得别人的尊重和认可。 而这些事情，基本主要都是应用dba贡献的价值。
所以实际上，应用dba的价值体现在整个团队对外展现，产品dba或者技能方面提高的dba是练内功影响自己的团队更多一些。 但你要说哪个价值大或者哪个困难，不同阶段答案是不一样的。看当时哪个是短板！但你可以去学习技能提高，而技能高的人却未必能做好你的事情，比如唐牛或者范鑫，他们要做应用DBA的事情，技能再强，恐怕也很难做的好，因为他们有自身的缺点，让他们做现在的事情主要目的是扬长避短，发挥自己的价值。如果某一日你真的觉得技能才是你唯一的方向，那也没关系，人生的轨道又不是死的，主管会充分考虑每个人的需求，结合整个团队来认真划分角色。所以在这个事情发生之前，做好的你手头的工作，再做的更好一些，最受益的是你自己！
11G real time query,BUG不是一般的多
有7人发表了评论 | 赶紧发表评论吧 | 作者：八神
sys@CRMG> desc b
Name Null? Type
———————————————————————————– ——– ——————————————————–
A DATE
C
–备库：
@> desc b
Name Null? Type
———————————————————————————– ——– ——————————————————–
A DATE
C DATE
sys@CRMG>rename b to c;
Name Null? Type
———————————————————————————– ——– ——————————————————–
A DATE
C
sys@CRMG> insert into c select sysdate,sysdate from user_objects;
–备库：
@>desc c;
Name Null? Type
———————————————————————————– ——– ——————————————————–
A DATE
C DATE
Name Null? Type
———————————————————————————– ——– ——————————————————–
A DATE
C
@>select count(*) from c;
———-
8606
@>select count(*) from b;
———-
8606
@>SELECT OBJECT_NAME,object_id,data_object_id from user_objects where object_name IN (’C',’B');
———- ———- ————–
C 16799 16799
@>alter system flush SHARED_POOL;
@>select count(*) from b;
select count(*) from b
*
ERROR at line 1:
ORA-00942: table or view does not exist
@>
ASM使用AIX raw disk的问题
有7人发表了评论 | 赶紧发表评论吧 | 作者：八神
同事在10G DOCS上看到，AIX下如果绕过VG，直接使用裸盘做ASM，当设备的PVID变化时，会引起磁盘组数据丢失
今天晚上做了测试
首先清除掉了hdiskpowerx上的pvid,发现再启动ASM的时候，mount dg出错了，
–清除pvid,lspv显示pvid为none
root@crmg_pri:/>chdev -l hdiskpower12 -a pv=clear
hdiskpower12 changed
root@crmg_pri:/>chdev -l hdiskpower13 -a pv=clear
hdiskpower13 changed
root@crmg_pri:/>chdev -l hdiskpower14 -a pv=clear
hdiskpower14 changed
root@crmg_pri:/>chdev -l hdiskpower15 -a pv=clear
hdiskpower15 changed
–mount diskgroup，报错磁盘不足，盘头信息已经不对了
@>alter diskgroup dg1 mount;
alter diskgroup dg1 mount
*
ERROR at line 1:
ORA-15032: not all alterations performed
ORA-15063: ASM discovered an insufficient number of disks for diskgroup “DG1″
–查看磁盘头状态，为PROVISIONED
@>select state,mode_status,mount_status,header_status from v$asm_disk;
STATE MODE_STATUS MOUNT_STATUS HEADER_STATUS
—————- ————– ————– ————————
NORMAL ONLINE CLOSED PROVISIONED
NORMAL ONLINE CLOSED PROVISIONED
NORMAL ONLINE CLOSED PROVISIONED
NORMAL ONLINE CLOSED PROVISIONED
NORMAL ONLINE CLOSED PROVISIONED
NORMAL ONLINE CLOSED PROVISIONED
NORMAL ONLINE CLOSED PROVISIONED
NORMAL ONLINE CLOSED PROVISIONED
NORMAL ONLINE CLOSED PROVISIONED
NORMAL ONLINE CLOSED CANDIDATE
NORMAL ONLINE CLOSED PROVISIONED
NORMAL ONLINE CLOSED PROVISIONED
NORMAL ONLINE CLOSED PROVISIONED
NORMAL ONLINE CLOSED PROVISIONED
NORMAL ONLINE CLOSED PROVISIONED
NORMAL ONLINE CLOSED PROVISIONED
NORMAL ONLINE CLOSED PROVISIONED
NORMAL ONLINE CLOSED PROVISIONED
NORMAL ONLINE CLOSED PROVISIONED
NORMAL ONLINE CLOSED PROVISIONED
NORMAL ONLINE CLOSED CANDIDATE
NORMAL ONLINE CLOSED PROVISIONED
这个状态的官方解释：
PROVISIONED - Disk is not part of a disk group and may be added to a disk group with the ALTER DISKGROUP statement.
The PROVISIONED header status is different from the CANDIDATE header status in that PROVISIONED implies
that an additional platform-specific action has been taken by an administrator to
make the disk available for Automatic Storage Management.
意思是现在这个盘，是完全可以作为全新的盘加入到DG的，也就是说ASM已经不认识上面的数据了，只能重用，上面的数据也就丢失了
前面是PVID从有到无的过程，下面再验证下PVID从无到有的过程，先将所有的power lun的PVID清除掉，并创建了DG，可以正常mount
然后给PV生成新的pvid
chdev -l hdiskpower13 -a pv=yes
…
…
–mount出错
@>alter diskgroup dg1 mount;
alter diskgroup dg1 mount
*
ERROR at line 1:
ORA-15032: not all alterations performed
ORA-15040: diskgroup is incomplete
ORA-15042: ASM disk “4″ is missing
–ASM disk状态已经改变
@>select state,mode_status,mount_status,header_status from v$asm_disk;
STATE MODE_STATUS MOUNT_STATUS HEADER_STATUS
—————- ————– ————– ————————
NORMAL ONLINE CLOSED MEMBER
NORMAL ONLINE CLOSED MEMBER
NORMAL ONLINE CLOSED MEMBER
NORMAL ONLINE CLOSED CANDIDATE
NORMAL ONLINE CLOSED MEMBER
NORMAL ONLINE CLOSED MEMBER
NORMAL ONLINE CLOSED MEMBER
NORMAL ONLINE CLOSED MEMBER
NORMAL ONLINE CLOSED MEMBER
NORMAL ONLINE CLOSED CANDIDATE
NORMAL ONLINE CLOSED MEMBER
NORMAL ONLINE CLOSED MEMBER
NORMAL ONLINE CLOSED MEMBER
NORMAL ONLINE CLOSED MEMBER
NORMAL ONLINE CLOSED MEMBER
NORMAL ONLINE CLOSED MEMBER
NORMAL ONLINE CLOSED MEMBER
NORMAL ONLINE CLOSED MEMBER
NORMAL ONLINE CLOSED MEMBER
NORMAL ONLINE CLOSED MEMBER
NORMAL ONLINE CLOSED CANDIDATE
NORMAL ONLINE CLOSED MEMBER
磁盘组数据仍然丢失了
可以看出，在AIX上，直接使用rhdisk,或者rpowerdisk来创建ASM后，一旦PVID有变化，ASM的数据都会丢失的，除非事先已经备份好
每个ASM磁盘头的信息，否则修复起来是很困难的，这个是使用AIX raw disk+ASM要注意的
但文档中说的ASM的格式化会破坏磁盘的PVID，当OS重启时，会从ODM库将PVID同步回磁盘，反过来会破坏掉ASM，这个情况经过测试，没有出现
也许是因为上面的测试是在11G里面做的
关于PVID
PVID是用于标识physical volumn的一个标识符，有主板序列+时间戳组成，他的本意是做到这个号码在世界上是唯一的，PVID存在于3个地方，
物理卷的磁盘头
VGDA（如果没做VG，这部分就不存在）
ODM库
PVID最初的源头是在物理磁盘头上，后面两个都是从这里读取的，所以一个LUN如果共享给多个主机使用，每台主机看到的pvid都是一样的
一般在做VG或者手工chdev -l 时，会给盘付上pvid,理论上，上面3个地方的PVID应该是高度一致的，如果人为强行破坏，可能引起数据丢失，
比如VGDA的PVID与磁盘头的PVID信息不一致时，会导致VG不能varyon和import
也有人通过DD的方式手工修改PVID，这些动作都是非常危险的
另外请参考：Doc ID: 750016.1
ASM的争论
有3人发表了评论 | 赶紧发表评论吧 | 作者：八神
今天下午部门里的几个达人针对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的陷井
有5人发表了评论 | 赶紧发表评论吧 | 作者：osdba
今天，查看一个数据库时，发现这个数据库没有使用到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, 129 Jun 18 16:44 ASM_VOL14
brw-rw—- 1 oracle dba 8, 81 Jun 18 16:44 ASM_VOL15
#cd /dev
#ls -l |grep “65, ”
admin@dbrac1:/dev>ls -l |grep “65, ”
brw-r—– 1 root disk 65, 0 Jun 19 00:42 sdq
brw-r—– 1 root disk 65, 1 Jun 18 16:44 sdq1
brw-r—– 1 root disk 65, 16 Jun 19 00:42 sdr
brw-r—– 1 root disk 65, 17 Jun 18 16:43 sdr1
发现/dev/oracleasm/disks下面的盘居然不是对应到/dev/emcpowerXX盘，
由此基本确定了asm lib没有使用多路径的盘，原先创建asm disk明明是使用
/dev/emcpower盘建立的:
/usr/sbin/asmtool -C -l /dev/oracleasm -n ASM_VOL1 -s /dev/emcpowera1
现在为何不是了?
通过分析asm lib的原理，基本清楚原因是这样的：
asm lib包只是对盘起一个名字，如“ASM_VOL1″，然后把这个名字存入磁盘的内容的头部。
下次机器自动启动时，会自动运行/etc/rc.d/init.d/oracleasm start，这时会自动扫描硬盘，
扫描过程中，是会读前面我们写入名称，由于使用了多路径，那么在/dev/下会有几个设备名对
应着同一个硬盘，其中/dev/sdXX的是各个路径盘，/dev/emcpowerXX是把这些路径合并了一个
盘，正常情况下我们都会要求asmlib使用/dev/emcpowerXX盘，但asm lib的扫描规则是使用最先扫描到的盘，
后面再扫描到的设备，只要上面的名称与前面相同，就使用前面的设备名，不管再次扫描到的了。
而一般情况下，asm lib都会先扫描到/dev/sdXX盘，而不是/dev/emcpowerXX的盘，由此导致了
此问题的发生。
其实oracle的官方网站也说了此问题：
http://www.oracle.com/technology/tech/linux/asmlib/multipath.html
解决方法就是修改配置文件中asm lib的扫描顺序，在/etc/sysconfig/oracleasm中配置如下内容：
ORACLEASM_SCANORDER=”emc sd”
这样扫描时会先扫描/dev/下emc开头的文件，然后才会是/dev下sd开头的文件。
这个问题很隐蔽，在安装asm lib时，没有任何地方提示需要配置这个扫描顺序，
当用/usr/sbin/asmtool -C -l /dev/oracleasm -n ASM_VOL1 -s /dev/emcpowera1建asm lib盘时，
也会正确建立在多路径盘上，但当机器重新启动后，asm lib重新扫描磁盘时，就会扫到错误的盘上。
Oracle11g Direct NFS 测试
有1人发表了评论 | 赶紧发表评论吧 | 作者：osdba
这几天测试了一下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 -s libnfsodm11.so libodm11.so
在nfs server机器中共享一个目录，为了使用硬盘不会成为IO瓶颈，使用8块盘做一个raid0，然后做ext3文件系统，做为nfs Server的输出：
mdadm -C /dev/md0 –level raid0 -c 8 -n 8 /dev/sdb /dev/sdc /dev/sdd /dev/sde /dev/sdf /dev/sdg /dev/sdh /dev/sdi
mkfs -t ext3 /dev/md0
mount /dev/md0 /nfs
然后在/etc/exportfs中配置：
/nfs 192.168.172.132(rw,no_root_squash,insecure)
service nfs restart
在数据库主机上(nfs client端）：
[oracle@nfs_client dbs]$ cat oranfstab
server: node_data1
path: 192.168.172.128
export: /nfs mount: /opt/oracle/oradata/nfs
mount -t nfs 192.168.172.128:/nfs /opt/oracle/oradata/nfs
两台机器通过万兆网卡连接，测试过网络速度可以达到800Mbytes/s以上。
建一个数据库：
CREATE DATABASE oratest
USER SYS IDENTIFIED BY sys
USER SYSTEM IDENTIFIED BY system
CONTROLFILE REUSE
LOGFILE GROUP 1 (’/opt/oracle/oradata/oratest/redo_1_1.log’) SIZE 200M REUSE,
GROUP 2 (’/opt/oracle/oradata/oratest/redo_2_1.log’) SIZE 200M REUSE,
GROUP 3 (’/opt/oracle/oradata/oratest/redo_3_1.log’) SIZE 200M REUSE,
GROUP 4 (’/opt/oracle/oradata/oratest/redo_4_1.log’) SIZE 200M REUSE,
GROUP 5 (’/opt/oracle/oradata/oratest/redo_5_1.log’) SIZE 200M REUSE
MAXLOGFILES 20
MAXLOGMEMBERS 5
MAXLOGHISTORY 1000
MAXDATAFILES 1000
MAXINSTANCES 2
noARCHIVELOG
CHARACTER SET US7ASCII
NATIONAL CHARACTER SET AL16UTF16
DATAFILE ‘/opt/oracle/oradata/oratest/system01.dbf’ SIZE 2046M REUSE
SYSAUX DATAFILE ‘/opt/oracle/oradata/oratest/sysaux01.dbf’ SIZE 2046M REUSE
EXTENT MANAGEMENT LOCAL
DEFAULT TEMPORARY TABLESPACE temp
TEMPFILE ‘/opt/oracle/oradata/oratest/temp01.dbf’ SIZE 2046M REUSE
UNDO TABLESPACE undotbs1
DATAFILE ‘/opt/oracle/oradata/oratest/undotbs01.dbf’ SIZE 2046M REUSE
SET TIME_ZONE = ‘+08:00′;
再建一个表空间tbs_testd在在nfs上：
create tablespace tbs_test datafile ‘/opt/oracle/oradata/nfs/test01.dbf’ size 2047M;
SQL> col svrname format a40
SQL> col dirname format a40
SQL> set linesize 200
SQL> select * from v$dnfs_servers;
ID SVRNAME DIRNAME MNTPORT NFSPORT WTMAX RTMAX
———- —————————————- —————————————- ———- ———- ———- ———-
1 nfs_server /nfs 907 2049 32768 32768
1 row selected.
col filename format a40
select * from v$dnfs_files;
SQL> select * from v$dnfs_files;
FILENAME FILESIZE PNUM SVR_ID
—————————————- ———- ———- ———-
/opt/oracle/oradata/nfs/test01.dbf 2145394688 9 1
SQL> col path format a30
SQL> select * from V$DNFS_CHANNELS;
PNUM SVRNAME PATH CH_ID SVR_ID SENDS RECVS PINGS
———- —————————————- —————————— ———- ———- ———- ———- ———-
5 nfs_server 192.168.172.128 0 1 9 25 0
9 nfs_server 192.168.172.128 0 1 28 75 0
11 nfs_server 192.168.172.128 0 1 96 250 0
12 nfs_server 192.168.172.128 0 1 166 552 0
13 nfs_server 192.168.172.128 0 1 216 955 0
14 nfs_server 192.168.172.128 0 1 3 7 0
15 nfs_server 192.168.172.128 0 1 351 1057 0
17 nfs_server 192.168.172.128 0 1 899 2708 0
18 nfs_server 192.168.172.128 0 1 3 7 0
19 nfs_server 192.168.172.128 0 1 2 4 0
20 nfs_server 192.168.172.128 0 1 10 30 0
21 nfs_server 192.168.172.128 0 1 37 109 0
22 nfs_server 192.168.172.128 0 1 18 52 0
13 rows selected.
在NFS server上查看到2049端口的连接：
[root@nfs_server data]# netstat -an |grep 2049
tcp 0 0 0.0.0.0:2049 0.0.0.0:* LISTEN
tcp 0 0 192.168.172.128:2049 192.168.172.132:14111 ESTABLISHED
tcp 0 0 192.168.172.128:2049 192.168.172.132:51478 ESTABLISHED
tcp 0 0 192.168.172.128:2049 192.168.172.132:61228 ESTABLISHED
tcp 0 0 192.168.172.128:2049 192.168.172.132:52532 ESTABLISHED
tcp 0 0 192.168.172.128:2049 192.168.172.132:10827 ESTABLISHED
tcp 0 0 192.168.172.128:2049 192.168.172.132:31047 ESTABLISHED
tcp 0 0 192.168.172.128:2049 192.168.172.132:55132 ESTABLISHED
tcp 0 0 192.168.172.128:2049 192.168.172.132:866 ESTABLISHED
tcp 0 0 192.168.172.128:2049 192.168.172.132:32634 ESTABLISHED
tcp 0 0 192.168.172.128:2049 192.168.172.132:54646 ESTABLISHED
tcp 0 0 192.168.172.128:2049 192.168.172.132:47987 ESTABLISHED
tcp 0 0 192.168.172.128:2049 192.168.172.132:22448 ESTABLISHED
tcp 0 0 192.168.172.128:2049 192.168.172.132:49091 ESTABLISHED
执行：
insert into test select * from test;时
使用自已写的查看网卡流量的脚本iftop查看网络流量中,可以写流量只有3.4Mbytes/s
ifname in_kbytes/s out_kbytes/s all_kbytes/s in_packets/s out_packets/s all_packets/s
——— ———– ———— ———— ———— ————- ————-
eth2 3133 99 3232 2370 770 3140
eth2 3364 147 3511 2559 837 3396
eth2 3630 1511 5142 2828 1845 4673
eth2 3315 103 3419 2517 785 3302
eth2 3380 105 3486 2535 796 3331
eth2 3627 113 3741 2718 854 3572
eth2 3610 112 3722 2704 853 3557
eth2 3586 113 3700 2713 862 3575
eth2 3471 107 3579 2589 804 3393
eth2 3470 108 3578 2618 822 3440
eth2 3347 105 3453 2525 807 3332
eth2 3406 106 3512 2549 809 3358
eth2 3351 106 3458 2547 814 3361
eth2 3248 101 3349 2427 769 3196
eth2 2743 87 2831 2080 666 2746
而执行select count(*) from test;时可以看到网络流量很高，高的时候达到400Mbytes/s.
在NFS Server端查看连接到2049端口的连接数，可以看到有很多个连接，这与使用操作系统的NFS client端是不一样的，
使用操作系统的NFS client端，到服务器的连接只有一个，由此可见，Oracle Direct NFS通过与服务器建立多个TCP连接
来实现高并发IO，从而提升NFS的性能。连接的数目的多少与压力的大小有关，压力越大，连接数越多。
[root@nfs_server nfs]# netstat -an |grep 2049
tcp 0 0 0.0.0.0:2049 0.0.0.0:* LISTEN
tcp 166768 0 192.168.172.128:2049 192.168.172.132:20048 ESTABLISHED
tcp 173716 140 192.168.172.128:2049 192.168.172.132:22625 ESTABLISHED
tcp 172772 0 192.168.172.128:2049 192.168.172.132:28796 ESTABLISHED
tcp 170832 0 192.168.172.128:2049 192.168.172.132:4468 ESTABLISHED
tcp 171764 140 192.168.172.128:2049 192.168.172.132:42147 ESTABLISHED
tcp 172684 0 192.168.172.128:2049 192.168.172.132:63693 ESTABLISHED
tcp 0 0 192.168.172.128:2049 192.168.172.132:48835 ESTABLISHED
tcp 170500 0 192.168.172.128:2049 192.168.172.132:57326 ESTABLISHED
tcp 171772 0 192.168.172.128:2049 192.168.172.132:43246 ESTABLISHED
tcp 0 0 192.168.172.128:2049 192.168.172.132:36080 ESTABLISHED
udp 0 0 0.0.0.0:2049 0.0.0.0:*
NFS随机IOPS性能不高的分析(Editor:osdba)
有1人发表了评论 | 赶紧发表评论吧 | 作者：vogts
最近做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性能调优与架构设计》最新勘误
有5人发表了评论 | 赶紧发表评论吧 | 作者：sky
推荐序二
“当年加入淘宝的毕业生成了淘宝开发 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 替换成如下：
-> FROM group_message
-> WHERE group_id > 1 AND group_id < 10
-> GROUP BY group_id\G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: group_message
type: range
possible_keys: idx_gid_uid_gc
key: idx_gid_uid_gc
key_len: 4
ref: NULL
rows: 3563
Extra: Using where; Using index; Using temporary; Using filesort
1 row in set (0.00 sec)
在”最后再看一下这个和 GROUP BY 一起使用的带有聚合函数的示例,与上面第三个示例相比,可以看到已经多了 filesort 排序操作了,因为我们使用了 MAX 函数。”之后增加
“要取得分组后的 MAX 值，又无法使用索引完成操作，只能通过排序才行了。”
P178
“但是从 5.0.3 开始,VARCHAR 的最大存储限制已经更改为字节数限制了,扩展到可以存放 65535 bytes 的数据,不同的字符集可能存放的字符数并不一样。也就是说,在 MySQL 5.0.3 之前的版本,M 所代表的是字符数,而从5.0.3 版本开始,M 代表的是字节数了。” ->
“但是从 5.0.3 开始,VARCHAR 的最大存储限制已经改为字节数，而且不再有单个字段的限制，而是受单条记录除 TEXT 和 BLOB 类型字段外最大不超过 65536 Bytes 的限制。不过，字段定义中的 M 仍然表示字符数，所以定义后的 VARCHAR 类型字段实际最大可存放数据长度与字符集相关的。”
P199
“最多将缓存 32 个连接线程” -> “最多将缓存 64 个连接线程”
P200
“(127 - 12) / 127 * 100%” -> “(127 - 11) / 127 * 100%”
P202
“平台上可以超出 4BG 的限制” -> “平台上可以超出 4GB 的限制”
P207
“Key_buffer_UsageRatio = (1 - Key_blocks_used/(Key_blocks_used+Key_blocks_unused)) * 100%” ->
“Key_buffer_UsageRatio = (Key_blocks_used/(Key_blocks_used+Key_blocks_unused)) * 100%”
P286
“Lucene 具肖高效的全文索引和分词算法” -> “Lucene 具有高效的全文索引和分词算法”
Update: 2009.07.06
P119 没出现一次对应的事件则数量加1 -> 每出现一次对应的事件则数量加1
P120 然后根据分析结果着手指定优化计划 -> 然后根据分析结果着手制定优化计划
Update: 2009.07.07
P66 “使用工具” -> “实用工具”
Update: 2009.07.14
P8 “Eent Scheduler” -> “Event Scheduler”
p54 “限制耽搁用户” -> “限制单个用户”
P52 “mysql.table_priv” -> “mysql.tables_priv”
“mysql.column_priv” -> “mysql.columns_priv”
Update:2009.08.14
P191 L16 “Event 都被会被 IO 线程” -> “Event 都会被 IO 线程”
P243 L5 “修改的才式” -> “修改的形式”
Update:2009.09.03
注：本文将与作者个人Blog Sky.Jian 朝阳的天空 所发布的勘误信息同步更新
