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

SQL Apply 启动失败主因是备库控制文件残留主库“只读”标记或角色未正确设为PHYSICAL STANDBY；需确保V$DATABASE中DATABASE_ROLE=PHYSICAL STANDBY且OPEN_MODE=MOUNTED，并清理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 + MOUNTED，READ 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超级智能客服