一、适用范围

本文适用于以下 Oracle 数据库版本：

• Oracle Database 11g
• Oracle Database 12c
• Oracle Database 19c
• Oracle AI Database 26ai

Oracle 提供了从性能数据采集、问题诊断、SQL 调优、变更验证到操作系统监控的一整套工具。实际工作中，不应依赖某一个报告判断问题，而应建立完整的分析链路：

发现异常 → 确定瓶颈时间段 → 定位等待事件和高负载 SQL → 分析执行计划 → 实施优化 → 验证效果

需要注意，不同功能的适用版本、数据库版本类型、部署平台和授权要求并不完全相同。AWR、ASH、ADDM、SQL Monitor 等功能即使已经安装在数据库中，使用时也可能需要 Oracle Diagnostics Pack、Oracle Tuning Pack 或 Oracle Real Application Testing 许可。

二、自动性能监控与诊断工具

2.1 AWR：Automatic Workload Repository

AWR，即自动工作负载信息库，是 Oracle 数据库历史性能数据采集和分析的基础。

AWR 按照一定时间间隔创建快照，记录两个快照之间的性能变化，主要包括：

• DB Time 和 DB CPU
• 前台等待事件
• 系统与会话统计信息
• 高负载 SQL
• 逻辑读和物理读
• 内存使用情况
• I/O 性能
• 段访问统计
• 服务和模块负载
• RAC 实例间通信情况

AWR 适合分析以下问题：

• 数据库在某个历史时间段为什么变慢
• 系统升级或变更前后性能是否发生变化
• CPU、I/O 或并发等待是否出现异常
• 哪些 SQL 消耗了最多的数据库时间
• 执行计划变化是否引发性能下降
• 当前性能是否偏离历史基线

生成单实例 AWR 报告：

@?/rdbms/admin/awrrpt.sql

RAC 环境中可以生成全局 AWR 报告：

@?/rdbms/admin/awrgrpt.sql

AWR 不是简单记录某一时刻的累计值，而是利用快照之间的差值分析负载。Oracle 官方将 AWR 定位为性能问题检测和数据库自我调优所需的性能统计信息存储基础。

2.2 ADDM：Automatic Database Diagnostic Monitor

ADDM，即自动数据库诊断监视器，以 AWR 采集的数据为基础，对数据库性能进行自动分析。

它主要从 DB Time 的角度判断哪些问题对数据库整体性能影响最大，并给出相应建议，例如：

• CPU 资源不足
• I/O 响应时间过高
• 高负载 SQL
• 硬解析过多
• 共享池配置不合理
• Buffer Cache 配置不合理
• 锁竞争和并发等待
• RAC 集群相关等待
• 数据库配置问题
• 应用连接或提交过于频繁

ADDM 不仅描述发生了什么，还会尝试说明问题影响、可能原因、预计收益和处理建议。

生成 ADDM 报告：

@?/rdbms/admin/addmrpt.sql

ADDM 适合数据库级别的宏观诊断，但不能完全替代人工分析。对于持续时间很短、发生在两个 AWR 快照之间的性能抖动，通常还需要结合 ASH 分析。

2.3 ASH：Active Session History

ASH，即活动会话历史，用于记录数据库中活动会话的采样信息。

Oracle Database 10g Release 1 开始提供 ASH，并将部分 ASH 采样通过 AWR 快照持久化到 DBA_HIST_ACTIVE_SESS_HISTORY。Oracle 10g Release 2 官方文档已经明确提供独立的 ashrpt.sql 和 ashrpti.sql 报告脚本。

需要区分以下概念：

• V$ACTIVE_SESSION_HISTORY：保存内存中的近期 ASH 采样；
• DBA_HIST_ACTIVE_SESS_HISTORY：保存由 AWR 持久化的部分历史 ASH 采样；
• ASH Report：针对指定时间范围生成的独立活动会话分析报告；
• AWR Report：分析两个 AWR 快照之间的数据库整体负载，并不等同于 ASH Report。

ASH 可以帮助回答以下问题：

