CORRUPTION DETECTED: In redo blocks starting at block in dataguard

If this error comes in dataguard (physical standby) database, oracle will automatically delete the corrupted archived log file and then we would require to copy the affected archived log from the primary site and so that managed recovery could proceed. I was thinking that oracle should automatically fetch the affected/corrupted archived log itself from the primary site, but then I realized the reason of not happening this automatically and I will explain the reason later.

Once this type of corruption is detected, following type of message is shown in the alert log file.

Fri Jan 26 06:58:04 2018 RFS[20]: Possible network disconnect with primary database Fri Jan 26 07:00:31 2018 RFS[21]: Assigned to RFS process 383490 RFS[21]: Opened log for thread 1 sequence 42623 dbid -1615019445 branch 926366821 CORRUPTION DETECTED: In redo blocks starting at block 2049count 2048 for thread 1 sequence 42623 Deleted Oracle managed file +RECO/mydg/archivelog/2018_01_26/thread_1_seq_42623.11622.966409233 Fri Jan 26 07:03:36 2018 Archived Log entry 171057 added for thread 1 sequence 42624 rlc 926366821 ID 0xa23cad4c dest 3: Fri Jan 26 07:03:38 2018

To solve this problem, copy this archived log file from the primary site and start managed recovery again.

While working on this issue, I faced a strange problem. In my 4 nodes RAC database, even after copying the archived sequence number 42623 (thread 1) to the standby RAC, managed recovery did not proceed and it kept showing message as follows. New archived logs kept coming but managed recovery was stuck on sequence number 42623.

Mon Jan 29 12:21:13 2018 Media Recovery Waiting for thread 1 sequence 42623 (in transit) Completed: ALTER DATABASE RECOVER  managed standby database using current logfile disconnect from session Mon Jan 29 12:35:52 2018 Archived Log entry 172350 added for thread 4 sequence 43335 rlc 926366821 ID 0xa23cad4c dest 3: RFS[30]: No standby redo logfiles available for thread 4 RFS[30]: Opened log for thread 4 sequence 43336 dbid -1615019445 branch 926366821 Mon Jan 29 12:50:53 2018 Archived Log entry 172354 added for thread 4 sequence 43336 rlc 926366821 ID 0xa23cad4c dest 3: RFS[30]: No standby redo logfiles available for thread 4

The reason of recovery process being stuck on this archived log sequence was that there was another RAC instance currently stuck on fetching/working this sequence number and therefore the current instance where MRP was being started was not able to apply this archived log.

To solve the problem, I shutdown all 4 instances of my standby database and then started the database, after that I initiated managed recovery and recovery started smoothly this time.