全网最全面的Oracle AWR 专栏，持续更新中...
在分析AWR报告中的"SQL Statistics"章节前，首先要搞清楚：这些被捕获的SQL语句，在多大程度上是否能代表整个系统的负载？
在这个例子中，我们会看到：
捕获到的SQL仅占总DB Time的0.2%
在这种情况下，继续分析"Top SQL"列表几乎是浪费时间，因为它仅反映了极少一部分的系统工作量。
不过，判断"SQL ordered by Elapsed Time"列表的代表性并不那么简单。
列表中显示的百分比，反映的是捕获SQL占DB Time的比例，而不是SQL执行时间的比例。
在下面的例子中，Oracle显示捕获的SQL占总DB Time的59.2%。
乍一看，好像有40.8%的SQL执行时间没有被捕捉到。
但实际上，DB Time并不等同于SQL执行时间。
在这个例子中，我们查看AWR报告中的"Time Model Statistics"部分，可以发现"sql execute elapsed time"仅占DB Time的67.83%。
这意味着被捕获的SQL最多能占到全部负载的67.83%------而不是100%。
换算后，59.2 ÷ 67.83 ≈ 87%。
也就是说，捕获SQL实际上代表了约87%的SQL执行时间，这实际上是一个高度具有代表性的样本。
另一方面，捕获的PL/SQL执行时间占DB Time的67.5%，这表明大部分SQL实际上是在PL/SQL过程中执行的，且主要的PL/SQL过程都已被成功捕获。
捕获SQL比例越高，Top SQL列表的分析价值越大；反之则越低。
对于"SQL ordered by Elapsed Time"列表，建议始终将DB Time比例换算成SQL执行时间比例，才能判断其真正代表性。
另一个需要注意的问题是：Oracle不会把COMMIT和ROLLBACK视为普通SQL语句。
如果包含它们，COMMIT几乎总会出现在列表头位（类似MySQL的情况）。
此外，Oracle只会捕获在AWR快照时仍驻留在shared pool中的SQL语句（可在V$SQL等视图中查看）。
当捕获比例偏低时，常见的两种原因是：
- 快照间隔太长：SQL可能在快照生成前被 aged out。解决方法是缩短AWR快照间隔。
- SQL语句过于异构（未使用绑定变量）：一个常见的现象是某些应用动态拼接SQL字符串，这样会导致生成大量"异构SQL"，把shared pool挤满，使得许多SQL在快照生成之前就被挤出shared pool。如果遇到这类问题，可以查看ASH报告中的"Top SQL using literals"部分，通常会找到线索。
号主在certview.oracle.com网站上的证书清单截图。
关于号主，姚远：
- Oracle ACE（Oracle和MySQL数据库方向）
- 华为云最有价值专家
- 《MySQL 8.0运维与优化》的作者
- 拥有数十项数据库认证
- 曾任IBM公司数据库部门经理
- 20+年DBA经验，服务2万+客户
- 精通C和Java，发明两项计算机专利
- 两次获得国家部级奖