本文分析了在特定数据库实例中出现的GCS Log Flush Sync等待问题的原因，并提出了两种解决方案：一是提高Redolog I/O性能；二是设置参数_cr_server_log_flush为false。
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
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/14730395/viewspace-681302/，如需转载，请注明出处，否则将追究法律责任。
转载于:http://blog.itpub.net/14730395/viewspace-681302/
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
