Oracle AWR夺命33问，你能过几关？-优快云博客

本文链接：https://blog.youkuaiyun.com/chenoracle/article/details/149660181

筛选了MOS上有关AWR相关的16篇文章，方便学习，文章标题如下:

01.常见问题_如何使用AWR报告来诊断数据库性能问题 1523048.1.pdf
02.Automatic Workload Repository (AWR) Reports - Main Information Sources (Doc ID 1363422.1).pdf
03.AWR Report Interpretation Checklist for Diagnosing Database Performance Issues (Doc ID 1628089.1).pdf
04.AWR Reporting - Licensing Requirements Clarification (Doc ID 1490798.1).pdf
05.AWR Snapshots and Reports from Oracle Multitentant Database(CDB, PDB) (Doc ID 2295998.1).pdf
06.Disabling and Uninstalling AWR (Doc ID 1909073.1).pdf
07.FAQ Automatic Workload Repository (AWR) Reports (Doc ID 1599440.1).pdf
08.How to Generate an AWR Report and Create Baselines (Doc ID 748642.1).pdf
09.How to Read Buffer Cache Advisory Section in AWR and Statspack Reports. (Doc ID 754639.1).pdf
10.How to Use AWR Reports to Diagnose Database Performance Issues (Doc ID 1359094.1).pdf
11.Snapshot Not Updated When Generating Automatic Workload Repository (AWR) And ASH Reports (Doc ID 2414754.1).pdf
12.Troubleshooting 'latch cache buffers chains' Wait Contention (Doc ID 1342917.1).pdf
13.Troubleshooting High Version Count Issues (Doc ID 296377.1).pdf
14.Troubleshooting Library Cache - Lock, Pin and Load Lock (Doc ID 444560.1).pdf
15.Troubleshooting Understanding and Tuning the Shared Pool (Doc ID 62143.1).pdf
16.Why Executions and Elap per Exec(s) are 'Blank' in AWR for Some SQL Statements (Doc ID 1522547.1).pdf

关注“DBA面试宝典”知识星球，可以下载文章合集。

::: hljs-center

Oracle AWR夺命33问：

:::

下面内容，主要翻译自《FAQ Automatic Workload Repository (AWR) Reports (Doc ID 1599440.1).pdf》

问题1:

应用程序用户抱怨数据库缓慢，我该怎么办？ / 如果我想用 AWR 快速检查性能问题的原因，主要需要检查哪些内容？
解答:
首先，我们建议您检查该时间段 ADDM 报告的结果并实施其建议。
然后查看 AWR 报告。
非常快速地获取一些背景信息：查看版本以了解您正在处理的内容，然后查看 Elapsed time（实际耗时）和 DB time（数据库时间）以确定数据库承受的负载量。
然后查看系统上发生的前台等待事件。如果可能，将其与负载相似的另一个报告进行比较。然后寻找大多数等待起源的总体领域。例如，如果前 5 个等待事件是：

library cache load lock (库缓存加载锁)
cursor: pin S wait on X (游标：pin S 等待 X)
row cache lock (行缓存锁)
latch: row cache objects (闩锁：行缓存对象)
library cache: mutex X (库缓存：互斥锁 X)
根据这些信息，判断大部分问题与什么相关。查看事件名称可以得到一些线索：“library cache”和“cursor”与解析有关。“row cache”与字典信息的内存缓存有关。由此您可以推断大部分时间花在解析和操作字典对象上——现在您可以使用这个信息来指导调查的下一阶段。现在选择一个等待事件并解决它：从最严重的瓶颈开始，因为这会带来最大的收益。进行更改后，检查对系统的影响。将其与之前的时段和基线进行比较。重复此过程，直到达到可接受的性能。

问题2:

AWR 中的 DB Time（数据库时间）代表什么？
解答:
DB Time 是 AWR 报告期间数据库会话和进程使用的时间。

问题3:

为什么报告顶部的 DB Time（数据库时间）会超过 Elapsed Time（实际耗时）？
解答:
在现代多处理器系统上，多个数据库调用可能同时发生。例如，如果有四个负载很重的 CPU，那么在一个小时的实际耗时内，DB Time 可能的上限是 240 分钟（4x 60 分钟。

问题4:

在 AWR 报告中如何考虑多个 CPU？
解答:
在报告顶部附近，“CPUs” 反映线程数。“Cores” 是物理 CPU 的数量。

问题5:

在负载概要 (Load Profile) 中，如何解读 DB Time(s) 63.8 (64) 秒对比 DB CPU(s) 1.8 秒？
解答:
在报告顶部附近，AWR 报告了一些统计数据，其中包括：