• 某一分钟内数据库主要在等待什么
• 哪条 SQL 在故障时段占用资源最多
• 哪个用户、模块、服务或客户端产生了负载
• 哪个会话阻塞了其他会话
• SQL 主要消耗在 CPU 还是等待事件
• RAC 环境中是否存在集群块访问问题
• 性能问题是否集中在特定对象、文件或数据块上

生成 ASH 报告：

@?/rdbms/admin/ashrpt.sql

查询最近 10 分钟的主要活动：

SELECT event,
       session_state,       COUNT(*) AS samplesFROM   v$active_session_historyWHERE  sample_time > SYSTIMESTAMP - INTERVAL '10' MINUTEGROUP BY event, session_stateORDER BY samples DESC;

ASH 特别适合分析持续时间较短、未能在 ADDM 中充分体现的瞬时性能问题。

2.4 服务器生成的预警

Oracle 可以根据预设阈值或动态基线，对数据库运行状态进行监控并生成告警。

典型监控指标包括：

• 表空间和临时表空间使用率
• Undo 空间使用情况
• CPU 使用率
• 用户提交响应时间
• 每秒物理读
• 恢复区使用率
• 会话数量
• 阻塞会话

服务器告警适合主动发现异常，但它只能说明指标超过阈值，不能代替根因分析。收到告警后，仍需结合 AWR、ASH、动态性能视图和操作系统数据进行判断。

2.5 OEM：Enterprise Manager Cloud Control

Oracle Enterprise Manager Cloud Control，简称 OEM，是 Oracle 提供的集中式数据库管理和监控平台。

OEM 的主要功能包括：

• 数据库实时性能监控
• Top Activity 分析
• ASH Analytics
• SQL Monitor
• ADDM 结果展示
• AWR 历史趋势
• 阻塞会话分析
• 数据库告警管理
• 指标阈值设置
• 作业和备份管理
• SQL 调优工具入口
• RAC、Data Guard 和 Exadata 监控

OEM 更像一个集中展示和管理平台，其底层数据通常来自 AWR、ASH、ADDM 和动态性能视图。

三、数据库内置 SQL 优化工具

3.1 SQL Tuning Advisor

SQL Tuning Advisor 用于分析一条或多条高负载 SQL，并给出优化建议。

建议内容可能包括：

• 收集或更新对象统计信息
• 创建索引
• 调整 SQL 结构
• 创建 SQL Profile
• 创建或使用 SQL Plan Baseline
• 检查访问路径和基数估算

其输入可以来自 AWR、Shared Pool、SQL Tuning Set，以及 ADDM 发现的高负载 SQL。

SQL Tuning Advisor 主要利用优化器的深度分析能力识别统计信息、访问路径、执行计划或 SQL 结构方面的问题，并不等同于自动重写所有 SQL。

3.2 SQL Access Advisor

SQL Access Advisor 从一组 SQL 工作负载出发，分析是否应该调整数据访问结构，可能建议：

• 创建或删除索引
• 创建组合索引
• 创建物化视图
• 创建物化视图日志
• 对表进行分区
• 调整现有访问结构

二者的侧重点不同：

• SQL Tuning Advisor 侧重具体 SQL 及其执行计划
• SQL Access Advisor 侧重根据整体工作负载优化索引、分区和物化视图等访问结构

3.3 SQL Monitor

Real-Time SQL Monitoring 用于实时观察 SQL 的执行过程，特别适合分析长时间运行 SQL 和并行 SQL。

SQL Monitor 可以显示：

• SQL 执行时间
• CPU 和等待时间
• 每个执行计划步骤的实际行数
• 每个步骤的活动时间
• I/O 请求和读取字节数
• 并行进程工作分布
• 当前主要资源消耗步骤
• 估算行数和实际行数之间的差异

生成文本格式 SQL Monitor 报告：

SELECT DBMS_SQLTUNE.REPORT_SQL_MONITOR(
           sql_id       => 'SQL_ID',
           type         => 'TEXT',
           report_level => 'ALL'
       )FROM dual;

SQL Monitor 展示的是 SQL 执行期间的实际运行信息，而不仅仅是优化器的预估成本。

3.4 Automatic SQL Tuning

Automatic SQL Tuning 通常在自动维护窗口中运行，其基本过程如下：

