【DB2】关于HADR同步后出现restore pending状态的问题分析

📅 发布时间:2026/7/12 2:01:32 👁️ 浏览次数:
【DB2】关于HADR同步后出现restore pending状态的问题分析
背景生产环境需要将原有一主一备 DB2 HADR 架构扩容为一主两备提升高可用能力。整体操作流程主库正常备份备库执行 RESTORE 恢复修改 HADR 相关参数启动 HADR 同步问题现象新备机恢复后查看表空间状态看似正常等待 HADR 日志 GAP 变为 0 后备机状态异常0x00000100HADR 无法正常同步初步排查与误区误区 1怀疑是 RESTORE 恢复方式问题库中存在大量非自动管理表空间以往恢复习惯使用重定向脚本本次因主备路径一致未使用重定向直接恢复怀疑恢复不规范重新用重定向脚本再恢复一次结果问题依旧排除恢复脚本原因误区 2怀疑 LOAD 共享目录 / 权限 / 日志传输问题主库存在大量 LOAD 操作优先往 LOAD 方向排查检查 db2set 中配置的 LOAD 共享目录权限正常检查 HADR 日志传输日志正常发送、接收无堆积结果排除 LOAD 目录权限与日志传输问题关键突破测试环境场景化复现生产恢复耗时太长直接在测试环境模拟两种关键场景场景 1备份 → 搭建 HADR → 执行 LOAD→ 结果正常无 0x00000100 异常场景 2备份 → 执行 LOAD → 搭建 HADR→ 复现 0x00000100 表空间异常根因定位回到生产环境操作时序复盘先做了数据库备份备份之后、搭建 HADR 之前主库有 LOAD 操作产生新日志这部分关键 LOAD 日志丢失 / 不完整备机通过备份恢复后HADR 同步时缺少这段日志最终导致备机表空间状态异常0x00000100一句话总结备份后、HADR 搭建前的 LOAD 日志丢失 错误操作顺序导致备机日志不连续表空间状态异常。经验与避坑指南HADR 扩容 / 搭建前尽量保证备份后无大操作尤其是 LOAD、REDISTRIBUTE 这类会产生特殊日志的操作。严格控制操作顺序推荐静止业务 / 禁止 LOAD → 备份 → 立即搭建 HADR → 再恢复业务 / LOAD一主多备扩容时务必保证备份集完整备份时间点到 HADR 启动前所有归档日志完整可访问LOAD 共享目录日志不丢失、不清理太早遇到 0x00000100 优先排查日志是否连续是否有 LOAD 操作跨在备份与 HADR 搭建之间备机是否缺失关键日志段以下为测试环境试验过程搭建HADR步骤省略搭建HADR后LOAD报错SQL1477NLOAD后搭建HADR报错先备份传输备份到备机再load再在备机恢复并搭建HADR查看备机表空间状态查询该表空间下的表处理方法使用LOAD后新的全量备份或者增量备份恢复表空间状态正常