环境:
主库为Exadata,备库为Linux系统,5G一个归档,主库节点1 4分钟生成一个归档,备库1.5分钟生成一个归档。
PSU:当前数据库PSU版本为11.2.0.4 18年4月的PSU
问题描述:
发现备库应用延迟严重,平均2.5分钟左右才应用一个归档,因此追不上主库生成的速度,导致应用延迟,通过查询备库的等待事件,发现大量等待"latch: checkpoint queue latch"。
问题分析:
通过对相应的等待事件进行分析,发现此问题与MOS文档 25248384.8描述完全匹配,因为BUG 25248384引起,影响11.2.0.4及12.1.0.2版本,在12.2及18C版本上修复,在多DBWR进程及高负载情况下会触发这个BUG,文档上没写规避方案,我们通过查看备库的DBWR进程发现,备库配置了15个进程。然后我也查了一下当前版本下没有现成补丁可以应用,因此把备库的DBWR进程数修改成6并重启备机,重启后归档应用速度恢复,等待事件消失,问题解决。
The content was last updated on: 26-FEB-2018
Click here for details of each of the sections below.
主库为Exadata,备库为Linux系统,5G一个归档,主库节点1 4分钟生成一个归档,备库1.5分钟生成一个归档。
PSU:当前数据库PSU版本为11.2.0.4 18年4月的PSU
问题描述:
发现备库应用延迟严重,平均2.5分钟左右才应用一个归档,因此追不上主库生成的速度,导致应用延迟,通过查询备库的等待事件,发现大量等待"latch: checkpoint queue latch"。
问题分析:
通过对相应的等待事件进行分析,发现此问题与MOS文档 25248384.8描述完全匹配,因为BUG 25248384引起,影响11.2.0.4及12.1.0.2版本,在12.2及18C版本上修复,在多DBWR进程及高负载情况下会触发这个BUG,文档上没写规避方案,我们通过查看备库的DBWR进程发现,备库配置了15个进程。然后我也查了一下当前版本下没有现成补丁可以应用,因此把备库的DBWR进程数修改成6并重启备机,重启后归档应用速度恢复,等待事件消失,问题解决。
Bug 25248384 Active Standby apply rate is slow due to wait event "latch: checkpoint queue latch"
This note gives a brief overview of bug 25248384.The content was last updated on: 26-FEB-2018
Click here for details of each of the sections below.
Affects:
Product (Component) Oracle Server (Rdbms) Range of versions believed to be affected Versions >= 11.2.0.4 but BELOW 18.1 Versions confirmed as being affected Platforms affected Generic (all / most platforms affected)
Fixed:
The fix for 25248384 is first included in
Interim patches may be available for earlier versions - click here to check.
Symptoms: | Related To: |
|
Description
When having high number of DBWR processes and under high system load, media recovery checkpoint can be slower due to significant waits on "latch: checkpoint queue latch", resulting in higher apply lag values. Workaround NONE
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/8019015/viewspace-2155824/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/8019015/viewspace-2155824/