Oracle Data Guard会主动对Hot数据（数据正被读取或修改）执行验证， 无论是primary还是standby，但对于那些Cold数据不会做任何检查和校验。所以在12.2版本中，引入了dbms_comp来验证校验Hot 和 Cold数据, 其可以确保standby端没有任何corruption，switchover 或failover后变成primary角色后可以正常运行。
执行DBMS_DBCOMP可以检测primary和standby的所有数据块，并进行一致性比较和standby写丢失。
SQL> select * from scott.emp;
select * from scott.emp
*
ERROR at line 1:
ORA-65478: shadow lost write protection - found lost write
相应的alertlog消息：
ERROR - I/O type:buffered I/O found lost write in block with afn:4 rdba:1000086. Expected
SCN:0x0000000000077d42 SCN in block:0x000000000007798b, approx current SCN:0x00000000000780d2, RAC instance:1
错误消息提到：其期望的scn：0x77d42即490818，而块读取却是scn 0x7798b即489867. 这意味着与上一次相比，Oracle收到了一个过时的版本 检查点（在SCN 490818）。这就表明写丢失。由于实际写入发生
在永久存储上，在Oracle RDBMS范围之外，我们需要进一步检查操作系统，卷管理或存储层，是导致丢失写入的实际原因。
当I / O子系统确认块写入完成时，发生数据块写丢失，但是写入并没有发生在永久存储器中。在随后的块中读取中，I / O子系统返回陈旧版本的数据块，可能用于更新数据库其他的块，从而造成corruption。
用法：
例如：我们有一个主数据库，它有一个或多个备数据库。当数据库挂载或打开时，在主数据库或备用数据库上执行DBMS_DBCOMP.DBCOMP
DBMS_DBCOMP.DBCOMP
（
datafile IN varchar2，
outputfile IN varchar2，
block_dump IN布尔值
）;
datafile -- 它可以是数据文件名或数据文件号。指定“ALL”来比较所有数据文件
其输出结果，可以帮助我们确定主备端是否存在潜在的block corruption。