Oracle DG备库应用延迟问题分析处理

1.情况说明

分享一个之前的案例,客户备库出现间歇性的日志应用延迟,延迟最高时刻需经过约50分钟左右才能将日志追平。

2.详细记录

2.1、问题发现

数据库的DG1备库出现间歇性的日志应用延迟,具体表现为备库apply lag延迟过高。影响到数据库的实时同步传输,增加潜在的数据安全风险。

2.2、问题分析

DG配置参数检查:

经检查,备库参数符合标准规范。

备库日志应用状态检查:

MRP0状态为applying状态,表明备库正在做日志应用。

DG告警提示检查:

无error项,且状态为valid,说明无传输性异常。

主库日志产生量分析:

通过上面可以看到,主库日志在一定时间内产生了较多的归档量,说明主库业务发生了变化。

主库alert告警日志分析:

我们以下午3点到4点的日志为例,伴随着业务量的提升,主库产生的归档量增加,这也就意味着备库需要传输和应用的归档也会同步增加,通过alert日志可以看到,在业务高峰期,备库所有standby redo 都处于active状态,无法接收thread 1的日志,因此造成了日志的应用延迟。

3.解决建议

经过认真分析,备库出现日志应用延迟与业务特点有关,与standby redo log组数有关,在业务高峰期时刻,主库日志切换频繁,备库日志来不及应用,导致短期内暂无空闲的standby redo log接收主库传输过来的日志,引发数据延迟,当前备库standby redo log比主库多1组,建议增加备库standby redo log 组数,再行观察。

相关推荐
tiancaijiben1 天前
阿里云SSL证书自动续签与部署完全指南:从托管服务到开源工具全方案解析
数据库
全堆鸿蒙1 天前
25 数据库设计与表结构规划:5 张表的设计思路
数据库·华为·cocoa·harmonyos
笃行3501 天前
【金仓数据库产品体验官】_坏得起_实测:备份恢复、PITR 时间穿越与主备切换——KingbaseES V9R3C18 深度体验(三)
数据库
笃行3501 天前
从兼容到进阶:驱动直连、窗口函数与动态 SQL 实测——KingbaseES V9R3C18 深度体验(二)
数据库
笃行3501 天前
MySQL 的 JSON 字段迁到金仓还能用吗?——KingbaseES V9R3C18 JSON 操作符与函数兼容实测
数据库
IpdataCloud1 天前
跨境AI金融风险怎么防?IP风险画像的实战应用指南
数据库·tcp/ip·金融·ip
Alan_751 天前
API 接口慢调用根因定位:从 TCP 建连到数据库 IO 的全栈排查实战
数据库
多巴胺梦想家1 天前
事务与并发控制:当多人同时操作数据库
服务器·数据库·oracle
howard20051 天前
PostgreSQL起步
数据库·postgresql
秋田君1 天前
QT_QT布局详解
开发语言·数据库·qt