:

Data Guard Becomes out of Sync

If your Data Guard database gets out of sync and the archive log files are available, you can restore the log files at your primary DB (usually PRODUCTION), put the Data Guard database into recovery mode and then the logs will get shipped to your standby database automatically.

If you still have the archive logs but they are backed up, then you will need to restore them from backup first, to disk, before they can be shipped. This can be achieved using the following method:

— on Data Guard DB

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;

— on Primary DB

Find out which log sequence numbers you need from V$ARCHIVED_LOG

— Using RMAN substitute the sequence numbers in the below

run
{
Allocate channel c1 device type disk; 
Allocate channel c2 device type disk;
Allocate channel c3 device type disk;
restore archivelog from sequence = 12271 until sequence = 12300;
}

When you have got the log files on disk at the primary site the log shipping should start automatically, as Data Guard should attempt to resolve the gaps without any manual intervention.

Remember to delete the log files as you go along so there is enough space and make sure that the CPU isn’t too high on the server. It is just a case of working through all of the log files you need. If you are physically deleting the log files from the disk you may need to ensure that your database doesn’t think the logs are available on disk, by running a crosscheck command in RMAN, like so:

RMAN> CROSSCHECK ARCHIVELOG ALL;

If some are showing as “EXPIRED”, you can use the following command to clear it up:

RMAN> DELETE EXPIRED ARCHIVELOG ALL;

To reduce the CPU usage, allocate fewer channels. I would recommend starting with 1 and see how it goes. You can always increase it the next time around.

Like it, share it...

Category: Data Guard


Related Posts

Leave a Reply

Your email address will not be published. Required fields are marked *