如何搭建逻辑备库_SQL Apply与不支持的数据类型评估

SQL Apply 启动失败主因是备库控制文件残留主库“只读”标记或角色未正确设为PHYSICAL STANDBY需确保V$DATABASE中DATABASE_ROLEPHYSICAL STANDBY且OPEN_MODEMOUNTED并清理V$DATAGUARD_CONFIG中重复DB_UNIQUE_NAME。SQL Apply 启动失败报 ORA-16000 或 ORA-16025这是最常见的拦路虎备库启动 sql apply 时直接报错根本走不到日志应用阶段。本质不是权限或网络问题而是备库控制文件里残留了主库的“只读”标记或者数据库角色没真正切到 physical standby 状态。实操建议确认当前状态SELECT DATABASE_ROLE, OPEN_MODE FROM V$DATABASE; —— 必须是 PHYSICAL STANDBY MOUNTEDREAD ONLY 或 READ WRITE 都不行如果误开了 ALTER DATABASE OPEN READ ONLY得先关库再重启到 MOUNT不能靠 SHUTDOWN IMMEDIATE STARTUP MOUNT 蒙混过关某些版本会卡在 OPEN MODE MOUNTED 但角色仍是 PRIMARY检查 V$DATAGUARD_CONFIG 是否有重复或残缺的 DB_UNIQUE_NAME尤其当用 RMAN duplicate 搭建后未清理旧配置时ORA-16025 往往就出在这儿遇到 NUMBER(*,n)、XMLType、JSON 字段时 SQL Apply 自动跳过SQL Apply 不是万能重放器它依赖逻辑备库的“语义解析”能力对部分数据类型做硬性限制。一旦碰到不支持的类型日志应用不会报错中断而是静默跳过整条 DML —— 表面看着正常实际数据已不一致。关键判断点NUMBER 类型只要指定了精度如 NUMBER(10,2)就没问题但 NUMBER(*)即 NUMBER 无括号会被拒绝因为其内部存储长度动态变化逻辑备库无法预分配空间XMLType 在 12.1 默认禁用需显式设置 ENABLE PLUGGABLE DATABASE 并启用 XML DB 组件否则 SQL Apply 直接忽略含该字段的事务JSON 列12.2必须底层是 VARCHAR2 或 CLOB 存储若建表时用了 JSON 关键字但未指定 STORAGE IN ROW备库解析失败后同样跳过如何快速识别哪些表/列会触发 SQL Apply 兼容性告警别等上线后查 V$LOGSTDBY_EVENTS——那已经是事后补救。搭建期就得主动扫描重点不是看“支持列表”而是抓“实际被用到的类型”。执行这三步 MacsMind 电商AI超级智能客服