适用范围

问题概述

问题原因

根据技术人员的反映和之前的操作，我们第一分析就是检查分析当前系统资源使用情况，发现包括Cpu、IO、内存均使用正常，然后开始把焦点放在数据库本身。 首先，从数据库中抓取AWR报告，确认一下整体上的性能问题，整体数据库时间消耗如下：

  	Snap Id	Snap Time	Sessions	Cursors/Session
Begin Snap:	21589	28-Dec-12 09:00:23	107	3.9
End Snap:	21590	28-Dec-12 10:00:25	131	4.0
Elapsed:	 	60.04 (mins)	 	 
DB Time:	 	532.21 (mins)	 

我们可以看到，一共收集了60分钟的报告，DB TIME即数据库实际运行时间占到了532分钟，即相当于差不多9个线程核的CPU满负载运行。根据我们对这套系统了解，业务量一般不大，数据库压力也不大，我们暂时确认是数据库整体上性能问题，并判断可能是锁（包括lock锁和Latch锁）资源等待问题，然后进一步看等待事件：

    Event	Waits	Time(s)	Avg wait (ms)	% DB time	Wait Class
row cache lock	5,919	27,841	4704	87.19	Concurrency
DB CPU	 	754	 	2.36	 
cursor: pin S wait on X	268	510	1904	1.60	Concurrency
direct path read	46,380	39	1	0.12	User I/O
log file sync	9,699	12	1	0.04	Commit

参考：row cache lock 解释： Row Cache Lock： When DDLs execute, it must acquire a row cache latch to lock the Data Dictionary information. The shared pool contains a cache of rows from the data dictionary that helps reduce physical I/O to the data dictionary tables. This allows locking of individual data dictionary rows. 我们根据后台等待事件发现，row cache lock等待事件占了87%以上，占了运行时间27841秒，相当于约450分钟以上，占了所有运行时间的约87% 。理论上这个事件是不能出现在TOP 5事件中的，说明当前系统性能差、数据库运行时间消耗时间长都是由row cache lock等待事件引发起。我们再去看整体时间使用模型：

  Time Model Statistics
•	Total time in database user-calls (DB Time): 31932.9s
•	Statistics including the word "background" measure background process time, and so do not contribute to the DB time statistic
•	Ordered by % or DB time desc, Statistic name
Statistic Name	Time (s)	% of DB Time
parse time elapsed	25,552.00	80.02
hard parse elapsed time	24,988.46	78.25
sql execute elapsed time	6,906.29	21.63

根据时间模型数据，可以看到60分钟之内，用于SQL或PLSQL解释的时间就占了80%以上，即25552秒，我们可以推测出由于与共享池相关的row cache lock等待事件导致了SQL解释出现问题，并最终大量的SQL运行变成缓慢，从于引发了系统的整体上性问题。 我们继续深入分析，通过hanganalyz level 3进行跟踪，得到相关TRACE文件，关键内容如下：

  HANG ANALYSIS DUMPS:
  oradebug_node_dump_level: 3
 State of LOCAL nodes
([nodenum]/cnode/sid/sess_srno/session/ospid/state/[adjlist]):
[101]/1/102/269/0x29c6a57f0/942/NLEAF/[349]