共享池和库缓存闩等待通常是由于大量的硬解析，在使用文本常量的应用程序中这是很频繁的;可以通过使用绑定变量，设置CURSER_SHARING为FORCE解决;通过查看V$SQLAREA.PARSE_CALLS识别SQL语句。

缓存缓冲链闩等待是由于低效的SQL语句引起的，当应用程序打开多个并行会话执行相同的语句查询相同的结果集时可以得到该冲突;另一个原因是热块在缓存缓冲中。可以查看V$SESSION_WAIT的P1RAW 列检查是否有热块在缓冲缓存中;可以通过EXP/IMP带热块的表，增加PCTFREE的值进行扩展;考虑减小具有许多热块的表的块(9i+)。

缓存缓冲LRU链闩等待是由于有大量的缓存缓冲活动。重复扫描大量低选择性的索引或者执行全表扫描的语句通常是主要原因;只能通过调整SQL.

行缓存对象闩保护数据字典，唯一方法是增加共享池的尺寸。

enqueue是应用于数据库资源的锁。它们由应用程序请求初始化，查询V$ENQUEUE_STAT查看各种信息。

最常见的enqueue等待是TX，模式号为6.是一种行级锁，通过V$LOCK确定阻塞者。另一种模式号为4，通常是主键强制或等待数据块中的一个ITL槽;查看V$SEGMENT_STATISTICS决定ITL等待的值，统计名为‘ITL waits’。通过使用较高的INITTRANS和PCTFREE重建对象修复该问题。

对于唯一键强制问题，会在多个用户同时向表插入相同的键时发生;方法是找出为什么应用程序允许用户同时尝试插入重复的键。

另一种常见的enqueue是等待ST Enqueue，每个数据库只有一个ST锁，方法是更改UET$和FET$请求该锁。使用本地管理表空间修复，使用TEMPFILE重建所有临时表空间修复，如果不能从字典管理表空间更改，增加所有高速增长的段的next extent分区尺寸，同时允许预分配分区。

另一种常见Enqueue是等待TM Enqueue，模式号为3.未索引外键是这种锁冲突的主要原因。如果应用程序显示使用LOCK TABLE语句也会发生这种锁，见V$SQLAREA.

通常是由于多个会话尝试读取块到内存中或者尝试将块钉在内存中时会发生。可以通过尝试降低级别或并行性，或增加对象的FREELISTS/FREELIST GROUPS;也可以尝试重建表使用较小的块或增加PCTFREE的值减少表中的行数。

如果主要等待是段头，检查NEXT分区的大小并确保PCTFREE和PCTUSED之间的gap不会太大;如果主要等待是撤销段头，可能是由于有太多的小的回滚段，考虑使用系统管理撤销。

诊断延迟相关的等待事件

当会话等待LGWR写出缓冲时会发生这种情况，主要有三个原因：高提交率—应用程序相关，I/O子系统太慢—考虑RAW，RAID 0，光纤通道，过大的日志缓冲。同时参数PROCESSES过大可能也会造成该事件等待增加。

如果由于空间不足或LGWR进程不够快，会话等待拷贝重做条目到日志缓冲时会发生这种情况。如果是日志缓冲太小，则考虑增加它;如果是I/O子系统太慢—考虑使用NOLOGGING或升级硬件。

当DBWR正在从SGA写出藏块时会发生该等待。

主要原因有：编写得很差的SQL，DBWRs不够，较慢的I/O，延迟块清除，较小的缓冲缓存。

延迟的块清除：第一个扫描刚被加载的表的进程将会进行该工作，全表扫描刚加载的表可以最小化该问题，或者分析这些数据也可以解决。

缓冲缓存太小通常不是问题，在增加它之前考虑增加DBWR.

是前台进程等待DBWR写出块的征兆。检查db file parallel writes事件的情况。

当重做日志太小并且事务产生大量的重做日志条目时会发生这种事件。可以通过创建更大的日志文件或可以通过创建更多的重组日志组完成。

还有一些10g新增的等待事件和RAC环境下的等待事件。

Dumps和Traces

。主要是ORA-0600和核心ORA-7445事件;

。作为一个DBA，必须熟悉ORADEBUG，可以通过oradebug dumplist和oradebug help得到帮助，该工具没有文档。

。遇到块中断时需要dump数据文件和块：

。控制文件也可以被dump，当跟踪恢复相关的问题和SCN同步问题时可能会有用。

或：

。共享池有问题时通常需要DUMP堆。

或：

。库缓存DUMP会给出库缓存中关于对象的详细信息。

或

。当诊断内存中断或死锁错误时可以使用DUMP进程状态。

。当诊断数据库挂起条件时可以DUMP系统状态。

或：