CORRUPTION DETECTED: on Standby server

 CORRUPTION DETECTED: In redo blocks starting at block 2049count 1679 for thread 1



Problem Summary 

---------------------------------------------------
CORRUPTION DETECTED: In redo blocks starting at block 2049count 1679 for thread 1 sequence 7677

Problem Description
---------------------------------------------------
Primary database is in MAXIMUM PERFORMANCE mode
Thu Jun 05 13:38:37 2014
RFS[2849]: Assigned to RFS process 5367
RFS[2849]: Opened log for thread 1 sequence 7677 dbid 752265984 branch 834506114
RFS[2850]: Assigned to RFS process 5369
RFS[2850]: Selected log 6 for thread 1 sequence 7678 dbid 752265984 branch 834506114
CORRUPTION DETECTED: In redo blocks starting at block 2049count 1679 for thread 1 sequence 7677
Thu Jun 05 13:44:36 2014
RFS[2851]: Assigned to RFS process 5801
RFS[2851]: Opened log for thread 1 sequence 7636 dbid 752265984 branch 834506114
CORRUPTION DETECTED: In redo blocks starting at block 1count 2048 for thread 1 sequence 7636
Thu Jun 05 13:44:38 2014
ARCH: Archival stopped, error occurred. Will continue retrying
ORACLE Instance QPUATRD - Archival Error
ORA-16014: log 6 sequence# 7678 not archived, no available destinations
ORA-00312: online log 6 thread 1: '/u02/oracle/oradata/orcl/stdby02.log' 

Suggested Solution:

The suggested solution is make sure the following firewall and router features are disabled.
- SQLNet fixup protocol
- Deep Packet Inspection (DPI)
- SQLNet packet inspection
- SQL Fixup
- SQL ALG (Juniper firewall) 




What happens when corruption occurs in standby?

If the redo gets corrupted before being applied to the standby then it cannot be applied and (hopefully) the standby requests the primary to resend the redo.
MRP cannot continue applying unless it has none corrupted redo to apply. At this point the thing to do is check to see that the standby is in sync.
If so then it is good. Corrupted data is propagated to a standby and applied when it is valid redo. So that is mostly logical corruption in primary database data files that gets propagated and applied.

You can check that the standby is in sync two ways

set lines 500
select * from v$dataguard_stats ;

And these queries: One for the primary and 2 for the standby.

Primary: SQL > select thread#, max(sequence#) "Last Primary Seq Generated"
from v$archived_log val, v$database vdb
where val.resetlogs_change# = vdb.resetlogs_change#
group by thread# order by 1;

PhyStdby: SQL > select thread#, max(sequence#) "Last Standby Seq Received"
from v$archived_log val, v$database vdb
where val.resetlogs_change# = vdb.resetlogs_change#
group by thread# order by 1;

PhyStdby: SQL > select thread#, max(sequence#) "Last Standby Seq Applied"
from v$archived_log val, v$database vdb
where val.resetlogs_change# = vdb.resetlogs_change#
and applied='YES'
group by thread# order by 1;