Oracle AWR 包含什么？
1. AWR报告头信息
| 数据库名称 | 数据库 ID | 唯一名称 | 角色 | 版本 | 发布 | RAC | CDB |
|---|---|---|---|---|---|---|---|
| KTDB | ktdb | 主要 | EE | 19.0.0.0.0 | 是 | 否 |
| 实例 | 实例编号 | 启动时间 |
|---|---|---|
| ktdb2 |
| 主机名称 | 平台 | CPU | 核心 | 插槽 | 内存 (GB) |
|---|---|---|---|---|---|
| hn-ekdb2 | Linux x86 64 位 |
| 快照 ID | 快照时间 | 会话 | 光标/Session | 实例 | |
|---|---|---|---|---|---|
| 开始捕捉： | |||||
| 已过： | |||||
| 数据库时间： | < /td> | 1.23（分钟） |
• DB Name：数据库名称 DBid：数据库 ID
• Elapsed：采样时间段
• DB Time：用户操作所花费的时间，不包括Oracle后台进程消耗的时间
• DB Time远小于Elapsed Time，说明数据库比较空闲
在180分钟内（采集了3次快照数据），数据库耗时1.23分钟。
但是对于批处理系统来说，数据库工作负载总是集中在一段时间内。如果快照周期不在这个周期内，或者快照周期跨度过长，包含大量数据库空闲时间，那么得到的分析结果就没有意义。这也说明分析时间段的选择很关键，选择一个能够代表性能问题的时间段。
2. 加载配置文件
加载配置文件
| 每秒 | 每笔事务 | 每执行 | 每次调用 | ||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 数据库时间(s）： | |||||||||||||||||||||||||||||||||||
| 数据库 CPU： | |||||||||||||||||||||||||||||||||||
| 后台 CPU： | |||||||||||||||||||||||||||||||||||
| 1,495.0 | |||||||||||||||||||||||||||||||||||
| 逻辑读取（块）： | |||||||||||||||||||||||||||||||||||
| 块更改： | |||||||||||||||||||||||||||||||||||
| 物理读取（块）： | |||||||||||||||||||||||||||||||||||
| 物理写入（块）： | |||||||||||||||||||||||||||||||||||
| 读取 IO 请求： | |||||||||||||||||||||||||||||||||||
| 写入IO请求： | 读取 IO (MB)： | ||||||||||||||||||||||||||||||||||
| 写入 IO (MB)： | |||||||||||||||||||||||||||||||||||
| IM 扫描行： | |||||||||||||||||||||||||||||||||||
| 会话逻辑读取 IM： | |||||||||||||||||||||||||||||||||||
| 全局缓存块收到： | |||||||||||||||||||||||||||||||||||
| 服务的全局缓存块： | 191.8 | ||||||||||||||||||||||||||||||||||
| 用户调用： | |||||||||||||||||||||||||||||||||||
| 解析（SQL）： | |||||||||||||||||||||||||||||||||||
| 硬解析 (SQL)： | |||||||||||||||||||||||||||||||||||
| SQL 工作区 (MB)： | 3.6 | ||||||||||||||||||||||||||||||||||
| 登录： | |||||||||||||||||||||||||||||||||||
| 用户登录： | |||||||||||||||||||||||||||||||||||
| 执行 (SQL)： | |||||||||||||||||||||||||||||||||||
| 回滚： | |||||||||||||||||||||||||||||||||||
| 交易： | < br/> |
• Per Second 和 Per Transaction：这两部分是数据库资源负载的详细列表，分为每秒的资源负载和每个事务的资源负载
• Redo size：redo 的数量每秒产生/每笔交易（单位字节）标志着数据库的繁忙程度
• 逻辑读：每秒/每个事务生成的逻辑读块数
• 块更改：每秒/每个事务更改的数据块数
• 物理读：每个事务生成的物理读第二/每笔交易
• 物理写入：每秒/每笔交易生成的物理写入数 块数
• 用户调用：每秒/每笔交易的用户调用数
• 解析：每笔交易的数量每秒/每个事务的解析次数
• 硬解析：每秒/每个事务的硬解析次数
• SQL 工作区：每秒/每个事务的排序次数
• 登录次数：每秒/每个事务的数据库登录次数
• 执行：每秒/每个事务的SQL 查询次数
• 回滚：每秒/每个事务的回滚次数
• 事务：每秒事务数
注：
1）逻辑读和物理读，还可以得到p的平均数每次逻辑读引起的物理读数，即18/384。平均而言，每个事务生成 65,979 次逻辑读取。这个数字应该尽可能小。
2）解析和硬解析：从表中我们可以看到CPU平均每秒执行3.5次解析（超过100次应注意），0次（超过10次应注意） ) 每秒硬解析。分析一下，就是CPU每秒要处理0条新的SQL，应该说是非常空闲的。
3.实例效率百分比：
实例效率百分比（目标100%）
| 缓冲不等待%： | 重做不等待%： |
| 缓冲区命中%： | |
| 软解析%： | 99.76 |
| 执行解析%： | 锁存命中百分比： |
| % 非解析 CPU： | |
（不应小于99%)• Buffer Hit%：表示进程从内存中查找数据块的比例，即内存数据块的Hit率。
（不应低于99%） • Library Hit%：表示库中的SQ共享池L解析的命中率。
（不应小于95%）如果太小，则表明数据库中可能存在库缓存争用。 • 执行与解析：语句执行与解析的比率。如果你想要高的SQL重用率，这个比例就会很高。值越高，重复解析的次数就越多。这个数据库是6.46%，说明93.54%的sql是新sql。 • Parse CPU to Parse Elapsd：消耗的总CPU 时间占总解析时间的百分比 • Redo NoWait：表示获取LOG 缓冲区中BUFFER 的不等待比例。 • 内存中排序%：内存中排序的比例。如果太低，则说明在临时表空间中进行了大量的排序。 （考虑增加PGA） • Soft Parse%：软解析的百分比（软/软+硬）。如果太低，说明SQL复用率不好，需要调整应用程序使用绑定变量。 （受ld 不低于95%) • Latch Hit：Latch 是保护内存结构的锁，可以认为是SERVER 进程获得了访问内存数据结构的权限。 （如果该值低于95%，说明数据库存在严重问题） • Non-Parse CPU：SQL实际运行时间/（SQL实际运行时间+SQL解析时间），太低意味着解析消耗太高很多时间。
4.共享池统计：
共享池统计
| 开始 | 结束 | |
|---|---|---|
| 内存使用百分比： | ||
| % SQL 执行次数>1: | ||
| 执行 SQL 的内存百分比>1： |
• 内存使用百分比：对于已经运行一段时间的数据库，共享池内存使用情况，已使用部分占共享池总大小的百分比。这个值应该保持适中（比如85%）。如果太高，会导致共享池中的对象被刷新出内存，导致SQL语句的硬解析增加。如果太低，会浪费内存； • 执行次数>1 的SQL：执行次数大于1 的SQL 比例。如果该值太小，则意味着应用程序中需要使用更多的绑定变量，以避免过多的SQL 解析。 • Memory for SQL w/exec>1：执行次数大于 1 的 SQL 消耗的内存比例。
5.event wait
按总等待时间排列的前 10 个前台事件
| 事件 | 等待 | 总等待时间（秒） | 平均等待 | 数据库时间百分比 | 等待类 |
|---|---|---|---|---|---|
| 数据库CPU | 37.8 | ||||
| gc cr 多块混合 | 集群 | ||||
| db文件分散读取 | 用户 I/O | ||||
| gc cr 块 3 路 | 集群 | gc cr 多块拨款 | |||
| db文件并行读取 | 用户 I/O | ||||
| 同步 ASM 重新平衡 | 其他 | ||||
| IPC发送完成同步 | 2,206 | ||||
| 日志文件同步 |
按照等待时间比例降序排列。当我们调整时，我们总是希望看到最显着的效果，所以这就是我们开始确定下一步做什么的地方。
通常，在没有问题的数据库中，CPU 时间总是列在前面。
6.SQL资源消耗定位：
按照Elapsed Time排序的SQL：
记录总执行次数的TOP SQLtime（请注意，这是监控范围内SQL的总执行时间，而不是单个SQL的执行时间）。
• Elapsed Time(S)：执行SQL 语句所用的总时间。这种排序是基于这个字段的。注意，这个时间不是单次SQL运行的时间，而是监控范围内SQL执行次数的总时间。单位时间为秒。 Elapsed Time = CPU Time + Wait Time• CPU Time(s)：执行SQL 语句时占用CPU 的总时间。该时间将小于或等于已用时间。单位时间为秒。 • 执行次数：监控范围内SQL 语句的总执行次数。 • Elap per Exec(s)：执行一次SQL 的平均时间。单位时间为秒。 • % Total DB Time：SQL 运行时间占数据库总时间的百分比。 • SQL ID：SQL 语句的ID 号。单击可导航到下面的详细 SQL 列表。点击在IE中返回返回当前的SQL ID。 • SQL 模块：显示SQL 如何连接到数据库来执行。如果是使用SQL*Plus或者PL/SQL连接的话，基本上就有人在调试程序了。通常，与前端应用程序链接执行的SQL的位置为空。 • SQL 文本：简单的sql 提示，需要单击SQL ID 才能查看详细信息。
按CPU时间排序的SQL：
记录执行CP中总U时间最长的TOP SQL（请注意，是在该时间内执行该SQL所占用的总CPU时间）监控范围，而不是单个SQL的执行时间）。
· %Total - CPU 时间占总 DB CPU 的百分比
· %CPU - CPU 时间占已用时间的百分比
· %IO - 用户 I/O 时间占已用时间的百分比
按 Gets 排序的 SQL :
记录执行TOP SQL占总buffer gets（逻辑IO）的执行情况（请注意t监控范围内的SQL执行占总Gets，而非单次SQL执行占Gets）。
·%Total - Buffer Gets占总缓冲区获取数的百分比
按读取次数排序的 SQL：
记录 TOP SQL 的执行占磁盘物理读取总数（物理 IO）的比例（请注意监控范围内的SQL执行占磁盘物理读总量，而不是单次SQL执行占磁盘物理读）。
· %Total - 物理读取占总磁盘读取的百分比
按执行排序的 SQL：
记录按照SQL执行次数排序的TOP SQL。这种排序可以显示监控范围内的SQL执行次数。
按Parse Calls排序的SQL：
记录SQL软解析次数的Top SQL。
按共享内存排序的SQL：
记录的TOP SQLSQL占用的库缓存的大小。
Sharable Mem (b)：库缓存占用的大小。单位是字节。
主要观察和调优ordered by Elapsed time、ordered by CPU time、ordered by gets、ordered by read的前三条SQL。
7.IO Stats - -> 表空间 IO 统计
（示例 AWR 中未收集此信息，因此使用示例）
读取 | Av 读取次数 | Av Rd(毫秒) | Av Blks/Rd | 写入 | Av 写入次数 < /td > | 缓冲区等待 | Av Buf Wt(ms ) | |
SYSAUX | 9,553 | 0 | 4.07 | 1.65 | 19,729 | 0 | 0 | 0.00 |
UNDOTBS | 7,879 | 0 | 3.21 | 1.00 | 8,252 | 0 | 20 | 5.50 |
系统 | 2,496 | 0 | 4.74 | 1.62 | 4,469 | 0 | 0 | 0.00 |
用户 | 364 | < td valign="top">3.08 | 1.57 | 4 | 0 | 0 | 0.00 | |
温度 | 34 | 0 | 3.24 | 12.35 | 25 | 0 | 0 | 0.00 |
测试2 | 4 | 0 | 47.50 | < td valign="top">4 | 0 | 0 | 0.00 | < /tr>
1）可以找到频繁读写活动的表空间或数据文件。如果临时表空间的写入次数最多，说明排序太慢ge;
2）从AVG BLKS/RD列中，我们可以看到哪些表空间经历了最多的全表扫描。如果该值大于1，则该值应与初始化参数db_file_multiblock_read_count的值进行比较。如果比较接近，说明大部分表空间进行了全表扫描；
3) 查看AV RD(MS)，该列表示I/O读取时间。该值应小于 20ms。如果太大，应检查经常读写的文件是否放在同一磁盘上。
注意：
带缓存的磁盘I/O时间通常小于1ms。
可以在init.ora文件中设置参数DB_FILE_MULTIBLOCK_READ_COUNT为help 磁盘读取时间。该参数控制全表扫描时一次I/O读取的数据块数量。这样会减少扫描表所需的I/O次数，从而提高全表扫描的性能。但是设置这个参数的结果是优化器可能会执行更多的全表扫描，因此需要将 OPTIMIZER_INDEX_COST_ADJ 设置为一个值，例如 10，以消除此问题并驱动索引的使用。
8.段统计
1）按逻辑读分段或按物理读分段
可以发现逻辑读或物理读比较大对象，找出原因，看看是否通过创建新索引或使用分区表可以减少对象的逻辑和物理读取；
2）Segments by Row Lock Waits
< p>通过此报告，您可以找到获得行级锁最严重的对象。您需要与开发人员讨论解决方案；3) 按 ITL 等待细分
此报告可以表明您已获得最严重的对象的 ITL 等待。如果发现有严重ITL等待的对象，则应将该对象的initrans参数设置为并发操作该对象的进程数；
4）Segments by Buffer Busy Waits：
所有者 | 表空间名称 | 对象名称 | 子对象名称 | 对象。输入 | Obj# | < p >Dataobj# | 缓冲区忙等待 | 捕获百分比 |
SYSAUX | SYS_LOB0000007450C00009$$ | SYS_LOB_P4025 | LOB 分区 | 99696< /p> | 99696 | 2 | 66.67 | |
系统 | 系统 | SEG$ | < td valign="top">表格 | 14 | 8 | 1 | 33.33 |
获取缓冲区忙等待最严重的对象。 Buffer busy waits的原因是数据分布问题。解决的关键是优化扫描过多数据块的SQL语句，减少扫描的数据块数量。如果SQL语句已经过优化，可以考虑增大pctfree的值，从而减少一个数据块中可以包含的数据行数，从而将对象的数据行划分为更多的数据块，或者建立哈希分区。表重新分配数据。
9.实例活动统计
比较内存和磁盘中的排序量。如果磁盘排序太高，需要增加PGA_AGGREGATE_TARGET（或者旧版本增加SORT_AREA_SIZE）
如果磁盘读操作较高，则表明可能进行了全表扫描。如果当前存在大量较大表的大型全表扫描，您应该评估最常用的查询，并通过添加索引来提高效率。大量的非一致性读操作意味着使用了过多的索引或者使用了非选择性索引。如果脏读缓冲区的数量高于请求的空闲缓冲区的数量（超过 5%），则说明 DB_CACHE_SIZE 太小，或者没有建立足够的检查点。如果叶节点分裂数量较多，请考虑重建已增长或已碎片的索引。
一致获取：不使用 select for update 子句的查询在缓冲区中访问的数据块的数量。这个数字加上DB BLOCK GETS统计值就是逻辑读操作的总数
DB BLOCK GETS：使用 INSERT UPDATE DELETE OR SELECT FOR UPDATE 语句在缓存中访问的数据块的数量。
物理读取：未从缓存中获取数据。可以从磁盘、操作系统缓存或磁盘缓存中读取，以满足 SELECT、SELECT FOR UPDATE、INSERT、UPDATE、DELETE 语句
LOGICAL READS=CONSISTENT GETS+DB BLOCK GETS。
缓存命中率HIT RATIO=(LOGICAL READS- PHYSICAL READS)/LOGICAL READS *100%
=(CONSISTENT GETS+DB BLOCK GETS- PHYSICAL READS)/(CONSISTENT GETS+DB BLOCK GETS) * 100%
缓存命中率应高于95%，否则需要增大DB_CACHE_SIZE。
DIRTY BUFFERS INSPECTED：从 LRU 列表中清除的脏读（修改）数据缓冲区的数量。如果该值超过0，请考虑添加DB_WR进程。
FREE BUFFER INSPECTED：由于脏读数据、固定或繁忙原因而跳过的缓冲区数量。如果数字很大，则缓冲区高速缓存太小。
PARSE COUNT：一个S的次数QL 语句已被解析。
RECURSIVE CALLS：数据库中递归调用的数量。如果一个进程的递归调用次数大于4次，则应检查数据字典缓存的命中率，以及是否有表或索引的范围过大。除非您使用大量 PL/SQL，否则递归调用应占用户调用的 10% 以下。
REDO SIZE：写入日志的重做信息量（以字节为单位）。此信息将有助于确定重做日志的大小。
SORTS(DISK)：磁盘排序数。磁盘排序次数除以内存排序次数不应高于5%。否则，需要调整SORT_AREA_SIZE和PGA_AGGREGATE_TARGET的大小
注意：SORT_AREA_SIZE分配的内存是针对每个用户的，PGA_AGGREGATE_TARGET分配的内存是针对所有会话的。的。
SORTS(MEMORY)：内存中的排序数。
SORTS(ROWS)：要排序的数据行数。
TABLE FETCH BY ROWID：通过访问ROWID访问的数据行数。高值通常意味着应用程序在获取数据方面进行了很好的调整。
TABLE FETCH CONTINUED ROW：获取的数据行数，可以是链式数据行，也可以是迁移后的数据行。
10.数据字典和库缓存统计：
如果报告中的PCT MISS值很高，则应增加应用程序中游标的共享程度或增加共享池的大小。
至此，相信大家对《Oracle AWR 的内容是什么》有了更深入的了解了，不妨实践一下吧！这是网站。更多相关内容，您可以进入相关渠道进行查询。关注我们并继续学习！
2. 本站积分货币获取途径以及用途的解读，想在本站混的好，请务必认真阅读！
3. 本站强烈打击盗版/破解等有损他人权益和违法作为，请各位会员支持正版！
4. 编程技术 > Oracle AWR 包含什么？
