dbms_comparison适用于主备库均open状态下的离线行级数据一致性校验，如迁移后抽样核验、补丁升级后关键表验证或跨库etl结果比对，不适用于data guard物理层同步验证。
dbms_comparison 不是 data guard 原生同步校验工具，它只比数据，不验证日志应用状态或块级物理一致性；用错场景会漏掉写丢失、逻辑坏块等关键问题。
DBMS_COMPARISON 适合什么场景
它适用于已知主备库都处于 OPEN 状态、且你明确想确认「某张表的行级数据是否完全一致」的离线比对。比如迁移后抽样核验、补丁升级后关键业务表校验、或跨库 ETL 结果验证。
- 必须两端数据库都能直连（通过 database link），且目标对象是堆表、IOT 或只读视图
- 不支持 LOB、LONG、ROWID、分区表单分区、临时表 —— 遇到就直接报
ORA-42387或跳过 - 比较过程会加
SELECT FOR UPDATE锁（默认行为），若表正在被大量 DML 修改，COMPARE可能长时间等待甚至失败 - 结果不实时：差异记录进
DBA_COMPARISON_ROW_DIF，不是函数返回值，查前得先确认SCAN_ID
为什么不能直接用 DBMS_COMPARISON 替代 DG 同步验证
它只读取逻辑数据（SQL 层面），完全绕过 Redo Apply 过程和数据文件物理结构。这意味着：
- 主库已提交、但备库归档未传输完 →
COMPARE仍可能返回“一致”，因为查的是当前备库可见数据 - 备库存在写丢失（lost write）或内存损坏导致的块头/尾校验和错误 →
COMPARE完全感知不到，照样返回 TRUE - 主库某行被逻辑删除（如误删后闪回），但备库没同步该 undo 记录 → 表面行数相同，实际内容错位，
COMPARE可能因排序依赖出错而漏比
真正该用什么验证 Data Guard 数据一致性
按风险等级分层选工具：
- 查日志是否真在应用：
SELECT PROCESS, STATUS, SEQUENCE#, BLOCK#, BLOCKS FROM V$MANAGED_STANDBY+SELECT APPLIED_SCN, LAST_APPLIED_TIME FROM V$DATAGUARD_STATS - 查物理块是否损坏（含写丢失）：
RMAN BACKUP VALIDATE DATABASE（主备都可跑，兼容性好）或DBMS_DBCOMP.DBCOMP('ALL', '/tmp/dbcomp.out', FALSE)（仅 12.2+ 备库，需 MOUNT/OPEN） - 查加密表空间或跨大版本（如主 19c / 备 12c）时的块级可信度：禁用
DBMS_DB_VERIFY，改用RMAN VALIDATE，并比对SELECT DBMS_DB_VERSION.VERSION FROM DUAL两端结果
DBMS_COMPARISON 的价值在于“语义层可信”，不是“存储层可信”。别让它替你扛 Data Guard 的物理一致性责任 —— 那块儿的坑，得靠 RMAN 或 DBMS_DBCOMP 踩实了才算数。
