Oracle 19c中如何通过Lost Write Protection增强容灾数据完整性？

Oracle 19c中DB_LOST_WRITE_PROTECT默认值自19.26起由NONE改为AUTO，但实际启用依赖ADG配置：主库需有启用实时重做应用的物理备库，备库则根据应用延迟动态降级；TYPICAL仅记录READ WRITE表空间缓存读，FULL额外覆盖READ ONLY表空间，性能开销更大且极少必要；启用后ORA-19599等报错多为假阳性，需结合v$managed_standby等视图排查，并必须配合DB_BLOCK_CHECKSUM=FULL才能生效。

oracle 19c 中开启 db_lost_write_protect 能显著提升 adg 环境下对“数据块丢失写”故障的识别能力，但它本身不防止丢失写发生，也不替代 data guard 的日志传输机制——它只让问题在恢复或备库应用时暴露出来，避免静默数据损坏。

为什么 19.26+ 版本必须关注 DB_LOST_WRITE_PROTECT 的默认值变化

从 19c RU 19.26 开始，DB_LOST_WRITE_PROTECT 默认值从 NONE 变为 AUTO。这个变化看似平滑，但实际行为依赖 Data Guard 配置状态：

• AUTO 在主库上仅当存在启用实时重做应用（Real Time Redo Apply）的物理备库时，才记录缓冲区读取操作到重做日志；否则退化为 NONE 行为
• AUTO 在备库上会动态判断重做应用延迟：若延迟超过阈值（60 秒，或 FSFO 阈值 × 2/3），自动跳过检测以保障角色切换速度
• 这意味着：没配好 ADG 或备库同步滞后时，AUTO 实际等同于未启用保护，且你可能完全意识不到
• 检查当前值用：show parameter db_lost_write_protect，别只信文档说“默认开了”

TYPICAL 和 FULL 在 ADG 场景下的真实差异

选择 TYPICAL 还是 FULL，关键看你的表空间读写属性和容灾恢复预期：

• TYPICAL：只对 READ WRITE 表空间的缓存读操作记入重做日志，这是检测丢失写的最小必要开销；备库启用后，会在应用重做时校验块 SCN 是否倒退
• FULL：额外覆盖 READ ONLY 表空间的读操作日志记录——这在 ADG 中极少必要，因为只读表空间本不该被修改，且其块变更通常来自主库 DDL 或只读转读写操作
• 性能影响：启用 TYPICAL 后主库重做日志量增加约 3%~8%，集中在高并发 SELECT + UPDATE 混合负载场景；FULL 增幅无明显额外收益，反而可能放大日志传输压力
• 真正需要 FULL 的场景极少，比如主库频繁执行 ALTER TABLESPACE ... READ WRITE 切换，且该表空间有大量历史数据块被反复读取

ADG 环境中启用后最常遇到的两个误判现象

启用 DB_LOST_WRITE_PROTECT 后，不是所有报错都代表真实丢失写，尤其在 ADG 同步链路中容易触发假阳性：

• 备库日志中出现 ORA-19599（block lost write detected）但主库对应 SCN 时间点无异常：大概率是备库重做应用延迟 + 主库归档日志被提前覆盖，导致校验时找不到原始块镜像，而非磁盘写失败
• 主库 alert.log 出现 Lost write detection: block ... in file ... is stale，但 v$database_block_corruption 为空：说明检测机制已生效，但该块尚未被后续 DML 触发重写，此时需人工用 BEGIN DBMS_REPAIR.CHECK_OBJECT 扫描确认
• 不要一看到 ORA-19599 就立刻停业务查存储——先查 v$managed_standby 确认 MRP 进程是否卡住、v$archive_dest_status 看归档传输是否堆积
• 启用后务必配合 DB_BLOCK_CHECKSUM=FULL，否则丢失写检测可能因校验和未启用而漏判

真正起作用的时刻，往往发生在故障切换后的第一次 OPEN RESETLOGS 或备库主动执行 RECOVER —— 那时候日志里埋的读操作标记才会被用来比对块 SCN。别指望它实时报警，它更像一个“事后取证开关”，开得越早，证据链越完整。