|
|
下面再对数据库来作分析。
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情况：
SQL> /
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( 0,1,2,3,4,5,6,7,8); 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
我想，在这里我们对比cpu time和Elapsd time就可以发现，这里I/O等待的情况非常严重。当然，也可以进一步检查过程内语句的执行计划情况，看是否合理。在这里，还是来关注io的情况。
在表空间的io统计中，比较繁忙的表空间是：
->ordered by IOs (Reads + Writes) desc
Tablespace
------------------------------
Av Av Av Av Buffer Av Buf
Reads Reads/s Rd(ms) Blks/Rd Writes Writes/s Waits Wt(ms)
-------------- ------- ------ ------- ------------ -------- ---------- ------
TBS_MCN_HIS_IDX
109,393 61 94.2 1.0 421,033 233 8,004 1.8
TBS_MCN_LOG_IDX
101,915 56 74.3 1.0 416,523 231 34,705 2.8
TBS_MCN_MAIN_IDX
110,871 61 43.9 1.0 200,902 111 15,797 1.4
TBS_MCN_MAIN_DAT
108,012 60 79.2 1.2 68,267 38 9,668 0.9
在看file io之前，先看一下hdisk4和hdisk5的各自拥有的lv情况。
#lspv -l hdisk4
hdisk4:
LV NAME LPs PPs DISTRIBUTION MOUNT POINT
lv_data052 64 64 00..00..64..00..00 N/A
lv_data009 64 64 00..64..00..00..00 N/A
lv_data053 64 64 00..00..64..00..00 N/A
…
#lspv -l hdisk5
hdisk5:
LV NAME LPs PPs DISTRIBUTION MOUNT POINT
lv_data143 64 64 00..00..64..00..00 N/A
lv_data100 64 64 00..64..00..00..00 N/A
lv_data244 64 64 00..00..00..00..64 N/A
lv_data142 64 64 00..00..64..00..00 N/A
lv_data099 64 64 00..64..00..00..00 N/A
…
通过观察，可以分布的大致情况是，080以上的lv基本在hdisk5中，080以下lv基本都在hdisk4中。现在再对比一下file io的统计：
根据file io的统计，去计算一下，在hdisk4和hdisk5中的物理读的数量差不多是
Hdisk4：132,578
Hdisk5：261,996
Hdisk5的io量差不多就是hdisk4的两倍。这和前面iostat的统计的结果也基本差不多。
下面几个是file io统计中最繁忙的几个lv。
TBS_MCN_LOG_IDX /dev/rlv_data096
50,938 28 74.8 1.0 209,422 116 17,496 2.6
/dev/rlv_data097
50,977 28 73.7 1.0 207,101 115 17,209 3.0
TBS_MCN_MAIN_DAT /dev/rlv_data009
15,625 9 20.6 1.0 985 1 0
/dev/rlv_data010
33,026 18 18.0 1.5 26,717 15 9,658 0.7
/dev/rlv_data091
37,009 21 118.5 1.2 38,190 21 9 107.8
/dev/rlv_data092
22,352 12 145.5 1.0 2,375 1 1 70.0
TBS_MCN_MAIN_IDX /dev/rlv_data018
26,666 15 17.6 1.0 35,333 20 4,023 1.8
/dev/rlv_data019
26,661 15 17.3 1.0 35,216 20 3,368 0.9
/dev/rlv_data020
30,600 17 17.1 1.0 93,095 52 4,274 1.1
/dev/rlv_data093
26,944 15 126.8 1.0 37,258 21 4,132 1.8
再来统计一下，表的读写情况。
select object_name,tablespace_name,value
from v$segment_statistics where statistic_name='physical reads' and owner='MCNS'
order by value desc ;
OBJECT_NAME TABLESPACE_NAME VALUE
PK_MC_MCN_USERINFO TBS_MCN_MAIN_IDX 66970541
T_MC_SMS_SMSNOTI TBS_MCN_LOG_DAT 51920167
IX_MC_SMS_SMSNOTI_SMID TBS_MCN_LOG_IDX 29194969
IX_MC_SMS_SMSNOTI_CREATETIME TBS_MCN_LOG_IDX 28041895
PK_MC_SMS_SMSNOTI TBS_MCN_LOG_IDX 26514549
IX_MC_SMS_SMSNOTI_SERIALID TBS_MCN_LOG_IDX 25635735
PK_MC_MCN_REC TBS_MCN_MAIN_IDX 17623694
IX_MCN_REC_TIME TBS_MCN_MAIN_IDX 13969248
T_MC_SMS_SMSNOTIHIS TBS_MCN_HIS_DAT 4455853
IX_MC_SMS_SMSNOTI_STATUS TBS_MCN_LOG_IDX 4432880
IX_RECVSMLOGHIS_ORGADDR SERVICE_HIST_IDX 4187067
IX_MC_SMS_SMSNOTI_GETFLAG TBS_MCN_LOG_IDX 3812548
T_MC_SMS_SMSNOTIHIS TBS_MCN_HIS_DAT 3758602
T_MC_SMS_SMSNOTIHIS TBS_MCN_HIS_DAT 3632276
T_MC_SMS_SMSNOTIHIS TBS_MCN_HIS_DAT 3585179
T_MC_SMS_SMSNOTIHIS TBS_MCN_HIS_DAT 3561865
T_MC_SMS_SMSNOTIHIS TBS_MCN_HIS_DAT 3509901
T_MC_SMS_SMSNOTIHIS TBS_MCN_HIS_DAT 3495163
T_MC_SMS_SMSNOTIHIS TBS_MCN_HIS_DAT 3480248
T_MC_SMS_SMSNOTIHIS TBS_MCN_HIS_DAT 3473926
T_MC_SMS_SMSNOTIHIS TBS_MCN_HIS_DAT 3463826
T_MC_SMS_SMSNOTIHIS TBS_MCN_HIS_DAT 3431232
通过上面的file io以及表的统计，再结合实际的业务情况，可以明确，这里最繁忙的是表空间TBS_MCN_LOG_DAT中的表T_MC_SMS_SMSNOTI以及其上位于表空间TBS_MCN_LOG_IDX中的索引。并且，这两部分全部集中再hdisk5上，所以后面的平衡io的优化操作就是将该表以及索引部分分布到hdisk4上。 |
|
楼主: BTxigua
IP卡
狗仔卡
楼主
显身卡
发表于 2007-10-31 13:47
