在客户处AWR报告中发现TOP 5 EVENT出出现如下等待事件:
Event | Waits | Time(s) | Avg Wait(ms) | % Total Call Time | Wait Class |
CPU time |
| 4,989 |
| 96.6 |
|
gcs log flush sync | 129,223 | 3,103 | 24 | 60.1 | Other |
reliable message | 295 | 33 | 111 | .6 | Other |
gc cr block busy | 764 | 16 | 21 | .3 | Cluster |
log file sync | 10,132 | 8 | 1 | .2 | Commit |
This is how it happens -
1)You fired an update statement on Instance-2.
2)However, the request for desired blocks was gone to Instance-1. So Instance-2 was
waiting on ''gc cr request'.
3)Instance-1 had the requested blocks but before it ships the blocks to Instance-2, it need to flush the changes from current block
to redo logs on disks. Until this is done Instance-2 waits on event - 'gcs log flush sync'.
The cause of this wait event 'gcs log flush sync' is mainly - Redo log IO performance.
To avoid this problem you need to =
1)Improve the Redo log I/o performance.
2) Set undersore parameter "_cr_server_log_flush" =false
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/7882490/viewspace-674175/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/7882490/viewspace-674175/