1. 从 AWR 中选择高负载 SQL；
2. 调用 SQL Tuning Advisor 进行分析；
3. 生成统计信息、索引或 SQL Profile 等建议；
4. 对符合条件的 SQL Profile 进行验证；
5. 根据配置决定是否自动实施；
6. 生成自动 SQL 调优报告。

自动 SQL 调优适合持续发现日常工作负载中的高消耗 SQL，但生产环境仍应审慎评估自动实施的建议。

3.5 SQL Performance Analyzer

SQL Performance Analyzer，简称 SPA，主要用于评估系统变更对 SQL 性能的影响。

适合使用 SPA 验证的变更包括：

• 数据库版本升级
• 初始化参数调整
• 优化器版本变化
• 补丁安装
• 统计信息更新
• 索引创建或删除
• 数据库迁移
• 操作系统或硬件变更；
• SQL Profile 或 SQL Plan Baseline 调整

SPA 可以比较变更前后同一批 SQL 的性能，并将 SQL 划分为性能改善、基本不变、性能退化或执行失败等类型。

SPA 不能完全代表真实业务并发压力。如果需要验证完整并发工作负载，应考虑 Database Replay。

3.6 SQL Plan Management

SQL Plan Management，简称 SPM，通过 SQL Plan Baseline 控制 SQL 可以采用的执行计划，主要用于防止执行计划变化导致性能回退。

常见使用场景包括：

• 数据库升级前固定关键 SQL 计划
• 更新统计信息后防止计划退化
• 新索引上线时验证新计划
• 将测试环境中的优良计划迁移到生产环境
• 出现计划突变后恢复历史稳定计划

SPM 并不是禁止执行计划变化，而是允许数据库验证新计划。表现更好的计划可以在验证后加入 SQL Plan Baseline。

3.7 自动索引

Automatic Indexing 根据应用工作负载自动识别索引候选项，并进行创建、验证和管理。

典型过程如下：

1. 根据 SQL 工作负载识别候选索引
2. 将候选索引创建为不可见索引
3. 在受控环境中验证索引效果
4. 确认有性能收益后将索引设为可见
5. 管理没有收益或长期未使用的自动索引

自动索引在 Oracle Database 19c 中引入，但不代表所有 19c 及以上数据库都可以使用。它的可用性受到数据库版本类型、部署平台和许可政策限制。

3.8 SQL Quarantine

SQL Quarantine （19c引入该特性）用于隔离严重消耗资源的 SQL 执行计划，防止相同计划反复执行并持续消耗系统资源。

需要注意，被隔离的是特定 SQL 执行计划，而不一定是整条 SQL。SQL 生成其他执行计划后仍可能继续执行。

典型应用场景包括：

• SQL 持续占用大量 CPU
• SQL 产生异常高的物理 I/O
• SQL 运行时间超过 Resource Manager 限制
• 某个执行计划频繁拖慢系统
• 需要临时阻止危险执行计划再次运行

3.9 Real-Time Statistics

传统优化器统计信息通常通过 DBMS_STATS 定期收集。如果业务在短时间内写入大量数据，统计信息可能来不及更新，从而导致错误的基数估算和执行计划。

Real-Time Statistics 可以在常规 DML 过程中动态维护部分关键统计信息，降低统计信息过期带来的执行计划风险。

需要注意：

• Real-Time Statistics 不能完全替代 DBMS_STATS
• 数据库仍需定期收集完整统计信息
• 该功能在 19c 中引入
• 可用性受到数据库产品形态和许可限制

四、深度诊断与辅助工具

4.1 V$ 动态性能视图

V$ 动态性能视图是 DBA 观察数据库实时运行状态最直接的接口。

查询当前正在等待的非空闲会话：

SELECT sid,
       serial#,
       username,
       sql_id,
       event,
       wait_class,
       seconds_in_wait,
       blocking_sessionFROM   v$sessionWHERE  status = 'ACTIVE'AND    username IS NOT NULLORDER BY seconds_in_wait DESC;

动态性能视图反映的多数是当前状态或实例启动以来的累计信息。分析历史故障时，应结合 AWR 和 ASH，而不能只查看当前 V$ 视图。

4.2 DBMS_XPLAN 与实际执行计划

