案例分析：事情的开始是这样的

今天晚上和客户一起喝了点酒，微醺，我觉得我也可以学习一下白鳝，写点小说一样的文字。

我喜欢看狄仁杰，不是刘德华版本的，刘德华的版本太年轻了，电视版的梁冠华成为了一个象征，我喜欢狄仁杰的一句话：事情是这样的......
然后镜头开始回放，狄仁杰的推理开始演绎。

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同时出现。
这一过程无法排解。

请大家推演一下，这种情况如何能够出现？如果需要其他信息，我可以进一步提供。我们一起来重走一下长征路。