诊断工具汇总
系统级别：- Top Activity
- AWR Report
- ASH
- ADDM
- EM
- Exa Watcher
- OS Tools
- Hang Analyze
- Trace Events
- System State Dump
SQL级别：
- SQL Monitor Report
- ASH
- DBMS_XPLAN
- EM
- EXPLAIN PLAN
- SQLT
- 10053 Trace
- Trace Events
- SQL Health Check
会话级别：
- ASH
- EM
- 10046 Trace
- Trace Events
$ORACLE_HOME/rdbms/admin:
- awrrpt.sql: 单实例awr报告- awrgrpt.sql: RAC的AWR
- awrddrpt.sql: 单实例AWR对比报告（意思就是数据库正常的时候和不正常的时候的对比
- awrgdrpt.sql: RAC的对比报告
- awrsqrpt.sql: 单个SQL的报告
AWR报告分析顺序
1.报告开头的系统基础信息
2.ADDM的主要发现
3.负载概览（Load Profile）
4.init.ora参数
5.顶级前台事件
6.顶级SQL
7.根据上述步骤里发现的可疑问题具体分析
所以会话数大概是48-480，是性能最优解。
通过这个ADDM可以关注下
DB CPU：当前有多少session获取了所有资源，正在使用CPU
DB Time：当前有多少session在等待资源
上图DB Time远大于DB CPU，说明有很多等待事件，说明数据库处于很忙的状态。
可以通过这张图的每秒DB CPU与第一张图的CPU core做比较，上图CPU core数为48说明每秒最多应该就48个DB CPU，但是上图都58了，说明拿到资源的session更多，数据库很忙，CPU是该系统的瓶颈。
需要特别注意的参数：
- db_block_size
- db_file_multiblock_read_count
- cursor_sharing
- open_cursors
- optimizer_*
- parallel_*
- processes
- sessions
EPS系统确实是会设置一些下划线参数，网站上面有这些参数的模板。
前台等待事件，关注比较明显的等待事件。
总结
- 系统级别性能问题的首选问题：AWR- 提供系统设置和体系结构的整体概况
- 分析是采用自顶向下
注意事项：
- 注意时间段，时间跨度尽量要短，包括问题发生的时间。
- 对于RAC的数据库，需要同步分析Global的和所有单个实例的AWR
- 对于CDB/PDB的架构，如果只分析某个PDB的问题，那就因该分析单个PDB的AWR
问答：
- AWR无标准解释文档- OLTP环境中Logon应该为0
- 以执行次数排序的 TOP 10 SQL 为确实的执行次数，存储过程中执行多次就是按多次算
- db_block_size：可以创建表空间级别的此参数，理论上一个block存放一行数据。一般不会在系统级别修改，在表空间修改及格。
- session不关，游标不会自动退出，所以程序中如果用完的游标不及时Close很容易在一个session累计大量未关闭的游标。