Elapsed time（实际耗时）（这是挂钟时间）
DB Time（数据库时间）（这是实际耗时期间数据库内部使用的总时间）
例如，您可能会看到：
Elapsed : 60.68 (分钟)
DB Time : 3,856.09 (分钟)
这意味着每经过一分钟的实际耗时，数据库中就完成了 63.6 分钟的工作 (3,856.09 / 60.68)。这个数字在负载概要部分以 DB Time(s)（每秒数据库时间）的形式报告（以秒为单位），同时报告每秒使用的 CPU 量 (DB CPU (s))：
DB Time(s): 63.6 (每秒)
DB CPU (s): 1.8 (每秒)
在多 CPU 系统上，您可用的总 CPU 时间（假设 100% CPU 使用率）将是：每秒 CPU 数量。
换句话说，如果您有 8 个 CPU，那么每秒可能使用 8 秒的 CPU 时间。在本例中，DB CPU (s) : 1.8 (每秒) 报告系统使用了 1.8 秒的 CPU，而它可能使用的潜在 CPU 是 8 秒（即使用了 CPU 容量的 1/4）。这意味着每秒 61.8 秒的 DB Time 不在 CPU 上，因此是其他原因（例如等待）。作为关联，这应该反映在该时段的操作系统 CPU 统计信息中。
就解读而言，“DB Time(s): 63.6 (每秒)” 意味着系统负载很重，“DB CPU (s): 1.8 (每秒)” 意味着大部分时间不是 CPU 时间，而是其他原因（如等待）。
值 63.6 也可以解释为在由两个 AWR 快照收集时间界定的实际耗时期间的平均活动会话数。实际上，仅根据数据库时间 (Database_Time) 和实际耗时 (Elapsed_Time)，您可以将平均活动会话数计算为 Database_Time 除以 Elapsed_Time。在本例中，3,856.09 除以 60.68 约等于 63.6。

问题6:

AWR 报告中的“实例 CPU (instance CPU)”和“主机 CPU (host CPU)”部分有什么区别？
主机 CPU 信息直接来自操作系统，反映整个机器上的 CPU 使用情况。实例 CPU 反映实例本身使用的 CPU。

问题7:

“User calls”（用户调用）和 “Parses”（解析）是什么意思？
解答:
解析调用 (Parse calls) 是对呈现给数据库的 SQL 语句进行解析的请求。用户调用 (User calls) 是用户会话对数据库的调用。解析调用是用户调用的一个子集。

问题8:

为什么报告不关注游标等待 (cursor waits)？
解答:
AWR 着眼于整个系统，而不是游标级别。如果您想查看单个游标的等待，可以使用 ASH 报告或 10046 跟踪。

问题9:

SQL 区域中的“无效 (Invalidations)”或“重新加载 (Reloads)”是否表明缓存不足？
解答:
在大多数情况下，无效或重新加载表明应用程序内部的共享效率不高，而不是需要调整共享池内存区域。如果游标未被共享，内存将被游标填满，需要回收空间以容纳新游标。然后可能会移除现有的游标，而在下次执行时又必须重新加载它们。添加更多空间只是意味着可以存储更多未共享的游标，并不能缓解压力。在考虑添加更多内存之前，请调查共享效率

问题10:

如何处理 RAC 上 ‘Buffer Busy Waits’（缓冲区忙等待）的高等待？
解答:
从 AWR 报告的“GC Buffer Busy”等待部分识别热点块。

问题11:

为什么我的存储管理员告诉我，存储设备报告的响应时间测量值表明文件的平均读取时间 (“Av Rd(ms)”) 远低于 AWR 中报告的值？
解答:
与任何其他应用程序一样，Oracle 数据库一旦提交 I/O 请求，就无法感知操作系统代码内部发生的情况。它所能做的只是测量请求的开始和结束时间。Oracle 数据库无法知道在除了实际的寻道时间、旋转延迟和传输时间之外，以下一个或多个事件是否消耗了时间，因为操作系统不会向应用程序报告该级别的细节：
1.将换出的进程恢复到内存所需的交换时间 (Swap time)。
2.在操作系统中断检测到读请求已完成并将线程标记为可运行之后，发出读请求的线程在运行队列中等待 CPU 的时间。
3.I/O 排队 (I/O queuing)。“iostat”的输出将在标记为 “avgqu-sz”（平均队列大小）的列下显示平均队列长度。

问题12:

能否使用 AWR 报告来识别由于硬件物理限制或配置/SQL 问题导致的数据库性能问题？
解答:
像往常一样从 Top 5 等待事件开始。对于 I/O 问题，您会期望 I/O 等待事件（如 ‘db file sequential read’ 和/或 ‘db file scattered read’）很高。请注意，I/O 问题可能影响整个系统，也可能仅限于单个磁盘，因此根据活动情况，您可能会看到某些等待的性能缓慢，而其他等待则没有。
如果您在以下部分看到 I/O 相关等待事件的数量很高以及平均读/写时间很高：

