通过addm分析io问题(r2笔记64天)

时间:2022-05-04
本文章向大家介绍通过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 INACTIVE
Redo 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点开始会做备份到磁带库中。 问题一下子有了一种峰回路转的感觉。最后一定位，在结合一些相关的数据来做分析，道理就说得通了。 在有些场合中，官方的报告要好于一些主观的数据分析。

随机文章
本站知识点必读
最近更新