执行计划是 SQL 调优的核心依据之一。对于已经执行过的 SQL，应尽量查看实际执行计划，而不是只使用 EXPLAIN PLAN：

SELECT *FROM TABLE(
    DBMS_XPLAN.DISPLAY_CURSOR(
        sql_id          => 'SQL_ID',
        cursor_child_no => NULL,
        format          => 'ALLSTATS LAST +PEEKED_BINDS'
    )
);

重点关注：

• E-Rows：优化器估算行数
• A-Rows：实际返回行数
• Buffers：逻辑读
• Reads：物理读
• A-Time：实际运行时间
• 索引访问方式
• 表连接顺序
• Nested Loops、Hash Join 和 Merge Join 的选择
• 是否存在笛卡尔连接
• 是否发生大量回表、磁盘排序或 Hash Join 溢写

如果 E-Rows 与 A-Rows 相差很大，通常需要检查统计信息、数据倾斜、直方图、关联列、表达式谓词和绑定变量。

EXPLAIN PLAN 展示的是解释时预计采用的计划，可能与 SQL 真正执行时使用的计划不同。

4.3 Alert 日志、Trace 与 TKPROF

数据库日志和 Trace 是分析内部错误、异常等待和复杂 SQL 性能问题的重要证据，主要包括：

• Alert 日志
• 后台进程 Trace
• 用户会话 Trace
• SQL Trace
• 10046 事件 Trace
• Hang Analyze
• Systemstate Dump
• RAC 相关诊断文件
• ADR 中的 Incident 文件

SQL Trace 可以记录 SQL 解析、执行、获取、CPU、等待事件和绑定变量等信息，再通过 TKPROF 转换为易读报告。

生产环境中应谨慎启用高级 Trace。Trace 可能产生较大文件并增加运行开销，因此应限定目标会话、SQL、模块和采集时间。

4.4 OSWatcher

OSWatcher 通常简称 OSW 或 OSWbb，用于持续采集操作系统性能信息，包括：

• CPU 使用率
• 内存使用情况
• 进程状态
• 磁盘 I/O
• 网络状态
• 系统负载
• 虚拟内存和换页情况

OSWatcher 适合判断数据库异常是否与操作系统资源问题相关。在较新的 Oracle 诊断体系中，它可以作为 Autonomous Health Framework 支持工具的一部分使用。

4.5 SQLHC

SQLHC，即 SQL Health Check，是 Oracle Support 常用的 SQL 诊断脚本工具。

它可以围绕指定 SQL ID 收集以下信息：

• SQL 文本和执行计划
• SQL 历史执行统计
• 对象定义和索引信息
• 表、列和直方图统计信息
• 优化器参数
• 绑定变量信息
• SQL Profile、SQL Patch 和 SQL Plan Baseline
• AWR 中的历史执行计划
• 可能影响 SQL 性能的已知问题

SQLHC 不是数据库内置的自动优化组件，通常需要从 My Oracle Support 获取并按照对应文档执行。

4.6 Oracle Autonomous Health Framework

Oracle Autonomous Health Framework，简称 AHF，集成或关联了多种诊断能力，包括：

• TFA 诊断信息采集
• OSWatcher 操作系统监控
• Procwatcher 进程和会话监控
• 集群和数据库日志分析
• 故障时间线整理
• 跨节点诊断信息收集

AHF 适合快速收集指定故障时间段内数据库、集群和操作系统的关联信息。

五、不同版本的功能关注点

表中的“支持”只代表相应数据库版本具备该技术能力，不代表所有版本类型、平台和许可证都可以无条件使用。

六、推荐的性能问题分析流程

6.1 明确问题范围

首先确认：

• 问题开始和结束时间
• 影响哪些业务和用户
• 是整体数据库变慢还是单个 SQL 变慢
• 是持续问题还是瞬时问题
• 最近是否进行过发布、升级、参数调整或统计信息收集
• 是否发生数据量突然增长
• 是否只影响某个实例、服务或节点

时间范围不准确，是很多性能分析失败的重要原因。

6.2 判断瓶颈类型

使用 OEM、AWR、ADDM、ASH 和动态性能视图判断主要瓶颈属于：

