某电信营业平台p570数据库瞬间访问慢弊病剖析(News).docVIP

某电信业务平台p570数据库瞬间访问慢故障分析目 录 TOC \o 1-3 \h \z \u HYPERLINK \l _Toc328040481 1、故障现象 PAGEREF _Toc328040481 \h 1 HYPERLINK \l _Toc328040482 2、故障的直接原因分析 PAGEREF _Toc328040482 \h 1 HYPERLINK \l _Toc328040483 3、磁盘IO等待时间较长的原因分析 PAGEREF _Toc328040483 \h 2 HYPERLINK \l _Toc328040484 4、锁的形成机制分析 PAGEREF _Toc328040484 \h 5 HYPERLINK \l _Toc328040485 5、结论 PAGEREF _Toc328040485 \h 71、故障现象6月14日14:55，节点XX.XX.XX.XX连接的前台有不到2分钟的时间访问数据库速度很慢。其中表AAA的写入数据的频度如下：时间段写入的记录数2012/6/14 14:503802012/6/14 14:513362012/6/14 14:523572012/6/14 14:533902012/6/14 14:543542012/6/14 14:551772012/6/14 14:562292012/6/14 14:573332012/6/14 14:583852012/6/14 14:593402012/6/14 15:00383在14:55时，写入的数据明显降低。2、故障的直接原因分析比较6月14日，14:53-59的每分钟的ASH报告，发现：1、在14:55:00-14:56:00、14:56:00-14:57:00，存在TOP DB Files，而在其他时段，并不存在。TOP DBfiles表示访问这个数据文件存在较长等待。在55:00-56:00时段，出现等待的事件是： gc current grant 2-way。此事件说明是：当时在内存里找不到数据块，需要到磁盘上去找。（The message-oriented wait event statistics indicate that no block was received because it was not cached in any instance. Instead a global grant was given, enabling the requesting instance to read the block from disk or modify it.） 2、在56:00-57:00，事件更演变成： gc buffer busy acquire这是一个面向竞争的事件。这个事件表明library cache pin已经发生了。事实上果然如此。（The contention-oriented wait event statistics indicate that a block was received which was pinned by a session on another node,was deferred because a change had not yet been flushed to disk or because of high concurrency, and therefore could not be shipped immediately.）这个事件通常是指另一个节点的会话加锁了数据块。加锁的原因是下列因素之一：还没有刷新到磁盘高度并发本地的两个会话在争抢。从上面的分析看到，这次某电信业务瞬间访问慢的直接原因就是磁盘IO等待时间较长。3、磁盘IO等待时间较长的原因分析14:55:00-14:56:00等待的数据文件如下。File ID% ActivityEvent% EventFile NameTablespace1181.15gc current grant 2-way1.15/dev/rlv_index43ICD某电信业务_MAIN_IDX1461.15gc current grant 2-way1.15/dev/rlv_index56ICD某电信业务_LOG_IDX1511.15gc current grant 2-way1.15/dev/rlv_index61ICD某电信业务_LOG_IDX1分钟ASH报告中，top db file如下：File ID% ActivityEvent% EventFile NameTablespace1181.15gc current grant 2-way1.15/dev/rlv_index43ICD某电信业务