通过addm分析io问题(r2笔记64天)
通过addm分析io问题(r2笔记64天)
昨晚在做测试环境数据迁移的时候，遇到了io的问题，本来预计2，3个小时完成的数据导入工作最后竟然耗了7个多小时。在数据的导入中，使用了10个并行的session，每个session都启用的并行度为8,在表级，索引级都做了nologging设置，在insert的时候使用了append模式，结果本来数据的导入还是比较顺利的，突然在8点左右开始就一下子直线下降。 在使用top命令查看进程的使用情况时，留意到rman的一些进程正在运行。但是大晚上的哪找客户的人来确认这个，使用dd来测试io的性能，创建一个200M的文件，不到1秒钟，还是比较快的。 但是可以看到iowait很高。 这个问题造成的影响还是比较严重的，因为目前为止还没有完全确定问题的根源，如果是后台的一些进程在运行，影响到底有多少，还没有估量，但是可以明显的看到数据库是不给力的，undo的空间到后面的数据导入中不仅足够充裕，还不断释放一些空间，让人感觉很郁闷，但是又插不上什么手。 下午的时候，和客户的存储部门，unix部门等的人一起开会，大家都列除了昨晚的一些问题总之就是发现了问题，但是因为那个段知道的动作就是我们在做数据导入，还没法确定到底是不是他们的问题。所以大家虽然能够列出一些图表数据，说明问题但是还是没有能够明确的定位问题。 我拿出了数据库层面反应数据库繁忙程度的一个指标，redo的切换率，在周一做的一次数据迁移中，redo在一个小时甚至达到了200多次。redo日志是1个G左右的样子。
DBNAME TIME_STAMP
--------- --------------------
PRODB 2014-Aug-14 23:09:09
GROUP# THREAD# SEQUENCE# MEMBERS SIZE_MB ARC STATUS
---------- ---------- ---------- ---------- ---------- --- ----------------
1 1 3389 2 1024 YES INACTIVE
2 1 3390 2 1024 YES INACTIVE
3 1 3391 2 1024 NO CURRENT
4 1 3388 2 1024 YES INACTIVERedo Switch times per hour PRODB 2014-Aug-14 23:09:09
MON DA 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23
--- -- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ----
07 31 0 0 1 0 0 0 0 0 0 0 0 0 0 0 1 1 5 1 0 4 1 0 0 2
08 01 35 51 19 0 0 1 0 0 1 0 1 4 2 1 2 9 5 4 3 4 3 2 2 2
08 02 1 1 1 8 0 1 0 1 1 1 1 11 0 0 1 0 0 1 0 0 1 0 0 1
08 03 0 0 1 0 0 1 0 0 1 0 0 1 0 0 1 0 0 2 2 3 1 0 0 1
08 04 0 0 1 0 0 1 0 0 1 0 0 1 1 1 3 3 2 3 1 1 1 0 0 1
08 05 0 0 1 0 0 1 0 0 1 0 0 1 0 0 1 0 0 1 0 0 1 0 0 1
08 06 0 0 1 0 0 1 0 0 1 0 0 1 0 0 1 0 0 1 0 0 1 0 0 1
08 07 0 0 1 0 0 1 0 0 1 0 0 1 0 0 1 0 0 1 4 6 1 0 0 1
08 08 0 0 1 0 0 1 0 0 1 0 0 1 0 0 1 14 0 7 2 0 3 0 1 1
08 09 0 0 1 0 0 1 0 0 1 0 0 1 0 0 1 0 0 1 1 0 1 0 0 1
08 10 0 0 1 0 0 1 0 0 1 0 0 1 0 0 1 0 0 1 0 0 1 0 0 1
08 11 0 0 1 0 0 1 0 0 1 0 109 207 34 0 1 0 0 1 0 0 1 0 0 1
08 12 0 1 1 0 0 1 0 0 1 0 0 1 0 0 1 0 0 1 0 0 1 0 0 1
08 13 0 0 1 0 0 1 0 0 1 0 0 1 0 0 1 0 1 24 123 65 25 22 22 19
08 14 22 29 30 25 21 16 0 0 1 27 42 1 0 0 2 22 2 5 5 5 4 5 3 0但是在昨晚的时候，简直是惨淡。到后面自己都不忍看这个速度了，眯了好一会，还在慢慢的做数据导入。 我提到了rman的影响，但是似乎客户那边还不是很确定是这个问题影响的。因为据他们说之前一直没有碰到过io的问题，上一次做数据导入的时候还是在白天，更不能说明了。 在大家都有依据，但是没有方向的，听听oracle怎么说，得到一个详尽的addm报告，然后就可以看到里面清晰的分析了io的一些问题，有很大一部分是由于rman导致的。 亮点是最后两处。
Finding 8: I/O Throughput
Impact is .8 active sessions, 2.23% of total activity.
------------------------------------------------------
The throughput of the I/O subsystem was significantly lower than expected.
Recommendation 1: Host Configuration
Estimated benefit is .8 active sessions, 2.23% of total activity.
-----------------------------------------------------------------
Action
Consider increasing the throughput of the I/O subsystem. Oracle's
recommended solution is to stripe all data files using the SAME
methodology. You might also need to increase the number of disks for
better performance.
Rationale
During the analysis period, the average data files' I/O throughput was
61 M per second for reads and 42 M per second for writes. The average
response time for single block reads was 1.3 milliseconds.
Recommendation 2: Host Configuration
Estimated benefit is .27 active sessions, .76% of total activity.
-----------------------------------------------------------------
Action
Consider slowing down RMAN or Data Pump activity, or scheduling these
jobs when user activity is lower.
Rationale
The I/O throughput on data and temp files was divided as follows: 34% by
RMAN, 0% by Data Pump, 0% by Recovery and 65% by all other activity.
Symptoms That Led to the Finding:
---------------------------------
Wait class "User I/O" was consuming significant database time.
Impact is 12.58 active sessions, 35% of total activity.有了这些分析，也有了一些说服力，他们开始查找问题发生的那个时间段的一些可能影响，结果网路组的人发现从8点开始网络带宽消耗异常的高。但是我们做数据导入是不依赖网络的。 然后他们继续排查，备份组发现设置了crontab，从8点开始会做备份到磁带库中。 问题一下子有了一种峰回路转的感觉。最后一定位，在结合一些相关的数据来做分析，道理就说得通了。 在有些场合中，官方的报告要好于一些主观的数据分析。