• CPU
• 存储 I/O
• 网络
• 内存
• 锁和并发
• RAC 集群通信
• 日志写入
• SQL 执行计划
• 解析和共享池
• 临时空间
• 应用连接和事务设计

6.3 定位高负载 SQL 或会话

重点检查：

• Top SQL by DB Time
• Top SQL by CPU Time
• Top SQL by Elapsed Time
• Top SQL by Buffer Gets
• Top SQL by Physical Reads
• Top SQL by Executions
• Top Sessions
• Top Events
• 阻塞会话链

6.4 分析执行计划

结合以下工具确认 SQL 问题：

• DBMS_XPLAN.DISPLAY_CURSOR
• SQL Monitor
• SQL Tuning Advisor
• SQLHC
• AWR SQL 历史
• SQL Plan Baseline
• 绑定变量和对象统计信息

不要只根据 Cost 数值判断执行计划优劣。Cost 是优化器用于比较候选计划的估算值，并不等同于真实执行时间。

6.5 关联操作系统数据

通过 OSWatcher、 top、 vmstat、 iostat、 sar 或监控平台判断：

• 数据库 CPU 高是否对应主机 CPU 耗尽
• 数据库 I/O 等待是否对应磁盘高延迟
• 是否发生 Swap
• 是否存在网络丢包或延迟
• 是否有其他进程争抢资源

6.6 实施并验证优化

优化措施可能包括：

• 改写 SQL
• 创建或调整索引
• 更新统计信息
• 使用 SQL Profile
• 使用 SQL Plan Baseline
• 调整分区设计
• 降低并发和批量大小
• 优化事务提交频率
• 调整内存或 I/O 配置
• 修复应用连接问题
• 隔离异常 SQL 执行计划

优化后必须使用相同时间范围、相同 SQL 负载和相同指标进行复测。必要时可使用 SPA 或 Database Replay 验证变更效果。

七、授权注意事项

Oracle 性能工具的授权是生产环境中必须重视的问题：

• AWR、ASH 和 ADDM 通常属于 Oracle Diagnostics Pack；
• SQL Tuning Advisor、SQL Access Advisor、Automatic SQL Tuning 和 Real-Time SQL Monitoring 通常属于 Oracle Tuning Pack；
• SQL Performance Analyzer 和 Database Replay 通常涉及 Oracle Real Application Testing；
• OEM 中的部分页面会调用上述管理包功能；
• 自动索引、SQL Quarantine 和 Real-Time Statistics 的可用性与版本类型、平台和许可有关；
• 直接查询底层视图或调用 PL/SQL 包，并不一定能绕过许可要求。

数据库中存在某个包、视图或菜单，不代表当前许可证自动允许使用。正式使用前，应根据实际数据库版本、部署方式、最新许可文档和采购合同进行确认。

八、总结

Oracle 性能优化工具可以分为三个层次：

1. AWR、ASH、ADDM、服务器告警和 OEM，负责发现、记录和定位性能问题；
2. SQL Tuning Advisor、SQL Access Advisor、SQL Monitor、SPA、SPM、Automatic SQL Tuning 和 Automatic Indexing，负责分析 SQL、控制执行计划并验证优化效果；
3. 动态性能视图、执行计划、Trace、OSWatcher、SQLHC 和 AHF，负责深入还原数据库、SQL 及操作系统层面的运行情况。

在实际性能优化中，建议遵循以下原则：

1. 先确定准确的问题时间段，再分析性能数据；
2. 从 DB Time 和等待事件判断瓶颈方向；
3. 同时关注 SQL、会话、数据库和操作系统；
4. 优先查看实际执行计划，而不是只看 EXPLAIN PLAN；
5. 不以单一指标或单一报告直接下结论；
6. 所有优化措施都应验证效果并准备回退方案；
7. 使用高级性能工具前确认版本、平台和授权要求。

性能优化的目标不是让所有指标都变小，而是在业务可接受的成本范围内，稳定地缩短关键事务响应时间、提高系统吞吐量，并减少性能回退风险。

-the end-

MyBologs：

https://www.myhfxf.com

https://www.xiaofeihuangfu.com

CSDN: https://blog.csdn.net/xfhuangfu

ITPUB: https://blog.itpub.net/28373936/

微信公众号：xfhuangfu