一、运行$ORACLE_HOME/rdbms/admin下awrrpt.sql生成awr报表
二、报表中比较重要的部分
1.load profile
Per Second | Per Transaction | |
Redo size: | 1,053.75 | 11,886.69 |
Logical reads: | 36.31 | 409.59 |
Block changes: | 6.36 | 71.73 |
Physical reads: | 0.21 | 2.37 |
Physical writes: | 0.34 | 3.82 |
User calls: | 0.10 | 1.11 |
Parses: | 1.43 | 16.14 |
Hard parses: | 0.21 | 2.31 |
Sorts: | 0.89 | 10.09 |
Logons: | 0.03 | 0.36 |
Executes: | 3.31 | 37.34 |
Transactions: | 0.09 |
% Blocks changed per Read: | 17.51 | Recursive Call %: | 99.65 |
Rollback per transaction %: | 0.00 | Rows per Sort: | 77.83 |
这个表里应该注重：
1）logical reads和physical reads，同时也可以得到平均每个逻辑读导致多少物理读，即0.21/36.31=0.57%。平均每个事务产生了409.59个逻辑读，这个数字应该越小越好。
2）parses 和hard parses：从表中可以看到cpu平均每秒进行了1.43个解析（超过100个应该注意），每秒进行0.21（超过10个应该注意）次硬解析，即cpu每秒要处理0.21个全新的sql，应该说很闲。
3）% Blocks changed per Read 17.51%，说明82.49%（1-17.51%）的逻辑读是用于只读而不是修改数据块。
4）Recursive Call%标明通过pl/sql来执行sql的比率。
5）rollback per transaction 表明事务回滚的百分比，对这个数据的分析应该参考前面transactions（0.09），这个值应该越小越好。
2.Instance Efficiency Percentages (Target 100%)
Buffer Nowait %: | 100.00 | Redo NoWait %: | 100.00 |
Buffer Hit %: | 99.42 | In-memory Sort %: | 100.00 |
Library Hit %: | 91.99 | Soft Parse %: | 85.67 |
Execute to Parse %: | 56.77 | Latch Hit %: | 100.00 |
Parse CPU to Parse Elapsd %: | 98.27 | % Non-Parse CPU: | 74.28 |
1）buffer nowait,不应低于99%；
2）buffer hit，不应低于99%；
3）library hit，不应低于95%--本系统为91.99%，说明该数据库中可能存在library cache 的争用；
4）soft parse，不应低于95%，说明sql语句的重用性不好；
5）latch hit，此数值如果低于95%说明数据库存在严重问题；
6）execute to parse%，说明sql语句执行与解析的比率。本数据库为56.77%，说明有43.23%的sql为新sql；
7）Parse CPU to Parse Elapsd %，=98.27%，说明如果cpu解析语句需要1秒，需要1/0.9827=1.02的总时间完成，说明cpu解析sql有0.02秒的时间来等待某种资源的释放，该值越小越好；
8）Non-parse CPU，说明花费在十几工作的时间和花费在解析上的时间的对比。
3.Shared Pool Statistics
Begin | End | |
Memory Usage %: | 99.08 | 96.00 |
% SQL with executions>1: | 83.62 | 81.22 |
% Memory for SQL w/exec>1: | 91.76 | 88.96 |
1）Memory Usage ，说明在shared pool中，被使用的部分占shared pool总尺寸的百分比。这个值应保持适中，(如85%）,如果太高，则会引起shared pool中的对象被刷出内存，从而导致sql语句的硬解析增加，太低则浪费内存；
2）SQL with executions>1，执行次数大于1次的sql占总sql数的百分比，越大越好；
3）Memory for SQL w/exec>1，在shared pool中执行次数大于1次的sql语句所消耗的内存占shared pool的百分比。
4.Top 5 Timed Events
Event | Waits | Time(s) | Avg Wait(ms) | % Total Call Time | Wait Class |
CPU time | 202 | 69.1 | |||
control file sequential read | 57,817 | 111 | 2 | 38.1 | System I/O |
os thread startup | 2,124 | 79 | 37 | 27.2 | Concurrency |
db file sequential read | 18,814 | 71 | 4 | 24.2 | User I/O |
db file parallel write | 31,698 | 20 | 1 | 7.0 | System I/O |
查看这个可以查看前五位的等待时间，oracle的等待事件有800多种，且大都相互关联，往往解决好前五位的等待事件就能够解决大多数的等待事件，收到事半功倍的效果。
5.SQL Statistics -->SQL ordered by Gets
- Resources reported for PL/SQL code includes the resources used by all SQL statements called by the code.
- Total Buffer Gets: 4,967,556
- Captured SQL account for 49.4% of Total
Buffer Gets | Executions | Gets per Exec | %Total | CPU Time (s) | Elapsed Time (s) | SQL Id | SQL Module | SQL Text |
674,362 | 0 | 13.58 | 32.51 | 57.14 | b6usrg82hwsa3 | DBMS_SCHEDULER | call dbms_stats.gather_databas... | |
539,858 | 1,762 | 306.39 | 10.87 | 48.84 | 54.27 | 6gvch1xu9ca3g | DECLARE job BINARY_INTEGER := ... | |
463,562 | 3 | 154,520.67 | 9.33 | 1.08 | 1.09 | gfjvxb25b773h | select o.owner#, o.obj#, decod... | |
203,851 | 1,444 | 141.17 | 4.10 | 0.78 | 0.96 | cvhk2j2gymzhd | DBMS_SCHEDULER | SELECT SU.NAME, SO.NAME, A.S... |
155,683 | 1,319 | 118.03 | 3.13 | 13.19 | 14.03 | abtp0uqvdb1d3 | CALL MGMT_ADMIN_DATA.EVALUATE_... | |
88,060 | 1,960 | 44.93 | 1.77 | 6.26 | 7.07 | 8a1pvy4cy8hgv | insert into histgrm$(obj#, int... | |
78,038 | 25,918 | 3.01 | 1.57 | 2.85 | 2.85 | 803b7z0t84sq7 | select job, nvl2(last_date, ... | |
71,659 | 9,999 | 7.17 | 1.44 | 0.54 | 0.56 | 6769wyy3yf66f | select pos#, intcol#, col#, sp... | |
70,539 | 1,044 | 67.57 | 1.42 | 6.23 | 6.94 | 4y1y43113gv8f | delete from histgrm$ where obj... | |
65,695 | 19,196 | 3.42 | 1.32 | 4.91 | 5.23 | 3c1kubcdjnppq | update sys.col_usage$ set eq... | |
64,291 | 7,544 | 8.52 | 1.29 | 3.41 | 3.45 | 7ng34ruy5awxq | select i.obj#, i.ts#, i.file#,... | |
62,092 | 1,444 | 43.00 | 1.25 | 0.19 | 0.19 | g1xapjmt4vm5c | DBMS_SCHEDULER | SELECT SU.NAME, SO.NAME, A.S... |
59,666 | 5,500 | 10.85 | 1.20 | 1.28 | 1.28 | 0h6b2sajwb74n | select privilege#, level from ... | |
57,990 | 36 | 1,610.83 | 1.17 | 2.38 | 3.37 | 70vs1d7ywk5m0 | MMON_SLAVE | begin dbms_stats.copy_table_st... |
52,548 | 3,328 | 15.79 | 1.06 | 0.71 | 0.91 | cqgv56fmuj63x | select owner#, name, namespace... |
在这里我们可以看到哪些sql语句扫描过多的数据块才能返回结果，这些语句需要优化。
6.IO Stats -->Tablespace IO Stats
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，如果过大应该检查是否将读写很频繁的文件放在了同一个磁盘上。
7.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，获得buffer busy waits最严重的对象。在同一时刻只有一个进程能够访问同一个数据块，其它进程必须等待。解决的关键是优化那些扫描了过多数据块的sql语句，减少他们要扫描的数据块。如果已经优化了sql语句，则可以考虑增大pctfree的值，从而减少一个数据块中能够包含的数据行数，从而将对象的数据行分部到更多的数据块里去。
六、实例活动统计数据
比较在内存中和磁盘中的排序量，如果磁盘排序太高就需要增加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进程。
ENQUEUE TIMEOUTS:请求入列的次数（锁定），以及所请求的特定队列不可用的次数。如果这个统计信息大于0，就需要调查锁定问题。
FREE BUFFER INSPECTED:由于是脏读数据、被固定或者正忙等原因儿跳过的缓冲区数量。如果数量很大的话就说明缓冲区缓存太小了。
SQL语句被解析的次数。
数据库中递归调用的数量。如果某个进程中的递归调用数量大于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:获取的数据行的数量，可以是链化数据行，也可以是迁移的数据行。
七、表空间和文件I/O统计数据
对于带缓存的磁盘I/O时间通常少于1ms.
在init.ora文件中可以设置参数DB_FILE_MULTIBLOCK_READ_COUNT有助于磁盘读取时间，该参数控制在全表扫描时一次I/O中读入的
数据块数量，这将减少扫描一张表所需的I/O数量，从而提高全表扫描的性能。但是，设置该参数的结果是优化器可能会执行更多的
全表扫描，所以需要将OPTIMIZER_INDEX_COST_ADJ设为一个值，例如10，来消除这个问题，并且驱动索引的使用。
数据字典和库缓存的统计数据
如果报表中PCT MISS值很高，你应当提高应用程序中游标的共享程度或者增加共享池的尺寸。
AWR报表和STATSPACK输出结果中首先需要查看的10项内容
1）首要的5个等待时间；
2）负载简档；
3）实力效率和命中率；
4）等待事件；
5）闩锁等待；
6）首要的SQL;
7）实例活动；
8）文件I/O和段统计数据；
9）内存分配；
10）缓冲区等待；
