This article explains how to resolve archive apply error in standby when we get ORA-00354 error.
Archive apply fails with error
Applicable Error Code
Dbvisit Standby terminated...
Error Code: 2001
ORA-00354: corrupt redo log block header
Noticed in DB version 188.8.131.52 , Noticed in standby version 8.0 (But independent of both)
Noticed in Windows.
Archive apply fails in the standby, Below is the full error.
C:\Program Files\Dbvisit\Standby>dbvctl -d TEST ============================================================= Dbvisit Standby Database Technology (184.108.40.20645) (pid 5568) dbvctl started on dbvlab03: Fri May 5 16:11:42 2017 ============================================================= >>> Applying Log file(s) from dbvlab01 to testdb on dbvlab03: Dbvisit Standby terminated... Error Code: 2001 ORA-00354: corrupt redo log block header Tracefile from server: dbvlab03 (PID:5568) 5568_dbvctl_TEST_201705051611.trc
#1. Try re-sending the archivelog from the primary using the below command
dbvctl -d <ddc> -r <corrupted archlog> -t 1 (Version 8.0)
dbvisit -r <SEQUENCE_NUMBER> <DDC> (Version 7.0)
dbvctl -d TEST -r 4567 -t 1
#2. Try applying the archivelogs in the standby.
dbvctl -d TEST (Version 8.0)
dbvisit TEST (Version 7.0)
#3. If the above does not work, you can synchronize the standby to make the database in sync with the primary and continue with archive send and apply. Before running the synchronize make sure your schedules are disabled.
https://dbvisit.atlassian.net/wiki/display/DS8QSG/The+Synchronise+Standby+Database+Option (Version 8.0)
https://dbvisit.atlassian.net/wiki/display/UGDS7/Synchronize+a+Standby+Database (Version 7.0)
As you find we tried switchover but did not get success then we checked logs and find there was a space issue then we there was space available around 3.8 GB but the inode was full (100%)so made some space and then tried synchronization but it was also failed at the final step got an error which was the same (space issue) then tried to send and apply log manually but while apply logs the same issue occurred. Then we put some effort to make availability of inode so now 15% of inode available, after that, we executed resynch with '-R' option, it got succeeded and then I tried to send and apply the logs but the similar error was generated while applying logs.
Please suggest what we should do next time before executing the switchover?