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 blo
ck
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.
[@more@]
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 blo
ck
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.
[@more@]
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/9533994/viewspace-1016077/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/9533994/viewspace-1016077/