调优排故方法论
引例：
以SQL语句的执行为例，语句的执行分为3个部分：解析执行和抓取。解析又分为软解析和硬解析。硬解析需要生成执行计划，并将执行计划传到共享池中。软解析直接在共享池中取出计划即可。假设此时出现了许多的Shared Pool Latch竞争这个分析过程如下：
Share Pool Latch的申请主要出现在进程从共享池中分配内存的时候。在整个SQL的执行过程中什么时候需要从共享池分配内存？
执行的时候不会，抓取的时候主要从磁盘或者Buffer Cache中读数据这也不会。解析过程中，软解析不会只是查找、读取共享池中的执行计划。而硬解析需要将新生成的执行计划存入共享池，在存入之前肯定需要在共享池中先分配一块内存才能将信息存进去。
结果分析：
通过对原理的了解对于Shared Pool Latch的竞争的原因：由于只有在进行硬解析的时候才会从共享池分配内存，因此Latch的竞争很有可能是由于过多的硬解析造成的。但是除了硬解析，还有其他情况也会持有Share Pool Latch比如自动调节内存时，如果启动了内存自动调节，当oracle觉得共享池内存不足或太多的时候，也会持有Shared Pool Latch、调节共享池内存大小，这也会导致Share Pool Latch竞争。
结论：
按照Oracle工作原理判断问题出现在哪个环节，要对原理全面分析，防止判断偏离方向。
调优排故的一般步骤：
调优排故大都是从原理的角度分析问题可能出现在哪个环节，oracle提供了很多工具如：
DBA_ 系列视图，可以查阅“数据定义”类的元数据信息
V$ 系列视图，可以查阅SGA中的状态，V$的底层X$还提供了更加详细的信息
各种跟踪事件，DUMP命令等
- 1.常见的DUMP和Trace文件：
Oracle的问题可以分为两大类：性能问题和故障。性能问题通常是对用户的反应慢，而故障多是指异常宕机或其他异常情况。
遇到故障最好的调查入口就是，DUMP文件和Trace文件。
按照存放位置的不同，DUMP和Trace文件分为3类：后台进程DUMP文件，核心DUMP文件和用户DUMP文件。他们对应参数background_dump_dest、core_dump_dest、user_dump_dest所在的位置。Oracle11g后这三个参数在一个位置。这其中最重要的就是background_dump_dest中的告警日志文件。如图为10g参数设置：
- 2.等待事件：
对于性能问题，等待事件是首先需要被关注的，并不是只有在发生等待时才有Event。Event的目的是告诉我们Oracle此时郑子啊做什么而不能将其单纯的看为等待。
oracle中的等待事件按照工作原理可分为两类，一类是主动触发事件，另一类是被动触发事件。
例如Oracle完成一个I/O操作时，它知道I/O不会很快完成于是会主动登记一个事件然后在进行I/O操作。（与IO有关的事件都是主动触发的）
主动事件特点：只要发生一次IO就一定对应了一个等待事件。无论这个IO的速度有多快。
但如果一个动作非常快，例如Latch的获取。在获取一个Latch前进程不会主动等待一个事件，只有当遇到阻塞、获取不到时，才会记录等待事件，诸如这种就是被动事件。除了IO相关，网络相关外的事件基本都是被动事件。
等待事件的查询：
v$session v$session_event v$system_event v$session_wait等视图查看。
挖掘等待事件的方法：
首先查看警告日志文件。Oracle生成的重要的trace文件会在警告日志文件中记录。找到告警日志后，再在其中找trace文件，因为在trace文件中，通常可以找到Call Stack Trace，也就是运行堆栈。运行堆栈是当出现问题时Oracle进程自身调用的函数信息。Oracle10g和11g都是用内部自定义函数kslwait登记等待事件的。在trace文件的运行堆栈中，查找是否有kslwait函数的调用，如果有就可以确定在数据库宕机时最后的等待事件是什么。 - 3.各种资料视图：
v$sysstat v$sesstat v$statname数据出现问题，网络一定会出现一些异常，从网络曲线图入手有什么变化那么数据一定会有反馈。
具有特殊含义的指标：
Redo entries（重做条目数）：用来记录Oracle一共生成了多少条Redo Recoder。根据redo信息的生成流程，只有在redo相关数据被传送到Log buffer后这些数据才会被组装成Redo Recoder。换句话说当Redo相关的数据被传送到Log Buffer时，这些数据才被成为Redo Recoder。
由此可见，有一条Redo Recoder就说明向Log Buffer传输过一次redo数据。Redo Recoder的数量代表了向Log Buffer中写数据的次数，这就是Redo entries的意义。
- 4.等待事件的注意事项：
在使用v$session查询等待事件的时候，要把state列带上。这样才能确定此等待事件是否真的还在进行。
案例中利用相同的两个存储过程，同时快速访问相同的快造成latch:cache buffers chains等待事件
SYS@proe>select sid,seq#,event,state from v$session where wait_class <> 'Idle' order by event;
如果显示不是waiting则。说明此等待事件已经结束