« 在上海 在最复杂的数据库故障处理中 | Blog首页 | 案情分析：数据库的基本情况 »
案例分析：事情的开始是这样的
作者：eygle | 【转载请注出处】|【云和恩墨 领先的zData数据库一体机 | zCloud PaaS云管平台 | SQM SQL审核平台 | ZDBM 数据库备份一体机】
链接：https://www.eygle.com/archives/2010/10/hard_case_one.html
今天晚上和客户一起喝了点酒，微醺，我觉得我也可以学习一下白鳝，写点小说一样的文字。链接：https://www.eygle.com/archives/2010/10/hard_case_one.html
我喜欢看狄仁杰，不是刘德华版本的，刘德华的版本太年轻了，电视版的梁冠华成为了一个象征，我喜欢狄仁杰的一句话：事情是这样的......
然后镜头开始回放，狄仁杰的推理开始演绎。
DBA的故障诊断与此类似，当遇到疑难杂症时，就需要DBA来进行猜测推理，然后进行揣测验证，最后得出结论。
然而这个过程绝不简单。
如果有朋友对我提到的这个案例感兴趣，那我们就一起来分享一下整个的诊断过程，看一看我们能够如何来抽丝拨茧，找出问题真相，破解这一出重大案件。
客户系统正常运行时CPU负荷通常在50%~60%，但是在某一时刻CPU会突然串升到100%，而且无法排解。
以下是30分钟之内的Top 5 Time Events
| Event | Waits | Time(s) | Avg Wait(ms) | % Total Call Time | Wait Class |
|---|---|---|---|---|---|
| latch: row cache objects | 1,271,430 | 349,493 | 275 | 53.8 | Concurrency |
| db file sequential read | 16,817,559 | 85,942 | 5 | 13.2 | User I/O |
| CPU time | 61,840 | 9.5 | |||
| cursor: pin S wait on X | 5,044,109 | 51,167 | 10 | 7.9 | Concurrency |
| read by other session | 3,036,029 | 10,224 | 3 | 1.6 | User I/O |
这里最显著的是latch:row cache objects的疯狂竞争，然后cursor:pin S wait on X同时出现。
这一过程无法排解。
请大家推演一下，这种情况如何能够出现？如果需要其他信息，我可以进一步提供。我们一起来重走一下长征路。
历史上的今天...
>> 2009-10-14文章:
>> 2008-10-14文章:
>> 2007-10-14文章:
>> 2006-10-14文章:
>> 2005-10-14文章:
>> 2004-10-14文章:
By eygle on 2010-10-14 00:45 | Comments (16) | Case | 2635 |
1.高峰期语句的执行和解析是否明显增加
2.共享池的使用情况如何
3.sga是否配置自动管理
4.cpu高峰期是否出现sga的动态调整
1.高峰期语句的执行和解析是否明显增加
2.共享池的使用情况如何
3.sga是否配置自动管理
4.cpu高峰期是否出现sga的动态调整
1.高峰期语句的执行和解析是否明显增加
2.row cache 中是否某个部分突然出现大量的gets和misses
3.共享池的使用情况如何
4.sga是否配置自动管理
5.cpu高峰期是否出现sga的动态调整
6.操作系统上除了cpu高以外,内存是否出现换页
数据库多少版本号啊？SGA什么配置啊
1.oracle的版本及平台
2.查出该事件对应的SQL
3.查看回滚表空间的使用大小
我估计应该还要下面的信息吧（AWR或者STATSPACK）
1.Dictionary Cache Stats 信息
2.Latch Sleep Breakdown
3.Latch Miss Sources
补充一点 如果是10G,需要知道是否设置SGA自动调整
然后要得到
v$sga_resize_ops的信息
检查ash视图，如果是sequence导致的latch: row cache objects竞争，那就简单了
如果是其它，继续
latch: row cache objects
cursor: pin S wait on X
首先想到数据字典缓存（Data Dictionary Cache）是主要用于存放数据字典信息，包括表、视图等对象的结构信息，用户以及对象权限信息。
是不是当时有同时执行DDL，造成资源严重竞争导致？
看看Dictionary Cache 统计信息.
select cache#, type, parameter, gets, getmisses, modifications mod from v$rowcache where gets > 0 order by gets;
Cache high gotten objects to reduce dictionary access.
Increase the SHARED_POOL_SIZE according to the V$SHARED_POOL_ADVICE.
等着听精彩故事
来向高手们学习下解决问题的思路
tinker
bug的可能性呢？
看一下逻辑读最高的几个SQL语句
看一下回滚段的使用情况
cursor: pin ( S, S wait on X) means re-executions of the same cursors.
可能是进进出出来来回回闲逛的Child cursors太多.
参考,
http://sites.google.com/site/embtdbo/wait-event-documentation/oracle-library-cache#TOC-cursor:-pin-S-wait-on-X-
a. If a session is waiting on the wait event ‘cursor: pin S wait on X’, the session is most likely trying to execute a cursor (pin S), and must wait as another session (who is most likely parsing the cursor) has it pinned X (wait on X)
b. the mutex holder was hung due to a bug not related to mutexes, causing requestors to back up behind the holder.
+ latch: row cache objects
参考,
http://sites.google.com/site/embtdbo/wait-event-documentation/oracle-library-cache#TOC-latch:-row-cache-objects
鄙人刚刚解决了一个latch: cache buffers chains的故障, 过两天,也仿照你的格式,写一篇博客.