在图中，请注意红色矩形中高亮显示的量度。您可以看到在 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”的选项卡是常用维护活动 — 如备份和恢复、数据导出或导入（数据泵）、数据库克隆以及更多活动 — 的启动控制台。在该画面上，您还可以对策略验证警报所基于的最佳实践的基本原理进行编辑。
　　结论
　　如先前所述，这篇文章所涉及的只是巨大冰山的一角。在本文中，我的目的不是为了提供全面的概述；而是希望提供对一些跨多个技能集的特定活动的快速浏览。