通过比较图形“Sessions:Waiting and Working”与尖峰发生的时间，我们可以看到，大部分会话都在“Application”等待类上进行等待。但是我们需要确切地查明它在该时期内正在等待什么？单击该时间的区域，调出活动会话画面，如图 8 所示。
该画面显示会话正在等待的等待事件是 enq:TX ?row lock contention。那么导致此问题的 SQL 语句是什么？很简单：画面本身显示了语句 8rkquk6u9fmd0 的 SQL ID（在红色圆圈中）。单击该 SQL ID，调出如图 9 所示的 SQL 画面。
在该画面上，您可以看到关于它的 SQL 语句以及相关的详细信息，包括执行计划。它表明，这条 SQL 导致行锁争用，因此应用程序设计可能是问题的根源。
栓锁争用
假设单击“Performance”选项卡出现类似图 10 所示的画面。
在图中，请注意红色矩形中高亮显示的量度。您可以看到在 12:20AM 左右有很多与 CPU 相关的等待，这导致在 CPU 中出现庞大的运行队列。我们需要诊断这一等待。
首先，单击显示 CPU 争用区域的图形（在图上标有“Click Here”），以详细查看该特定等待，如图 11 所示。
注意在“Active Sessions Working:CPU Used”图形中带阴影的框 (1)。您可以使用鼠标拖动它来放置焦点。此操作导致以下的饼形图（2 和 3）只在该框所包含的时段内进行计算。在这里我们看到，一个具有 id 8ggw94h7mvxd7 的特定 SQL 正在非常困难地运行 (2)。我们还看到，具有用户名 ARUP 和 SID 265 的用户会话是最主要的运行会话 (3)。单击该会话，查看其详细信息。此操作调出“Session Details”画面。单击选项卡“Wait Events”，调出该会话所经历的等待事件的详细信息，其画面类似于图 12 所示。
在该画面中，请注意在红色圆圈中高亮显示的 118 厘秒的最长等待，它在等待库高速缓存。当您单击“Latch:Library Cache”的超链接时，将会看到类似图 13 所示的画面。
该画面提供了 10g 数据库之前所没有提供的一些独特信息。在诊断这个栓锁争用问题时，如何知道这 118 厘秒的等待是由几个会话中的多个小等待组成，还是只是由一个会话中的一个大等待组成，从而使数据出现偏差呢？
在这里，直方图可以帮助我们。从图上看，您知道大约 250 次会话拥有 1 毫秒的等待（在圆圈中高亮显示）。会话在 4 与 8 毫秒之间的某处等待了大约 180 次。该画面显示，这些等待的时间通常很短，因而它们不是栓锁争用的主要症状。
在数据库主页上，您可以通过单击标为“Advisor Central”的选项卡来访问 ADDM、SQL Access Advisor 以及其他顾问程序。ADDM 在收集量度时自动运行，并且结果立即发布在 Advisor Central 页中；当单击该页时，将显示由 ADDM 给出的建议。SQL Tuning Advisor 也检查这些量度，并在此页上发布其建议。（我们将在以后的文章中更加详细地研究 ADDM 和 SQL Tuning Advisor。）
简化维护
数据库主页上标为“Maintenance”的选项卡是常用维护活动 — 如备份和恢复、数据导出或导入（数据泵）、数据库克隆以及更多活动 — 的启动控制台。在该画面上，您还可以对策略验证警报所基于的最佳实践的基本原理进行编辑。
结论
如先前所述，这篇文章所涉及的只是巨大冰山的一角。在本文中，我的目的不是为了提供全面的概述；而是希望提供对一些跨多个技能集的特定活动的快速浏览