Checker run found 1 new persistent data failures

I saw this in the alert.log file for a standby database. I didn’t find much information on it during a search so I figured I’d put a post together.

Checker run found 1 new persistent data failures

Here is the full text of what I was seeing in the alert.log.

Mon Feb 09 08:39:43 2015
Media Recovery Log +LOGDBORCL/DBORCL/ARCHIVELOG/2015_02_09/thread_1_seq_10725.279.871201587
Media Recovery Waiting for thread 1 sequence 10726 (in transit)
Mon Feb 09 08:40:22 2015
Checker run found 1 new persistent data failures

This standby database is fully configured with data guard broker and standby redo logs. The standby redo logs were not being used as witnessed by the use of archive log files in output above.

The reason the standby redo logs were not being used is because we had performed a snapshot of the disks used by ASM, mounted them on another server, and recovered the database to managed standby. However, we had missed a step to rebuild the standby redo logs. Thus, the standby redo logs on the standby database were copies of Even though this was an oversight I wanted to document the alert.log errors and the solution.

-- Stop managed standby.
alter database recover managed standby database cancel;

-- Rebuild all of the standby redo logs.
alter database drop logfile group 21;
alter database add standby logfile group 21 ( '+LOGDBORCL/DBORCL/stby_log21.ora' ) size 1073741824 reuse;

    ... repeat for all standby redologs (11 in my case)

-- Restart managed recovery.
alter database recover managed standby database disconnect;

After rebuilding the standby redo logs – on the standby database only – the database reverted to using standby redo logs as indicated by the following line in the alert.log.

Recovery of Online Redo Log: Thread 1 Group 21 Seq 10748 Reading mem 0
  Mem# 0: +LOGDBORCL/DBORCL/stby_log21.ora

Post a Comment