oracle 19c data guard 的“零丢失”能力仅在maximize protection或availability模式下、sync传输启用且网络稳定时生效，需通过保护模式、传输状态、validate database及故障演练综合验证。
Oracle 19c Data Guard 的“零丢失”能力不是默认开启的，它只在最大保护（MAXIMIZE PROTECTION）或最大可用性（MAXIMIZE AVAILABILITY）模式下、且网络与备库稳定时才实际生效。验证前必须先确认保护模式和实时传输状态，否则所有校验都无意义。
检查当前保护模式是否启用 SYNC 传输
保护模式决定了日志是否同步写入备库。仅靠 SELECT protection_mode, protection_level FROM v$database; 不够，还需确认底层传输是否真走 SYNC：
- 查
v$archive_dest_status中目标备库的transmit_mode字段：值为SYNC才表示强制同步；ASYNC或空值即不满足零丢失前提 - 查
v$dataguard_config确认该备库的log_xpt_mode是SYNC（注意：此字段在 19c 中已弃用，以v$archive_dest_status为准） - 若使用 Data Guard Broker，运行
SHOW DATABASE verbose <db_unique_name>;</db_unique_name>，观察输出中LogXptMode是否为SYNC - 最大保护模式下，一旦所有备库不可用，主库会直接 shutdown —— 这是验证其“零丢失决心”的最直接证据，但生产环境慎用
验证主库提交是否真实等待备库确认
即使配置了 SYNC，也可能因参数或网络问题降级。关键看事务提交时的行为：
- 在主库执行
ALTER SYSTEM SWITCH LOGFILE;后，立即查v$archived_log，确认刚生成的日志dest_id对应的备库记录中status为A（Archived），且completion_time与主库归档时间差 ≤ 1 秒 - 启用 SQL Trace（
ALTER SESSION SET EVENTS '10046 trace name context forever, level 8';），执行一个简单 INSERT+COMMIT，查看 trace 文件中是否有LGWR ASYNC或LGWR SYNC等字样 —— 只有SYNC表示主库 LGWR 真正在等备库 ACK - 检查
v$managed_standby中process=LNS的状态：status应为WRITING，client_process应为LGWR；若为ARCH，说明已退化为异步归档
用 VALIDATE DATABASE 检测 SCN 是否真正连续
零丢失不仅要求日志传过去，还要求每个 SCN 都被完整接收并可衔接。VALIDATE DATABASE ARCHIVELOG ALL; 是唯一能暴露“隐形缺口”的命令：
- 必须在备库
MOUNT状态下执行（不能 OPEN），且 RMAN 连接的是目标数据库（非 catalog） - 输出中出现
Archive Log SCN Gap或Missing Archive Log即表示已有数据丢失风险 —— 即使v$archive_gap为空，这个命令仍可能报 gap，因为它校验的是物理文件 + 控制文件元数据 + SCN 链三者一致性 - 若备库配置了
DELAY，需先确认延迟已超时，否则 VALIDATE 会把未到时间的日志误判为缺失 - 该命令不校验文件内容损坏，所以还需配合
RMAN VALIDATE ARCHIVELOG ALL;做二次校验
模拟主库故障并验证备库是否拥有全部已提交事务
最终验证必须落在“故障后能否不丢数据”上，不能只看监控指标：
- 在主库执行一个带明确标记的事务（如
INSERT INTO test_scn VALUES (SYSDATE, DBMS_FLASHBACK.GET_SYSTEM_CHANGE_NUMBER); COMMIT;），记下 SCN 值 - 立即 kill -9 主库实例（或拔网线），强制中断
- 在备库执行
RECOVER MANAGED STANDBY DATABASE FINISH;→ALTER DATABASE ACTIVATE PHYSICAL STANDBY DATABASE; - 启动新主库后查
test_scn表，确认刚才插入的 SCN 是否存在；再查SELECT current_scn FROM v$database;，对比是否 ≥ 记录的 SCN - 注意：此操作会破坏原 Data Guard 配置，仅限测试环境；生产环境建议用
FAILOVER命令替代手动激活
真正难验证的点在于“瞬态故障下的行为”——比如网络抖动 2 秒、备库 LGWR 写磁盘慢、主库高并发导致 LNS 进程排队。这些场景下 SYNC 可能临时降级，而监控视图未必立刻反映。所以日常必须结合 v$archive_dest_status 的 error 字段、告警日志里的 ORA-16057、以及每 5 分钟一次的 VALIDATE DATABASE 自动巡检，才能守住零丢失底线。
