AIX系统性能管理之Oracle案例分析
2010-09-07 10:38
633 查看
AIX系统性能管理之Oracle案例分析
在这个案例中，主要重点就io这一块作分析。对于其他的，在这里就不作讨论。
应用环境：
两台P570作HA(Rotating方式)，AIX 5.3 安装oracle 9206，磁阵DS4300，14块盘，6块作raid10为hdisk4，另外8块盘作raid10为hdisk5
两台P630作HA(Rotating方式)，AIX 5.1 安装oracle 9206，磁阵7133
两个数据库各分担一定的功能。P570压力比较大。
性能问题：
最近，P570数据库上的数据库性能急剧下降，报表统计跑将近24个小时才能完成，严重影响白天正常的业务，给主机带来比较大的性能负担。
检查过程(主要在P570上操作)：
1、使用topas查看一下操作系统的load情况。结果没想到topas无法运行了，得到的结果如下，根本无法刷新数据。
2、安装nmon_aix53(操作系统为5.3)，结果nmon_aix53运行也报错。
3、检查进程情况
竟然总共已经产生了9000多个进程。在这众多的进程中可以发现有很多的defunct进程。
在网上随便查一下defunct，就可以知道，这是孤儿进程。已经找不到父进程，所以把init(PID 1)作为他的父进程。上面的结果中就是PPID=1。孤儿进程无法用kill -9 来清除，即使是root用户也不行，只能重启。这些孤儿进程一般情况下都是由于不当的fork ()/execve()造成的。
继续检查系统，不知道这么多的孤儿进程是哪个产生的。看一下主机系统的报错情况。
在这里，可以看到频繁的这个报错。基本每隔半个小时报错一次。再检查详细的错误。可以定位到原来是由于一个网管监控软件造成的这个错误。基本也可以判断，由于整个软件的不当的fork调用，导致了数量惊人的孤儿进程。
现在孤儿进程的问题基本确定了，但是这个孤儿进程到目前为止，对系统造成的影响有多大?网上搜了一把，孤儿进程一般不占用内存，不占用空间，只不过是在进程列表中占了一个位置，所以并不会对系统性能产生太严重的影响。当然，如果任期发展，有可能就会使主机hang住。在这里，网管系统是以root用户运行的，进程数的限制非常大。所以，这里孤儿进程应该只是一个安全隐患，并不是对当前性能造成影响的原因。
4、检查cpu的使用情况，
Cpu的使用率基本在65%左右，wa基本在35%到40%，io等待比较严重。
5、再继续检查一下磁盘的IO情况
在上面的两份报告中，可以发现，系统对磁盘的负载不均。Hdisk5基本上长期维持在100%，而hdisk4则基本上维持在50%左右。再检查这两个hdisk的详细情况：
6、检查一下内存，
#lsps -a
Page Space Physical Volume Volume Group Size %Used Active Auto Type
paging00 hdisk2 rootvg 12288MB 1 yes yes lv
hd6 hdisk0 rootvg 12288MB 1 yes yes lv
#svmon -G -i 1 5
size inuse free pin virtual
memory 6029312 3780159 2249153 446200 3535574
pg space 6291456 17540
work pers clnt
pin 445938 262 0
in use 3535574 244585 0
size inuse free pin virtual
memory 6029312 3780168 2249144 446205 3535578
pg space 6291456 17540
这台机器内存比较大，24G物理内存，从这里看，free的空间也挺多，交换区也基本没怎么使用，在这里内存肯定不会造成问题。
查看一下参数设置情况：
#vmo -a | grep perm
maxperm = 4587812
maxperm% = 80
minperm = 1146952
minperm% = 20
#vmo -a | grep client
maxclient% = 80
这里，两套系统都使用的是裸设备，这几个参数完全没必要设这么高，这会造成系统的内存争用。P570内存比较大，这种情况还没多大影响，但是在P630上，就可以看到已经比较危险了。下面是nmon输出的一个内存统计结果，可以看到物理内存已经被消耗殆尽，交换也已经使用了62.6%的空间了。但实际上这个数据库是比较空闲的，cpu使用率不超过10%，io的量基本为0，内存的消耗实际上就是被maxperm给吃了，被文件页面的缓存给占用了。这个系统就必需要调整maxperm和minperm的值，否则如果业务繁忙起来，将导致oracle和操作系统的内存争用，影响性能。
Memory
Physical PageSpace | pages/sec In Out | FileSystemCache
% Used 99.4% 62.6% | to Paging Space 0.0 0.0 | Process & 13.3%
% Free 0.6% 37.4% | to File System 0.0 14.2 | System 86.1%
MB Used 8141.4MB 2563.9MB | Page Scans 0.0 |
MB Free 50.6MB 1532.1MB | Page Cycles 0.0 | Free 0.6%
Total(MB) 8191.9MB 4096.0MB | Page Steals 0.0 | ------
| Page Faults 18.9 | Total 100.0%
------------------------------------------------------------ |
Min/Maxperm 1540MB( 19%) 6162MB( 75%) <--% of RAM |
Min/Maxfree 120 128 Total Virtual 12.0GB |
Pinned 7.1%
7、顺带再检查一下，网络基本没什么问题。
#netstat -i
Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll
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
我想，在这里我们对比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
再来统计一下，表的读写情况。
通过上面的file io以及表的统计，再结合实际的业务情况，可以明确，这里最繁忙的是表空间TBS_MCN_LOG_DAT中的表T_MC_SMS_SMSNOTI以及其上位于表空间TBS_MCN_LOG_IDX中的索引。并且，这两部分全部集中再hdisk5上，所以后面的平衡io的优化操作就是将该表以及索引部分分布到hdisk4上。
在这个案例中，主要重点就io这一块作分析。对于其他的，在这里就不作讨论。
应用环境：
两台P570作HA(Rotating方式)，AIX 5.3 安装oracle 9206，磁阵DS4300，14块盘，6块作raid10为hdisk4，另外8块盘作raid10为hdisk5
两台P630作HA(Rotating方式)，AIX 5.1 安装oracle 9206，磁阵7133
两个数据库各分担一定的功能。P570压力比较大。
性能问题：
最近，P570数据库上的数据库性能急剧下降，报表统计跑将近24个小时才能完成，严重影响白天正常的业务，给主机带来比较大的性能负担。
检查过程(主要在P570上操作)：
1、使用topas查看一下操作系统的load情况。结果没想到topas无法运行了，得到的结果如下，根本无法刷新数据。
| Topas Monitor for host: jsdxh_db01 EVENTS/QUEUES FILE/TTY Thu Oct 25 13:58:32 2007 Interval: 2 Cswitch Readch Syscall Writech Kernel | | Reads Rawin User | | Writes Ttyout Wait | | Forks Igets Idle | | Execs Namei Runqueue Dirblk Network KBPS I-Pack O-Pack KB-In KB-Out Waitqueue PAGING MEMORY Faults Real,MB Steals % Comp Disk Busy% KBPS TPS KB-Read KB-Writ PgspIn % Noncomp PgspOut % Client PageIn PageOut PAGING SPACE Sios Size,MB % Used NFS (calls/sec) % Free ServerV2 ClientV2 Press: ServerV3 "h" for help ClientV3 "q" to quit |
| #./nmon_aix53 ERROR: Assert Failure in file="nmon11.c" in function="main" at line=3239 ERROR: Reason=NULL pointer ERROR: Expression=[[q->procs = MALLOC(sizeof(struct procentry64 ) * n )]] ERROR: errno=12 ERROR: errno means : Not enough space |
| #ps -ef | wc -l 9947 |
| #ps -ef |grep defunct | wc -l 9331 ##ps -ef | grep defunct | more root 159952 1 0 0:00 <defunct> root 172052 1 0 0:00 <defunct> root 225294 1 1 0:00 <defunct> root 262236 1 0 0:00 <defunct> root 290902 1 0 0:00 <defunct> |
继续检查系统，不知道这么多的孤儿进程是哪个产生的。看一下主机系统的报错情况。
| #errpt |more IDENTIFIER TIMESTAMP T C RESOURCE_NAME DESCRIPTION A63BEB70 1025140007 P S SYSPROC SOFTWARE PROGRAM ABNORMALLY TERMINATED A63BEB70 1025133007 P S SYSPROC SOFTWARE PROGRAM ABNORMALLY TERMINATED A63BEB70 1025130007 P S SYSPROC SOFTWARE PROGRAM ABNORMALLY TERMINATED A63BEB70 1025123007 P S SYSPROC SOFTWARE PROGRAM ABNORMALLY TERMINATED A63BEB70 1025120007 P S SYSPROC SOFTWARE PROGRAM ABNORMALLY TERMINATED |
现在孤儿进程的问题基本确定了，但是这个孤儿进程到目前为止，对系统造成的影响有多大?网上搜了一把，孤儿进程一般不占用内存，不占用空间，只不过是在进程列表中占了一个位置，所以并不会对系统性能产生太严重的影响。当然，如果任期发展，有可能就会使主机hang住。在这里，网管系统是以root用户运行的，进程数的限制非常大。所以，这里孤儿进程应该只是一个安全隐患，并不是对当前性能造成影响的原因。
4、检查cpu的使用情况，
| #vmstat 1 10 System configuration: lcpu=16 mem=23552MB kthr memory page faults cpu ----- ----------- ------------------------ ------------ ----------- r b avm fre re pi po fr sr cy in sy cs us sy id wa 4 0 3533226 2251446 0 0 0 0 0 0 3167 323907 7321 22 9 32 37 1 0 3533229 2251443 0 0 0 0 0 0 1863 313913 4784 18 8 40 34 2 0 3533229 2251443 0 0 0 0 0 0 3004 319720 6939 19 9 35 38 |
5、再继续检查一下磁盘的IO情况
| #iostat 1 2 System configuration: lcpu=16 drives=11 paths=4 vdisks=0 tty: tin tout avg-cpu: % user % sys % idle % iowait 0.0 60.0 26.6 9.6 38.4 25.4 Disks: % tm_act Kbps tps Kb_read Kb_wrtn hdisk1 37.0 350.0 70.0 0 350 hdisk0 31.0 354.0 70.0 0 354 hdisk2 0.0 0.0 0.0 0 0 hdisk3 0.0 0.0 0.0 0 0 dac0 0.0 9780.0 1199.0 2000 7780 dac0-utm 0.0 0.0 0.0 0 0 dac1 0.0 0.0 0.0 0 0 dac1-utm 0.0 0.0 0.0 0 0 hdisk4 49.0 3141.0 389.0 520 2621 hdisk5 99.0 6639.0 810.0 1480 5159 cd0 0.0 0.0 0.0 0 0 tty: tin tout avg-cpu: % user % sys % idle % iowait 0.0 902.0 30.2 8.4 38.9 22.5 Disks: % tm_act Kbps tps Kb_read Kb_wrtn hdisk1 0.0 0.0 0.0 0 0 hdisk0 0.0 0.0 0.0 0 0 hdisk2 0.0 0.0 0.0 0 0 hdisk3 0.0 0.0 0.0 0 0 dac0 0.0 13080.0 1497.0 1616 11464 dac0-utm 0.0 0.0 0.0 0 0 dac1 0.0 0.0 0.0 0 0 dac1-utm 0.0 0.0 0.0 0 0 hdisk4 63.0 3866.0 405.0 296 3570 hdisk5 100.0 9214.0 1092.0 1320 7894 cd0 0.0 0.0 0.0 0 0 |
| #lspv hdisk5 PHYSICAL VOLUME: hdisk5 VOLUME GROUP: oravg PV IDENTIFIER: 00c2c1eb0bcfbdd4 VG IDENTIFIER 00c2c1eb00004c0000000110153a551d PV STATE: active STALE PARTITIONS: 0 ALLOCATABLE: yes PP SIZE: 64 megabyte(s) LOGICAL VOLUMES: 120 TOTAL PPs: 8718 (557952 megabytes) VG DESCRIPTORS: 1 FREE PPs: 1206 (77184 megabytes) HOT SPARE: no USED PPs: 7512 (480768 megabytes) MAX REQUEST: 1 megabyte FREE DISTRIBUTION: 00..00..00..00..1206 USED DISTRIBUTION: 1744..1744..1743..1743..538 #lspv hdisk4 PHYSICAL VOLUME: hdisk4 VOLUME GROUP: oravg PV IDENTIFIER: 00c2c1eb0bcfb8b3 VG IDENTIFIER 00c2c1eb00004c0000000110153a551d PV STATE: active STALE PARTITIONS: 0 ALLOCATABLE: yes PP SIZE: 64 megabyte(s) LOGICAL VOLUMES: 128 TOTAL PPs: 6538 (418432 megabytes) VG DESCRIPTORS: 2 FREE PPs: 100 (6400 megabytes) HOT SPARE: no USED PPs: 6438 (412032 megabytes) MAX REQUEST: 1 megabyte FREE DISTRIBUTION: 00..00..00..00..100 USED DISTRIBUTION: 1308..1308..1307..1307..1208 |
#lsps -a
Page Space Physical Volume Volume Group Size %Used Active Auto Type
paging00 hdisk2 rootvg 12288MB 1 yes yes lv
hd6 hdisk0 rootvg 12288MB 1 yes yes lv
#svmon -G -i 1 5
size inuse free pin virtual
memory 6029312 3780159 2249153 446200 3535574
pg space 6291456 17540
work pers clnt
pin 445938 262 0
in use 3535574 244585 0
size inuse free pin virtual
memory 6029312 3780168 2249144 446205 3535578
pg space 6291456 17540
这台机器内存比较大，24G物理内存，从这里看，free的空间也挺多，交换区也基本没怎么使用，在这里内存肯定不会造成问题。
查看一下参数设置情况：
#vmo -a | grep perm
maxperm = 4587812
maxperm% = 80
minperm = 1146952
minperm% = 20
#vmo -a | grep client
maxclient% = 80
这里，两套系统都使用的是裸设备，这几个参数完全没必要设这么高，这会造成系统的内存争用。P570内存比较大，这种情况还没多大影响，但是在P630上，就可以看到已经比较危险了。下面是nmon输出的一个内存统计结果，可以看到物理内存已经被消耗殆尽，交换也已经使用了62.6%的空间了。但实际上这个数据库是比较空闲的，cpu使用率不超过10%，io的量基本为0，内存的消耗实际上就是被maxperm给吃了，被文件页面的缓存给占用了。这个系统就必需要调整maxperm和minperm的值，否则如果业务繁忙起来，将导致oracle和操作系统的内存争用，影响性能。
Memory
Physical PageSpace | pages/sec In Out | FileSystemCache
% Used 99.4% 62.6% | to Paging Space 0.0 0.0 | Process & 13.3%
% Free 0.6% 37.4% | to File System 0.0 14.2 | System 86.1%
MB Used 8141.4MB 2563.9MB | Page Scans 0.0 |
MB Free 50.6MB 1532.1MB | Page Cycles 0.0 | Free 0.6%
Total(MB) 8191.9MB 4096.0MB | Page Steals 0.0 | ------
| Page Faults 18.9 | Total 100.0%
------------------------------------------------------------ |
Min/Maxperm 1540MB( 19%) 6162MB( 75%) <--% of RAM |
Min/Maxfree 120 128 Total Virtual 12.0GB |
Pinned 7.1%
7、顺带再检查一下，网络基本没什么问题。
#netstat -i
Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll
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
我想，在这里我们对比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
再来统计一下，表的读写情况。
通过上面的file io以及表的统计，再结合实际的业务情况，可以明确，这里最繁忙的是表空间TBS_MCN_LOG_DAT中的表T_MC_SMS_SMSNOTI以及其上位于表空间TBS_MCN_LOG_IDX中的索引。并且，这两部分全部集中再hdisk5上，所以后面的平衡io的优化操作就是将该表以及索引部分分布到hdisk4上。
内容来自用户分享和网络整理，不保证内容的准确性，如有侵权内容，可联系管理员处理 
相关文章推荐
- AIX系统性能管理之Oracle案例分析
- AIX系统性能管理之Oracle案例分析
- <<《Spark商业案例与性能调优实战100课》第17课：商业案例之NBA篮球运动员大数据分析系统代码实战
- 系统集成资质-集成项目管理工程师下午案例分析题解答方法
- 《黑马程序员》 交通灯管理系统案例分析与总结
- JavaWeb项目开发案例精粹-第6章报价管理系统-001需求分析及设计
- Linux 学习笔记_9_文件系统管理_2_文件系统管理命令及案例分析
- Oracle - PGA自动管理原理深入分析及性能调整(6)
- 《Spark商业案例与性能调优实战100课》第13课：商业案例之纯粹通过DataSet进行电商交互式分析系统中特定时段段访问次数TopN
- Oracle - PGA自动管理原理深入分析及性能调整(7)
- 关于Oracle性能分析中 自动工作量资料档案库(AWR)的管理（Oracle10个/11g的新特点）
- 某金融机构行情系统性能分析案例
- Oracle - PGA自动管理原理深入分析及性能调整(4)
- Oracle DataBase单实例使用ASM案例(4)--AIX系统Oracle 10g应用
- Oracle - PGA自动管理原理深入分析及性能调整(5)
- Spark商业案例与性能调优实战100课》第16课：商业案例之NBA篮球运动员大数据分析系统架构和实现思路
- Silverlight医学PACS诊断分析管理系统【案例分享】
- Oracle - PGA自动管理原理深入分析及性能调整(3)
- 系统集成项目管理工程师教程-第23章案例分析的 风险管理案列 参考答案
- 舰队管理系统分析与设计-舰队管理系统分析与设计（Oracle），功能需求，数据字典，软件工程