IO 统计信息 > 表空间 IO 统计信息 (IO Stats > Tablespace IO Stats)
IO 统计信息 > 文件 IO 统计信息 (IO Stats > File IO Stats)
那么您可能会怀疑 I/O 子系统存在一些问题。这可能是因为它性能缓慢，或者可能被数据库外部的力量过度施压，或者可能来自数据库的过量 I/O。如果 I/O 来自数据库，那么您会期望在“Top SQL”部分看到负责此操作的 SQL。查看：
SQL 统计信息 > 按读取排序的 SQL (SQL Statistics > SQL ordered by Reads)
并查找物理读取 (Physical Reads) 过多的查询。这可能是由一次大规模执行或大量较小执行（或两者结合）引起的。

问题13:

在 AWR 效率百分比中，“Parse CPU to Parse Elapsed %”（解析 CPU 占解析耗时百分比）我们持续获得非常低的百分比（例如 0.3%），但所有其他效率百分比都 >95%
仅查看效率百分比可能会导致危险的假设。始终从 Top 5 等待事件开始，并由此展开工作。如果没有性能问题，并且您在目标服务级别内运行，那么某些比率不是“最佳”是否重要？
解析耗时 (Parse elapsed time) 应该主要是 CPU 时间，但是，对于动态采样 (dynamic sampling) 之类的事情，其他等待可能会占用时间。如果您已确定这导致了问题，那么您应该跟踪会话（使用 10046 level 8）以查看另外 99.7% 的解析时间花在了哪里。

问题14:

AWR 报告是否提供任何并行查询 (PQ) 统计信息/使用情况？
解答:
是的。它报告 PX 等待事件，因此您可以看到等待它们所花费的时间。这可以帮助您评估这是否合理或花费的时间是否过长。
在“实例活动统计信息 (Instance Activity Stats)”下还显示了与并行查询相关的统计信息，例如 “PX local messages recvd”（接收的本地 PX 消息）、“PX local messages sent”（发送的本地 PX 消息）、“Parallel operations downgraded to …”（并行操作降级为…）

问题15:

AWR 中的建议部分有多准确？
解答:
建议部分基于运行报告所针对的特定快照时段收集的数据。因此，它们根据实际收集的证据提供良好的建议。如果您选择采纳建议，与任何更改一样，应进行验证、测试并运用常识。

问题16:

如果我们发生死锁，能否在 ADDM、AWR 或 ASH 报告中找到？
解答:
不能。这些报告不适用于此目的。如果发生死锁，您可能会看到比平时更多的队列 (enqueue) 等待，但如果只涉及几个会话，在整个系统的背景下这可能微不足道。

问题17:

为什么有时 SQL 的执行次数等于零？
解答:
如果长时间运行的 SQL 语句的执行次数等于零，但您发现耗时 (elapsed time) 和 CPU 时间 (CPU time) 有值，那么您知道发生了以下情况之一：
SQL 语句在开始和结束快照 ID 之间的某个时间开始执行，但未在该时间间隔内完成。
SQL 语句在第一个快照 ID 的时间之前已经开始执行，并且在结束快照 ID 的时间尚未完成。
为了查看语句完成（以及该语句消耗的全部时间），您需要扩展快照 ID 值的范围，直到找到一个列出执行次数 (Executions) 至少为 1 的 AWR 报告。

问题18:

ADDM/ASH 与 AWR 有什么关系？
解答:
AWR 是自动记录工作负载信息的存储库。此工作负载信息包含有关整个数据库以及各个会话的信息。它可以以不同的方式报告。AWR 报告生成显示给定时间段内整个数据库 AWR 基础统计信息的输出。ADDM 报告使用给定时间段内整个数据库的 AWR 信息，以更易读的建议形式呈现结果（以报告形式）。
ASH 报告基于活动会话历史记录 (Active Session History) 而不是整个数据库生成输出。
从 Oracle 版本 12c 开始，默认情况下，AWR 报告包含 ADDM 和 ASH 报告信息。

问题19:

就 ADDM 和 SGA 大小调整而言，ADDM 似乎总是建议 SGA 大小不足，这作为指标有多可靠？是否有更好的方法确定最佳 SGA 大小？
解答:
ADDM 报告的工作基础是您查看它是因为您有性能问题。这意味着如果它看到没有足够的内存来存储所有内容，它会比平时更严格。存在一种误解，认为它“总是建议 SGA 大小不足”。事实并非如此。如果您遇到内存问题，那么此信息将很有用。如果您没有遇到内存问题但有其他问题，那么此建议可能不太重要。基于自动化信息很难区分 SGA 是否产生影响的情况，因此如果存在短缺就会报告，然后可以根据需要进行处理。
AWR 报告中的 SGA 目标建议 (SGA Target Advisory) 提供了有关预计更改 SGA 大小所带来差异的更多信息。

问题20:

如何确认我的数据库是否分配了足够的内存？
解答:
AWR 报告的“建议统计信息 (Advisory Statistics)”部分是一个很好的起点。但是，一般来说，如果您没有太多缓冲区（内存中的数据块）等待或重新加载（语句文本），那么您就有足够的内存。
ADDM 也会为相关的 AWR 报告时段提供建议。