12.2Data Guard新特性--使用DBMS_DBCOMP.DBCOMP数据比较

      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。

转载于:https://www.cnblogs.com/DataArt/p/10018704.html