OracleAWR内容有哪些
本篇内容主要讲解“Oracle AWR内容有哪些”，感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷，实用性强。下面就让小编来带大家学习“Oracle AWR内容有哪些”吧!
成都创新互联服务项目包括淮滨网站建设、淮滨网站制作、淮滨网页制作以及淮滨网络营销策划等。多年来，我们专注于互联网行业，利用自身积累的技术优势、行业经验、深度合作伙伴关系等，向广大中小型企业、政府机构等提供互联网行业的解决方案，淮滨网站推广取得了明显的社会效益与经济效益。目前，我们服务的客户以成都为中心已经辐射到淮滨省份的部分城市，未来相信会继续扩大服务区域并继续获得客户的支持与信任！
1.AWR报告头信息
| DB Name | DB Id | Unique Name | Role | Edition | Release | RAC | CDB |
|---|---|---|---|---|---|---|---|
| KTDB | 1107793954 | ktdb | PRIMARY | EE | 19.0.0.0.0 | YES | NO |
| Instance | Inst Num | Startup Time |
|---|---|---|
| ktdb2 | 2 | 02-3月 -20 19:35 |
| Host Name | Platform | CPUs | Cores | Sockets | Memory (GB) |
|---|---|---|---|---|---|
| hn-ekdb2 | Linux x86 64-bit | 80 | 80 | 4 | 753.98 |
| Snap Id | Snap Time | Sessions | Cursors/Session | Instances | |
|---|---|---|---|---|---|
| Begin Snap: | 5339 | 14-5月 -20 08:00:03 | 159 | .5 | 4 |
| End Snap: | 5342 | 14-5月 -20 11:00:14 | 168 | .6 | 4 |
| Elapsed: | 180.17 (mins) | ||||
| DB Time: | 1.23 (mins) |
• DB Name ：数据库名字 DBid: 数据库id
• Elapsed:采样时间段
• DB Time:用户操作花费的时间,不包括Oracle后台进程消耗的时间
• DB Time远小于Elapsed Time说明数据库比较空闲
在180分钟里（其间收集了3次快照数据），数据库耗时1.23分钟.
可是对于批量系统，数据库的工作负载总是集中在一段时间内。如果快照周期不在这一段时间内，或者快照周期跨度太长而包含了大量的数据库空闲时间，所得出的分析结果是没有意义的。这也说明选择分析时间段很关键，要选择能够代表性能问题的时间段。
2. Load Profile
Load Profile
| Per Second | Per Transaction | Per Exec | Per Call | |
|---|---|---|---|---|
| DB Time(s): | 0.0 | 1.2 | 0.00 | 0.01 |
| DB CPU(s): | 0.0 | 0.6 | 0.00 | 0.01 |
| Background CPU(s): | 0.1 | 21.8 | 0.03 | 0.00 |
| Redo size (bytes): | 1,495.0 | 256,536.7 | ||
| Logical read (blocks): | 384.5 | 65,979.0 | ||
| Block changes: | 29.3 | 5,026.5 | ||
| Physical read (blocks): | 18.0 | 3,095.9 | ||
| Physical write (blocks): | 0.6 | 93.7 | ||
| Read IO requests: | 3.8 | 656.2 | ||
| Write IO requests: | 0.3 | 53.9 | ||
| Read IO (MB): | 0.1 | 24.2 | ||
| Write IO (MB): | 0.0 | 0.7 | ||
| IM scan rows: | 0.0 | 0.0 | ||
| Session Logical Read IM: | 0.0 | 0.0 | ||
| Global Cache blocks received: | 3.9 | 667.2 | ||
| Global Cache blocks served: | 191.8 | 32,906.7 | ||
| User calls: | 0.6 | 98.2 | ||
| Parses (SQL): | 3.5 | 598.3 | ||
| Hard parses (SQL): | 0.0 | 1.4 | ||
| SQL Work Area (MB): | 0.0 | 3.6 | ||
| Logons: | 0.1 | 18.7 | ||
| User logons: | 0.0 | 0.4 | ||
| Executes (SQL): | 3.7 | 639.6 | ||
| Rollbacks: | 0.0 | 0.0 | ||
| Transactions: | 0.0 |
• Per Second 和Per Transaction：这两部分是数据库资源负载的一个明细列表，分割成每秒钟的资源负载和每个事务的资源负载情况
• Redo size：每秒/每个事务 产生的redo量 (单位字节) 标志数据库的繁忙程度
• logical reads：每秒/每个事务 产生的逻辑读的块数
• block changes：每秒/每个事务 改变的数据块数
• physical reads：每秒/每个事务 产生的物理读
• physical writes：每秒/每个事务 产生的物理写的块数
• user calls：每秒/每个事务 用户的调用次数
• parses：每秒/每个事务 分析次数
• hard parses: 每秒/每个事务 硬分析次数
• SQL Work Area：每秒/每个事物 排序次数
• logons: 每秒/每个事务 登录数据库次数
• executes: 每秒/每个事务 SQL的执行次数
• rollbacks: 每秒/每个事物回滚次数
• transactions: 每秒的事务数
需要注意：
1）logical reads和physical reads，同时也可以得到平均每个逻辑读导致多少物理读，即18/384 平均每个事务产生了65979个逻辑读，这个数字应该越小越好。
2）parses 和hard parses：从表中可以看到cpu平均每秒进行了3.5个解析（超过100个应该注意），每秒进行0（超过10个应该注意）次硬解析，即cpu每秒要处理0个全新的sql，应该说很闲。
3.instance efficiency Percentages：
Instance Efficiency Percentages (Target 100%)
| Buffer Nowait %: | 99.99 | Redo NoWait %: | 100.00 |
| Buffer Hit %: | 95.96 | In-memory Sort %: | 100.00 |
| Library Hit %: | 99.57 | Soft Parse %: | 99.76 |
| Execute to Parse %: | 6.46 | Latch Hit %: | 99.95 |
| Parse CPU to Parse Elapsd %: | 25.76 | % Non-Parse CPU: | 99.74 |
| Flash Cache Hit %: | 0.00 |
• Buffer Nowait%：表示在内存获得数据的未等待比例
（不应低于99%）• Buffer Hit%：表示进程从内存中找到数据块的比率，内存数据块命中率。
（不应低于99%）• Library Hit%：表示共享池中SQL解析的命中率。
(不应低于95%） 如果过小，说明该数据库中可能存在library cache的争用。• Execute to Parse：是语句执行与解析的比例，如果要SQL重用率高，则这个比例会很高。该值越高表示一次解析后被重复执行的次数越多。本数据库为6.46%，说明有93.54%的sql为新sql。• Parse CPU to Parse Elapsd：解析总时间中消耗总CPU的时间百分比• Redo NoWait：表示在LOG缓冲区获得BUFFER的未等待比例。• In-memory sort%：在内存中排序的比率，如果过低说明有大量的排序在临时表空间中进行。（考虑调大PGA）• Soft Parse%：软解析的百分比（softs/softs+hards），太低说明SQL重用率不好，则需要调整应用使用绑定变量。（不应低于百分之95）• Latch Hit：Latch是一种保护内存结构的锁，可以认为是SERVER进程获取访问内存数据结构的许可。（如果此数值低于95%说明数据库存在严重问题）• Non-Parse CPU ：SQL实际运行时间/(SQL实际运行时间+SQL解析时间)，太低表示解析消耗时间过多。
4.shared pool statistics：
Shared Pool Statistics
| Begin | End | |
|---|---|---|
| Memory Usage %: | 85.83 | 85.92 |
| % SQL with executions>1: | 91.54 | 92.23 |
| % Memory for SQL w/exec>1: | 85.45 | 86.42 |
• Memory Usage %：对于一个已经运行一段时间的数据库来说，共享池内存使用率，被使用的部分占shared pool总尺寸的百分比。这个值应保持适中，(如85%）,如果太高，则会引起shared pool中的对象被刷出内存，从而导致sql语句的硬解析增加，太低则浪费内存；• SQL with executions>1：执行次数大于1的sql比率，如果此值太小，说明需要在应用中更多使用绑定变量，避免过多SQL解析。• Memory for SQL w/exec>1：执行次数大于1的SQL消耗内存的占比。
5.event wait
Top 10 Foreground Events by Total Wait Time
| Event | Waits | Total Wait Time (sec) | Avg Wait | % DB time | Wait Class |
|---|---|---|---|---|---|
| DB CPU | 37.8 | 51.4 | |||
| gc cr multi block mixed | 2,606 | 27.5 | 10.55ms | 37.4 | Cluster |
| db file scattered read | 2,217 | 2.8 | 1.27ms | 3.8 | User I/O |
| gc cr block 3-way | 2,674 | 1.3 | 493.28us | 1.8 | Cluster |
| gc cr multi block grant | 2,600 | 1.2 | 461.59us | 1.6 | Cluster |
| db file parallel read | 803 | 1 | 1.25ms | 1.4 | User I/O |
| Sync ASM rebalance | 672 | 1 | 1.47ms | 1.3 | Other |
| IPC send completion sync | 2,206 | .8 | 381.13us | 1.1 | Other |
| enq: PS - contention | 1,173 | .5 | 463.95us | .7 | Other |
| log file sync | 23 | .5 | 19.77ms | .6 | Commit |
按所占等待时间的比例倒序列示。当我们调优时，总希望观察到最显著的效果，因此应当从这里入手确定我们下一步做什么。
通常，在没有问题的数据库中，CPU time总是列在第一个。
6.SQL资源消耗定位：
SQL ordered by Elapsed Time：
记录了执行总和时间的TOP SQL(请注意是监控范围内该SQL的执行时间总和，而不是单次SQL执行时间）。
• Elapsed Time(S): SQL语句执行用总时长，此排序就是按照这个字段进行的。注意该时间不是单个SQL跑的时间，而是监控范围内SQL执行次数的总和时间。单位时间为秒 Elapsed Time = CPU Time + Wait Time• CPU Time(s): 为SQL语句执行时CPU占用时间总时长，此时间会小于等于Elapsed Time时间。单位时间为秒。• Executions: SQL语句在监控范围内的执行次数总计。• Elap per Exec(s): 执行一次SQL的平均时间。单位时间为秒。• % Total DB Time: 为SQL的Elapsed Time时间占数据库总时间的百分比。• SQL ID: SQL语句的ID编号，点击之后就能导航到下边的SQL详细列表中，点击IE的返回可以回到当前SQL ID的地方。• SQL Module: 显示该SQL是用什么方式连接到数据库执行的，如果是用SQL*Plus或者PL/SQL链接上来的那基本上都是有人在调试程序。一般用前台应用链接过来执行的sql该位置为空。• SQL Text: 简单的sql提示，详细的需要点击SQL ID。
SQL ordered by CPU Time:
记录了执行占CPU时间总和时间最长的TOP SQL(请注意是监控范围内该SQL的执行占CPU时间总和，而不是单次SQL执行时间)。
· %Total - CPU Time as a percentage of Total DB CPU
· %CPU - CPU Time as a percentage of Elapsed Time
· %IO - User I/O Time as a percentage of Elapsed Time
SQL ordered by Gets:
记录了执行占总buffer gets(逻辑IO)的TOP SQL(请注意是监控范围内该SQL的执行占Gets总和，而不是单次SQL执行所占的Gets).
· %Total - Buffer Gets as a percentage of Total Buffer Gets
SQL ordered by Reads:
记录了执行占总磁盘物理读(物理IO)的TOP SQL(请注意是监控范围内该SQL的执行占磁盘物理读总和，而不是单次SQL执行所占的磁盘物理读)。
· %Total - Physical Reads as a percentage of Total Disk Reads
SQL ordered by Executions:
记录了按照SQL的执行次数排序的TOP SQL。该排序可以看出监控范围内的SQL执行次数。
SQL ordered by Parse Calls:
记录了SQL的软解析次数的TOP SQL。
SQL ordered by Sharable Memory:
记录了SQL占用library cache的大小的TOP SQL。
Sharable Mem (b)：占用library cache的大小。单位是bytes。
主要针对ordered by Elapsed time,orderedby CPU time,orderedby gets,orderedby read排名前三SQL进行观察并调优.
7.IO Stats -->Tablespace IO Stats
（在样例AWR中没有收集该信息，所以使用一个样例）
Tablespace | Reads | Av Reads/s | Av Rd(ms) | Av Blks/Rd | Writes | Av Writes/s | Buffer Waits | 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 |
SYSTEM | 2,496 | 0 | 4.74 | 1.62 | 4,469 | 0 | 0 | 0.00 |
USERS | 364 | 0 | 3.08 | 1.57 | 4 | 0 | 0 | 0.00 |
TEMP | 34 | 0 | 3.24 | 12.35 | 25 | 0 | 0 | 0.00 |
TEST2 | 4 | 0 | 47.50 | 1.00 | 4 | 0 | 0 | 0.00 |
1）可以找到具有频繁读写活动的表空间或数据文件，如果临时表空间的写入数量最高，说明排序太多太大；
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有助于磁盘读取时间，该参数控制在全表扫描时一次I/O中读入的数据块数量，这将减少扫描一张表所需的I/O数量，从而提高全表扫描的性能。但是，设置该参数的结果是优化器可能会执行更多的全表扫描，所以需要将OPTIMIZER_INDEX_COST_ADJ设为一个值，例如10，来消除这个问题，并且驱动索引的使用。
8.Segment Statistics
1）Segments by Logical Reads或Segments by Physical Reads
可以找到逻辑读或物理读比较大的对象，并查找原因，是否可以通过创建新索引、或采用分区表等来降低对象的逻辑读以及物理读；
2）Segments by Row Lock Waits
通过这个报表可以找到获得行级锁最严重的对象，需要跟开发人员探讨解决方法；
3）Segments by ITL Waits
这个报表可以标明获得ITL等待最严重的对象，如果发现了ITL等待很严重的对象，则应该将对象的initrans参数设置为并发操作该对象的进程个数；
4）Segments by Buffer Busy Waits：
Owner | Tablespace Name | Object Name | Subobject Name | Obj. Type | Obj# | Dataobj# | Buffer Busy Waits | % of Capture |
SYS | SYSAUX | SYS_LOB0000007450C00009$$ | SYS_LOB_P4025 | LOB PARTITION | 99696 | 99696 | 2 | 66.67 |
SYS | SYSTEM | SEG$ | TABLE | 14 | 8 | 1 | 33.33 |
获得buffer busy waits最严重的对象。Buffer busy waits产生原因就是数据分布问题。解决的关键是优化那些扫描了过多数据块的sql语句，减少他们要扫描的数据块。如果已经优化了sql语句，则可以考虑增大pctfree的值，从而减少一个数据块中能够包含的数据行数，从而将对象的数据行分部到更多的数据块里去，或者建立hash分区表，使数据重新分布。
9.实例活动统计数据
比较在内存中和磁盘中的排序量，如果磁盘排序太高就需要增加PGA_AGGREGATE_TARGET(或者旧版本中增大SORT_AREA_SIZE)
如果磁盘的读操作较高，表明可能执行了全表扫描，如果目前存在大量的较大的对较大表的全表扫描，就应当评估最常用的查询,并通过增加索引来提高效率。大量的非一致性读操作意味着使用了过多的索引或者使用了非选择性索引。如果脏读缓冲区数量高于所请求的空闲缓冲区的数量（超过5%），那么说明DB_CACHE_SIZE太小，或者没有建立足够多的检查点。如果叶节点的分裂数量很高可以考虑重建已增长或已经碎化的索引。
consistent gets:没有使用select for update子句的查询在缓冲中访问的数据块数量，这个数量加上DB BLOCK GETS统计信息的值就是逻辑读操作总数
DB BLOCK GETS:使用了INSERT UPDATE DELETE OR SELECT FOR UPDATE语句在缓存中访问的数据块数量。
PHYSICAL READS:没有从缓存中度取得数据量。可以从磁盘，操作系统缓存或者磁盘缓存中读取，以满足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:一条SQL语句被解析的次数。
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内容有哪些”有了更深的了解，不妨来实际操作一番吧！这里是创新互联网站，更多相关内容可以进入相关频道进行查询，关注我们，继续学习！
网页标题：OracleAWR内容有哪些
网页URL：http://pwwzsj.com/article/podsdd.html
