#netstat -i
en7 1500 link#2 0.14.5e.c5.5d.2e 3133315897 0 2978410586 4 0
en7 1500 10.33.102.9 jsdxh_db_svc 3133315897 0 2978410586 4 0
en9 1500 link#3 0.14.5e.c5.64.b8 16814726 0 3897247 3 0
en9 1500 192.168.0 jsdxh_db01_stby 16814726 0 3897247 3 0
lo0 16896 link#1 13949555 0 13969868 0 0
lo0 16896 127 loopback 13949555 0 13969868 0 0
lo0 16896 ::1 13949555 0 13969868 0 0
从上面对数据库主机的操作系统层面的情况检查来看，大致可以判断造成问题主要应该是在io上面。尤其是hdisk5，hdisk5的io负担过重，可以考虑与分担一部分的量到hdisk4上，以平衡磁盘io，减少io等待。下面对数据库部分的分析也主要在io这一块，其他方面在这里就不作分析了。
下面对数据库部分的分析思路大致如下：找到读写最频繁读写的lv(有可能是表，索引或者其他的)，分布其流量。
下面再对数据库来作分析。
1、检查了一下alert日志。
$ tail -100 alert_ora92.log |more
Thu Oct 25 17:43:29 2007
Thread 1 advanced to log sequence 68444
Current log# 3 seq# 68444 mem# 0: /dev/rlv_redo13
Current log# 3 seq# 68444 mem# 1: /dev/rlv_redo16
Thu Oct 25 17:47:26 2007
Thread 1 advanced to log sequence 68445
Current log# 4 seq# 68445 mem# 0: /dev/rlv_redo11
Current log# 4 seq# 68445 mem# 1: /dev/rlv_redo14
Thu Oct 25 17:51:16 2007
Thread 1 advanced to log sequence 68446
Current log# 5 seq# 68446 mem# 0: /dev/rlv_redo12
Current log# 5 seq# 68446 mem# 1: /dev/rlv_redo15
从日志中看，redo切换的频率相当高，基本上是4分钟不到，就会作一次日志的切换操作。Redo是3个组，每组2个member，每个member 500M。
2、statspack
Top 5 Timed Events
~~~~~~~~~~~~~~~~~~ % Total
Event Waits Time (s) Ela Time
-------------------------------------------- ------------ ----------- --------
log file sync 483,667 84,354 64.69
db file sequential read 469,344 35,231 27.02
enqueue 82,536 5,747 4.41
CPU time 2,150 1.65
db file parallel write 11,919 1,245 .96
从top 5事件看，
日志的写入速度太慢。这需要对应用作调整，将频繁commit的改为批量提交。但是在这里我想可能更大的原因是磁盘io的原因。检查一下相关的日志文件，以及相关redo的lv情况：
QL> /
GROUP# STATUS TYPE MEMBER
---------- ------- ------- ------------------------------
3 ONLINE /dev/rlv_redo13
3 ONLINE /dev/rlv_redo16
4 ONLINE /dev/rlv_redo11
4 ONLINE /dev/rlv_redo14
5 ONLINE /dev/rlv_redo12
5 ONLINE /dev/rlv_redo15
SQL> !
$ lslv -l lv_redo13
lv_redo13:N/A
PV COPIES IN BAND DISTRIBUTION
hdisk4 008:000:000 0% 000:000:000:000:008
$ lslv -l lv_redo16
lv_redo16:N/A
PV COPIES IN BAND DISTRIBUTION
hdisk5 008:000:000 0% 000:000:008:000:000
$ lslv -l lv_redo11
lv_redo11:N/A
PV COPIES IN BAND DISTRIBUTION
hdisk4 008:000:000 0% 008:000:000:000:000
$ lslv -l lv_redo14
lv_redo14:N/A
PV COPIES IN BAND DISTRIBUTION
hdisk5 008:000:000 0% 008:000:000:000:000
$ lslv -l lv_redo12
lv_redo12:N/A
PV COPIES IN BAND DISTRIBUTION
hdisk4 008:000:000 0% 000:000:000:000:008
$ lslv -l lv_redo15
lv_redo15:N/A
PV COPIES IN BAND DISTRIBUTION
hdisk5 008:000:000 0% 008:000:000:000:000
在这里，每个组中的两个member一个在hdisk4，一个在hdisk5，分布在磁盘的边缘。可以考虑改变一下内策略，将redo分布调整到磁盘的中间位置。因为本身是raid10的方式，或者干脆不要两个member，只使用其中的一个member，这个有可能带来其他的问题，如果非不得已，不考虑这种方法。
另外一个等待事件，顺序读。这个事件一般是由于不当的选择索引或者表的连接。但在这里，我想可能并不是这个原因，而主要还是磁盘繁重的io造成的。看一下物理读排序的SQL语句：
SQL ordered by Reads for DB: ORA92 Instance: ora92 Snaps: 47 -48
-> End Disk Reads Threshold: 1000
CPU Elapsd
Physical Reads Executions Reads per Exec %Total Time (s) Time (s) Hash Value
--------------- ------------ -------------- ------ -------- --------- ----------
170,449 206,955 0.8 33.1 279.55 20719.02 4053432766
Module: Das.exe
BEGIN p_mc_sce_addsms(:p0,:p1,:p2,:p3,:p4,:p5,:p6,:p7,:p8); END
;
142,856 233,890 0.6 27.8 74.05 9616.88 1594289970
Module: Das.exe
SELECT MAX(T.ACTIVE_FLAG), MAX(T.SECOND_NO) FROM T_MC_MCN_USERIN
FO T WHERE T.USER_NO = :B1 AND T.PARTCOL_USERNO = SUBSTR(:B1 , -
3, 2) AND ROWNUM <= 1
更多内容请看PCdog.com--解决方案 系统解决方案 性能调优专题
