一、报表头
WORKLOAD REPOSITORY report for
| DB Name | DB Id | Instance | Inst num | Release | RAC | Host |
|---|---|---|---|---|---|---|
| ORA10G | 4018937891 | ora10g | 1 | 10.2.0.1.0 | NO | FS-62 |
| Snap Id | Snap Time | Sessions | Cursors/Session | |
|---|---|---|---|---|
| Begin Snap: | 12242 | 16-3月 -11 12:43:35 | 99 | 1.7 |
| End Snap: | 12269 | 17-3月 -11 15:01:41 | 145 | 8.3 |
| Elapsed: | 1,578.09 (mins) | |||
| DB Time: | 210.48 (mins) |
Report Summary
Cache Sizes
| Begin | End | |||
|---|---|---|---|---|
| Buffer Cache: | 408M | 480M | Std Block Size: | 8K |
| Shared Pool Size: | 160M | 88M | Log Buffer: | 6,968K |
二、负载简档
Load Profile
| Per Second | Per Transaction | |
|---|---|---|
| Redo size: | 4,976.63 | 11,231.44 |
| Logical reads: | 1,318.04 | 2,974.60 |
| Block changes: | 42.99 | 97.02 |
| Physical reads: | 3.64 | 8.22 |
| Physical writes: | 0.88 | 1.99 |
| User calls: | 87.23 | 196.86 |
| Parses: | 15.06 | 34.00 |
| Hard parses: | 2.71 | 6.13 |
| Sorts: | 11.96 | 26.99 |
| Logons: | 0.57 | 1.30 |
| Executes: | 42.91 | 96.85 |
| Transactions: | 0.44 |
| % Blocks changed per Read: | 3.26 | Recursive Call %: | 67.23 |
| Rollback per transaction %: | 24.00 | Rows per Sort: | 72.96 |
如果重做数据块增加，块更改变得频繁，以及每次读操作%BLOCKS增加，都意味着DML语句活动的增加；
如果SQL语句不再共享池中分析，就会呈现硬分析，硬分析超过100次/秒就意味着绑定变量的使用效率不高，
应当使用CURSOR_SHARING初始化参数；或者说明共享池大小有问题；
如果SQL语句在共享池中运行就会出现软分析，软分析超过300次/秒就说明应用程序效率不高，语句被反复分析，
而不是对应每个会话应只分析语句一次，以保证高效率。
三、实例的效率
Instance Efficiency Percentages (Target 100%)
| Buffer Nowait %: | 100.00 | Redo NoWait %: | 99.99 |
| Buffer Hit %: | 99.80 | In-memory Sort %: | 100.00 |
| Library Hit %: | 94.51 | Soft Parse %: | 81.98 |
| Execute to Parse %: | 64.90 | Latch Hit %: | 99.96 |
| Parse CPU to Parse Elapsd %: | 78.02 | % Non-Parse CPU: | 82.86 |
BUFFER NOWAIT%
低于99：这是一个对特定缓冲区的请求命中率，在内存中该缓冲区应该立即可用。如果命中率下降，在BUFFER WAIT部分将发现当前存在热数据块的争用想象；
BUFFER HIT%低于95：这是一个对特定缓冲区的请求命中率，并且缓冲区位于内存中，而无需物理磁盘的IO操作。
如果你在访问时经常使用非选择性索引，它将使命中率很高，这将导致很多DBA误认为系统性能很好。
高命中率不说明系统性能一定高，但低命中率一定说明低性能；
LIBRARY HIT%低于95：较低的库命中率通常意味着SQL过早的被推出缓冲池（可能是因为缓冲池太小了）。较低的命中率
还意味着没有使用绑定变量或者一些其他问题造成SQL没有被重用；
OLTP中的IN MEMORY SORT%低于95：在一个OLTP系统中，调整PGA_AGGREGATE_TARGET,SORT_AREA_SIZE可以有效解决该问题；
SOFT PARSE%低于95：软分析低于80说明SQL没有被重用；
LATCH HIT%低于99：通常是个大问题，找到特定的闩锁可以解决问题。
四、五个最重要的等待事件
Top 5 Timed Events
| Event | Waits | Time(s) | Avg Wait(ms) | % Total Call Time | Wait Class |
|---|---|---|---|---|---|
| SQL*Net more data to client | 762,278 | 8,827,093 | 11,580 | 69,895.5 | Network |
| log file sync | 14,068 | 8,298,607 | 589,892 | 65,710.8 | Commit |
| db file sequential read | 55,449 | 5,286,862 | 95,346 | 41,862.9 | User I/O |
| log file parallel write | 51,756 | 3,060,269 | 59,129 | 24,232.1 | System I/O |
| db file parallel write | 43,403 | 2,095,949 | 48,290 | 16,596.3 | System I/O |
首要等待事件是整个报表中最能揭示问题的部分，如果TIMED_STATISTICS是TRUE，那么事件将按照等待的时间排序，否则将按照等待的数量排序。
Wait Events
- s - second
- cs - centisecond - 100th of a second
- ms - millisecond - 1000th of a second
- us - microsecond - 1000000th of a second
- ordered by wait time desc, waits desc (idle events last)
| Event | Waits | %Time -outs | Total Wait Time (s) | Avg wait (ms) | Waits /txn |
|---|---|---|---|---|---|
| SQL*Net more data to client | 762,278 | 0.00 | 8,827,093 | 11580 | 18.17 |
| log file sync | 14,068 | 0.00 | 8,298,607 | 589892 | 0.34 |
| db file sequential read | 55,449 | 0.00 | 5,286,862 | 95346 | 1.32 |
| log file parallel write | 51,756 | 0.00 | 3,060,269 | 59129 | 1.23 |
| db file parallel write | 43,403 | 0.00 | 2,095,949 | 48290 | 1.03 |
| db file scattered read | 34,260 | 0.00 | 1,644,941 | 48013 | 0.82 |
| control file parallel write | 31,887 | 0.00 | 1,600,072 | 50179 | 0.76 |
| direct path read | 25,188 | 0.00 | 1,479,752 | 58748 | 0.60 |
| control file sequential read | 23,095 | 0.00 | 815,458 | 35309 | 0.55 |
| SQL*Net message to client | 8,573,047 | 0.00 | 177,975 | 21 | 204.34 |
| latch: session allocation | 720 | 0.00 | 151,013 | 209741 | 0.02 |
| library cache pin | 1,256 | 0.00 | 150,085 | 119494 | 0.03 |
| enq: RO - fast object reuse | 129 | 0.00 | 131,440 | 1018915 | 0.00 |
| latch: library cache | 1,536 | 0.00 | 119,347 | 77700 | 0.04 |
| os thread startup | 320 | 1.88 | 84,768 | 264901 | 0.01 |
| latch: shared pool | 1,062 | 0.00 | 72,219 | 68003 | 0.03 |
| SQL*Net break/reset to client | 1,616 | 0.00 | 51,430 | 31825 | 0.04 |
| latch: cache buffers chains | 412 | 0.00 | 37,860 | 91893 | 0.01 |
| reliable message | 105 | 0.00 | 31,729 | 302176 | 0.00 |
| latch free | 388 | 0.00 | 30,572 | 78794 | 0.01 |
| SQL*Net more data from client | 38,992 | 0.00 | 28,933 | 742 | 0.93 |
| LGWR wait for redo copy | 3,825 | 0.10 | 21,912 | 5729 | 0.09 |
| enq: TX - row lock contention | 125 | 0.00 | 16,048 | 128386 | 0.00 |
| library cache load lock | 444 | 0.00 | 11,228 | 25288 | 0.01 |
| log buffer space | 9 | 0.00 | 10,088 | 1120838 | 0.00 |
| kksfbc child completion | 109 | 100.00 | 8,504 | 78016 | 0.00 |
| latch: library cache lock | 72 | 0.00 | 6,406 | 88968 | 0.00 |
| read by other session | 36 | 0.00 | 6,067 | 168540 | 0.00 |
| log file switch completion | 26 | 7.69 | 5,803 | 223200 | 0.00 |
| buffer busy waits | 35 | 0.00 | 4,248 | 121379 | 0.00 |
| rdbms ipc reply | 285 | 0.00 | 4,012 | 14077 | 0.01 |
| latch: enqueue hash chains | 2 | 0.00 | 3,036 | 1518074 | 0.00 |
| latch: messages | 3 | 0.00 | 3,026 | 1008799 | 0.00 |
| enq: SQ - contention | 34 | 0.00 | 2,917 | 85786 | 0.00 |
| latch: library cache pin | 43 | 0.00 | 2,744 | 63811 | 0.00 |
| log file switch (checkpoint incomplete) | 5 | 60.00 | 2,279 | 455745 | 0.00 |
| latch: row cache objects | 17 | 0.00 | 2,217 | 130424 | 0.00 |
| cursor: mutex X | 1,351 | 0.00 | 1,876 | 1388 | 0.03 |
| latch: cache buffers lru chain | 2 | 0.00 | 1,044 | 522002 | 0.00 |
| SGA: allocation forcing component growth | 10 | 40.00 | 35 | 3516 | 0.00 |
| direct path write | 232 | 0.00 | 3 | 12 | 0.01 |
| buffer exterminate | 3 | 0.00 | 2 | 568 | 0.00 |
| latch: In memory undo latch | 2 | 0.00 | 1 | 600 | 0.00 |
| log file sequential read | 20 | 0.00 | 0 | 18 | 0.00 |
| log file single write | 20 | 0.00 | 0 | 13 | 0.00 |
| row cache lock | 11 | 0.00 | 0 | 23 | 0.00 |
| db file parallel read | 1 | 0.00 | 0 | 13 | 0.00 |
| enq: CF - contention | 1 | 0.00 | 0 | 5 | 0.00 |
| undo segment extension | 456 | 100.00 | 0 | 0 | 0.01 |
| direct path write temp | 428 | 0.00 | 0 | 0 | 0.01 |
| latch: redo allocation | 8 | 0.00 | 0 | 0 | 0.00 |
| cursor: mutex S | 5 | 0.00 | 0 | 0 | 0.00 |
| SQL*Net message from client | 8,572,916 | 0.00 | 512,942,718 | 59833 | 204.34 |
| pipe get | 84,729 | 0.22 | 3,037,535 | 35850 | 2.02 |
| SGA: MMAN sleep for component shrink | 892 | 55.61 | 568,172 | 636964 | 0.02 |
| Streams AQ: qmn coordinator idle wait | 6,858 | 50.83 | 190,038 | 27710 | 0.16 |
| Streams AQ: waiting for time management or cleanup tasks | 2,929 | 58.89 | 114,168 | 38978 | 0.07 |
| jobq slave wait | 34,360 | 92.11 | 102,569 | 2985 | 0.82 |
| virtual circuit status | 3,156 | 100.00 | 94,324 | 29887 | 0.08 |
| Streams AQ: qmn slave idle wait | 3,372 | 0.00 | 94,291 | 27963 | 0.08 |
| class slave wait | 55 | 100.00 | 269 | 4897 | 0.00 |
DB FILE SEQUENTIAL READ：该等待事件通常指单一的数据块读操作，例如索引的读取，该值过大说明表的连接顺序很糟糕，或者使用了非选择性索引。在一个高事务量，做过较好调整的系统中该数字通常较大。以排序的方式加载数据有助于范围扫描，还可以减少块读取的数量，分区也有帮助，分区可以排除一些块。注意非选择性索引会导致许多快读取。
BUFFER BUSY WAITS IDS:当一个缓冲区以一种非共享方式被使用或者正被读入缓存时会出现这种等待，
BUFFER BUSY WAIT不应该高于1%；
buffer busy/Segment Header:如果等待针对一个段的头信息，就增加空闲列表或者空闲列表组的数量，
或者扩大PCTUSED与PCTFREE之间的间隔。
buffer busy/Undo Header:如果等待是针对一个撤销请求的头信息，则可以通过增加会滚段或者增加
撤销区域来解决；
Buffer Busy/Undo Block:如果是针对一个撤销的数据块，应该适当加快提交（不能过快，否则会引起
日志同步问题）或者使用更大的回滚段或者撤销区。需要减少驱动一致性读操作的表上的数据密集度
或者增加DB_CACHE_SIZE;
Buffer Busy/Data Block:如果等待是发生在一个数据快上，就可以将数据移动到另外一个数据快上，
以避开这个热数据块，或者使用更小的数据块（以减少每个数据块的行数，降低他的热度）；
Buffer Busy/Index Block：
Latch Free：闩锁是底层的队列机制（更加准确得说是互斥机制），用于保护系统全局去SGA的共享
内存结构。如果闩锁不可用，就会记录一次闩锁丢失。多大多数的闩锁丢失问题都与使用绑定变量失
败（库缓存闩锁和共享池闩锁）、生成重做日志问题、缓存的征用问题以及缓存的热数据块有关系。闩锁
也与BUG有关，当闩锁丢失率高于0.5%就应当到oracle.com/support查找一下METLINK的BUG报告；
ENQUEUE:入列是保护共享资源的一种锁机制。这种锁保护共享资源，例如一条记录中的数据，以防止两个人
同时更新同一条数据，排队机制是FIFO（ORACLE的栓锁机制不是FIFO）；
Log File Switch: 确保归档的磁盘未满，并且速度足够快。由于IO的原因，DBWR可能速度很慢。可能需要
增加更多更大的日志文件，并且如果DBWR存在问题，你可能需要增加DBWR进程数；
LOG BUFFER SPACE:数据库发生改变时，改变的块被复制到日志缓冲区。如果日志缓冲区不能足够快的
写入重做日志，就会导致LOG BUFFER SPACE问题。当一次提交大量事务时也会产生这个问题。
这种等待出现在写日志缓冲区的速度快于LGWR写重做日志的速度，或者是日志切换太慢了，但通常不是因为
日志缓冲区太小。可以增加日志文件的尺寸，或者使用更快的磁盘写日志，但最终手段可以增加日志缓冲
区的尺寸。
LOG FILE SYNC:为了减少日志文件同步等待，可以尝试一次批量提交更多的记录而不是逐条提交，
可以使用更快的磁盘或者裸设备或者RAID10(而不是RAID5,RAID5写性能太差)；
Global Cache CR Request:当使用多个实例时（RAC）当一个实例等待另一个实例缓存的数据块时就会发生
Global Cache CR Request;
Log File Parallel Write:将重做日志放到较快的磁盘上，不要使用RAID5,将日志文件和数据文件分开存放；
Direct Path Read：ORACLE通常使用DIRECT PATH READS直接将数据块读入PGA，它可用于排序、并行查询
和提前读操作。这里的时间并不总是反映实际等待时间。这通常是文件I/O的问题。使用异步I/O可以减少消耗时间，
但是不会减少等待时间；
Direct Path Write:
Async Disk I/O:ORACLE等待异步写操作完成，或者等待写入的异步从属。问题可能是DBWR,LGWR,ARCH,CKPT
有关的I/O问题，但通常是某个文件I/O问题。
IDEL EVENTS:闲置时间保存在STATS$IDLE_EVENT表中。
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/23754390/viewspace-689772/ ，如需转载，请注明出处，否则将追究法律责任。
