ORACLE awrrpt analysis
Awrrpt analysis
1. Confirm the system is OLTP or OLAP
If the system is OLTP: pay attention to Library hit and Buffer hit
2. Elasped time > DB Time ok. Otherwise it means the load of database is high.
otherwise
| Snap Id | Snap Time | Sessions | Cursors/Session | |
|---|---|---|---|---|
| Begin Snap: | 3887 | 09-Apr-14 00:00:29 | 234 | 8.8 |
| End Snap: | 3911 | 10-Apr-14 00:00:30 | 213 | 9.7 |
| Elapsed: | 1,440.01 (mins) | |||
| DB Time: | 503.75 (mins) |
3. Instance Efficiency Percentages (Target 100%)
| Buffer Nowait %: | 100.00 | Redo NoWait %: | 100.00 |
| Buffer Hit %: | 97.83 | In-memory Sort %: | 100.00 |
| Library Hit %: | 99.68 | Soft Parse %: | 99.84 |
| Execute to Parse %: | 18.44 | Latch Hit %: | 100.00 |
| Parse CPU to Parse Elapsd %: | 64.94 | % Non-Parse CPU: | 96.67 |
a. Buffer Nowait 说明 在从内存取数据的时候，没有经历等待的比例，期望值是100%
b. Buffer Hit 说明从内存取数据的时候，buffer的命中率的比例，期望值是100%，但100%并不代表性能就好，因为这只是一个比例而已，举个例子，执行一条 sql语句，# 执行计划是需要取10000个数据块，结果内存中还真有这10000个数据块，那么比例是100%，表面上看是性能最高的，还有一个执行计划是需要500 个数据块，内存中有250个，另外250个需要在物理磁盘中取，这种情况下，buffer hit是50%，结果呢，第二个执行计划性能才是最高的，所以说100%并不代表性能最好
c. Library Hit 说明sql在Shared Pool的命中率，期望值是100%
d. Execute to Parse 说明解析sql和执行sql之间的比例，越高越好，说明一次解析，到处执行，如果parse多，execute少的话，还会出现负数，因为计算公式是100*（1-parse/execute）
e. Parse CPU to Parse Elapsd 说明在解析sql语句过程中，cpu占整个的解析时间比例，，期望值是100%，说明没有产生等待，需要说明的是，即使有硬解析，只要cpu没有出现性能问题，也是可以容忍的，比较硬解析也有它的好处的
f. Redo NoWait 说明在产生日志的时候，没有产生等待，期望值是100%
g. Soft Parse 说明软解析的比例，期望值是100%，有一点要说明的是，不要单方面的追求软解析的高比例，而去绑定变量，要看性能的瓶颈在哪里
h. Latch Hit 说明latch的命中率，期望值是100%，latch类似锁，是一种内存锁，但只会产生等待，不会产生阻塞，和lock还是有区别的，latch是在并发的情况下产生的
i. Non-Parse CPU 说明非解析cpu的比例，越高越好，用100减去这个比例，可以看出解析sql所花费的cpu，100-99.30=0.7，说明花费在解析sql上的cpu很少
b. Buffer Hit 说明从内存取数据的时候，buffer的命中率的比例，期望值是100%，但100%并不代表性能就好，因为这只是一个比例而已，举个例子，执行一条 sql语句，# 执行计划是需要取10000个数据块，结果内存中还真有这10000个数据块，那么比例是100%，表面上看是性能最高的，还有一个执行计划是需要500 个数据块，内存中有250个，另外250个需要在物理磁盘中取，这种情况下，buffer hit是50%，结果呢，第二个执行计划性能才是最高的，所以说100%并不代表性能最好
c. Library Hit 说明sql在Shared Pool的命中率，期望值是100%
d. Execute to Parse 说明解析sql和执行sql之间的比例，越高越好，说明一次解析，到处执行，如果parse多，execute少的话，还会出现负数，因为计算公式是100*（1-parse/execute）
e. Parse CPU to Parse Elapsd 说明在解析sql语句过程中，cpu占整个的解析时间比例，，期望值是100%，说明没有产生等待，需要说明的是，即使有硬解析，只要cpu没有出现性能问题，也是可以容忍的，比较硬解析也有它的好处的
f. Redo NoWait 说明在产生日志的时候，没有产生等待，期望值是100%
g. Soft Parse 说明软解析的比例，期望值是100%，有一点要说明的是，不要单方面的追求软解析的高比例，而去绑定变量，要看性能的瓶颈在哪里
h. Latch Hit 说明latch的命中率，期望值是100%，latch类似锁，是一种内存锁，但只会产生等待，不会产生阻塞，和lock还是有区别的，latch是在并发的情况下产生的
i. Non-Parse CPU 说明非解析cpu的比例，越高越好，用100减去这个比例，可以看出解析sql所花费的cpu，100-99.30=0.7，说明花费在解析sql上的cpu很少
| Event | Waits | Time(s) | Avg wait (ms) | % DB time | Wait Class |
|---|---|---|---|---|---|
| DB CPU | 14,931 | 49.40 | |||
| db file sequential read | 1,049,728 | 4,124 | 4 | 13.64 | User I/O |
| db file scattered read | 504,265 | 2,755 | 5 | 9.12 | User I/O |
| direct path read | 131,783 | 881 | 7 | 2.91 | User I/O |
| db file parallel read | 48,791 | 492 | 10 | 1.63 | User I/O |
a. DB CPU 位置越高越好；
b. db file sequential read > db file scattered read 说明走索引大于全表扫描
场景一：数据库慢
awrrpt报告结果：
TOP 5中有control file parallel write, log file parallel write
解决方案：
1. 磁盘读写慢 --> 调整磁盘
2. 使用关键字“nologging”
3. 减少提交“commit”
高log file sync等待事件的3个主要原因。
①．高提交频率
①．高提交频率
解决方法是简单的消除不必要的提交，事务是工作单元。工作单元应该是全部成功或全部失败。
②．缓慢的I/O子系统
较高的IO吞吐良可以改善log file sync和log file parallel write事件的平均等待时间。频繁的提交会弄乱数据库布局和IO子系统。解决办法是将日志文件放裸设备上或绑定在RAID 0或RAID 0+1中，而不是绑定在RAID 5中。
③．过大的日志缓冲区
过大的日志缓冲区也可能延长log file sync等待。大型的日志缓冲区减少后台写入的数量，允许LGWR变得懒惰，并导致更多的重做条目堆积在日志缓冲区中。同时可以调整参数_LOG_IO_SIZE参数，其默认值是LOG_BUFFER的1/3或1MB，取两者之中较小的值。换句话说，你可以具有较大的日志缓冲区，但较小的_LOG_IO_SIZE将增加后台写入，从而减少log file sync的等待时间。
②．缓慢的I/O子系统
较高的IO吞吐良可以改善log file sync和log file parallel write事件的平均等待时间。频繁的提交会弄乱数据库布局和IO子系统。解决办法是将日志文件放裸设备上或绑定在RAID 0或RAID 0+1中，而不是绑定在RAID 5中。
③．过大的日志缓冲区
过大的日志缓冲区也可能延长log file sync等待。大型的日志缓冲区减少后台写入的数量，允许LGWR变得懒惰，并导致更多的重做条目堆积在日志缓冲区中。同时可以调整参数_LOG_IO_SIZE参数，其默认值是LOG_BUFFER的1/3或1MB，取两者之中较小的值。换句话说，你可以具有较大的日志缓冲区，但较小的_LOG_IO_SIZE将增加后台写入，从而减少log file sync的等待时间。
Comments
Post a Comment