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。别指望它实时报警，它更像一个“事后取证开关”，开得越早，证据链越完整。
