通过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点开始会做备份到磁带库中。 问题一下子有了一种峰回路转的感觉。最后一定位,在结合一些相关的数据来做分析,道理就说得通了。 在有些场合中,官方的报告要好于一些主观的数据分析。

原文发布于微信公众号 - 杨建荣的学习笔记(jianrong-notes)

原文发表时间:2014-08-15

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏大数据

Solr:不止于文字

Solr于2004年首次创建时,打算成为OpenSource文本搜索引擎,为企业网站和内部文档搜索等用途提供类似Google的搜索功能。 基于Lucene搜索库...

27500
来自专栏ATYUN订阅号

像素墨镜,大烟卷—Thug Life风格自动生成项目

AiTechYun 编辑:nanan ? 暴徒生活(Thug Life)是一款非常火热的P图特效,通过加上此特效会让用户的视频或者照片变的非常有趣好玩。其拥有大...

39650
来自专栏Java架构

跳槽必看!一位程序猿面试蚂蚁金服后端的经验总结!前言自我介绍最近的项目经历总结

32550
来自专栏编程一生

IO和socket编程

13330
来自专栏Albert陈凯

2018-11-06 成为一个专业的程序员前言

https://github.com/stanzhai/be-a-professional-programmer

91720
来自专栏圆方圆学院精选

【董天一】IPFS家族(一)

IPFS这个项目其实很大,并不像大家想象的是一个东西,IPFS是由很多模块组成,每一个模块现在都已经独立成项目了,并且有自己的主页。让我们来简单看一下IPFS家...

27410
来自专栏SDNLAB

解耦重构 Internet BGP SDN

高清视频直播和云计算的蓬勃发展,带来互联网流量持续高速增长,主流云公司的Internet出口带宽都已经达到Tbps级别。 鉴于网络的拥堵大部分发生在出口互联,E...

48040
来自专栏Java社区

【五一福利】Java程序员编程学习之路资源合集

25730
来自专栏我的博客

Lucenu和Sphinx介绍

一、Lucene介绍 1、简介 Lucene 是apache软件基金会一个开放源代码的全文检索引擎工具包,是一个全文检索引擎的架构,提供了完整的查...

39960
来自专栏phodal

Serverless 应用开发指南:serverless 的 hello, world

在翻译了几篇 serverless 与物联网相关的文章之后,我开始想着好好掌握一下 serverless 的相关知识。 我对于 serverless 的第一认知...

36780

扫码关注云+社区

领取腾讯云代金券