Scribd
Upload
114 views3 pages

Misconception of Archive Log Sequences in Data Guard

This document discusses a common misconception about archive log sequences in Oracle Data Guard configurations. When failovers occur, old archive log sequences from previous instances can remain registered in the control file, even if those logs no longer exist. This can make it appear that the primary and standby databases are out of sync when they are actually in sync. The document recommends several ways to clean up the control file, such as recataloging logs, clearing sections of the control file, or using DBMS_BACKUP_RESTORE to reset sections, in order to remove references to old archive log sequences and correctly represent the current state of the primary and standby databases.

Uploaded by

nizam
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
114 views3 pages

Misconception of Archive Log Sequences in Data Guard

This document discusses a common misconception about archive log sequences in Oracle Data Guard configurations. When failovers occur, old archive log sequences from previous instances can remain registered in the control file, even if those logs no longer exist. This can make it appear that the primary and standby databases are out of sync when they are actually in sync. The document recommends several ways to clean up the control file, such as recataloging logs, clearing sections of the control file, or using DBMS_BACKUP_RESTORE to reset sections, in order to remove references to old archive log sequences and correctly represent the current state of the primary and standby databases.

Uploaded by

nizam
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 3

Misconception of Archive Log Sequences in Data Guard

February 4th, 2013 | Posted by [email protected] in Administration | Data Guard


Misconception of Archive Log Sequences in Data Guard
I have read in OTN forums and personally went though such misconception of archive log sequences in primary, We
will go in detail to understand why sequence number is showing higher value(Ex: 50) in “v$archived_log” even
though the current log sequence(SQL> archive log list) is very low  Ex: 5-6.

This behavior because of registering the old incarnation sequences with the recent control file, If you are using FRA
or try to register the archive log location when there are old incarnation sequences exist in the same location. The old
incarnation sequences can persist if we haven’t cleaned up after several Drills(Fail-over/Switchover). I did several
drills before writing this small article how the log sequences will be updated with control file. By thus you cannot
estimate or use views to check the synchronization between primary and standby database(s). So consider to
cleanup them by several procedures. We will discuss available scenarios.

Now lets check what is the maximum sequence archived on primary with the first query  and second query output
shows what is the log sequence applied on standby with the GAP.

PRIMARY
SQL>  select max(sequence#) from v$archived_log;
MAX(SEQUENCE#)
--------------
            56
SQL>
DB_NAME    HOSTNAME       LOG_ARCHIVED LOG_APPLIED APPLIED_TIME   LOG_GAP
---------- -------------- ------------ ----------- -------------- -------
ORCL       ORACLE-PRIMARY           56          48 03-FEB/19:17         8

So the maximum archived sequence on primary is “56″ and log applied on standby is “48″ from primary and the GAP
stated as “8″. Initially we start troubleshoot to fix the archive gaps of “8″ and after all the troubleshooting part found
that there is no archive with “56″ on primary and the current log sequences is just “7″ from the below output.

SQL> archive log list

Database log mode              Archive Mode

Automatic archival             Enabled

Archive destination            USE_DB_RECOVERY_FILE_DEST

Oldest online log sequence     5

Next log sequence to archive   7

Current log sequence           7

SQL>

Here the problem is only from the primary database and you can see from below output what is the maximum
sequence applied on the standby database.
STANDBY
SQL>  select max(sequence#) from v$archived_log where applied='YES';
MAX(SEQUENCE#)
--------------
             6
SQL>
So what’s wrong with the view “v$archived_log” ? Of course if you check the “RESETLOGS_CHANGE#” from the
“v$archived_log” then you can see multiple “RESETLOGS_CHANGE#” this is because of previous fail-overs the old
incarnation sequence numbers are still registered too. So how to cleanup those archives? You have several ways

1) Re-create Control file

– This is not always possible because you need downtime of primary/production database.

2) Uncatalog archive log files.

– By this procedure you can uncatalog all of the archives and after removing old incarnation archives again we can
register them as below steps.

RMAN> change archivelog sequence 1 uncatalog;


RMAN> change archivelog all uncatalog;
RMAN> catalog start with ‘archive log location’;
3) Clear the section in the controlfile which contains data referencing v$archived_log, May be in view
“v$archived_log” it can contain information of destinations 1 to 30, This below procedure describes process of only
keeping entries from one distinct location. The package “dbms_backup_restore.resetCfileSection” refers to
different sections such as cleanup of “v$archived_log” and cleanup of backups so on.

Now gather information to verify the number of sequences after executing the package.

SQL> select count(*) from v$archived_log;

COUNT(*)

----------

237

SQL>

Run the below DBMS package from “SYS” user.

SQL> execute sys.dbms_backup_restore.resetCfileSection( 11);


PL/SQL procedure successfully completed.
SQL>

Check again how many entries exist in v$archived_log?

SQL> select count(*) from v$archived_log;

COUNT(*)
----------

SQL> select sequence#,applied from v$archived_log;

no rows selected

SQL>

Register existing archive log files with Control file as below. Before this step ensure there are no archive log
sequences of old incarnation. 
RMAN> catalog start with ‘Archive Log Location’;
Note:- Prior to this entire operation, Recommended to take Full backup.
After registering the archive sequences of current “RESETLOGS_CHANGE#” then you can check the sequence
numbers of primary and standby database(s) and also synchronization between primary and standby databases.

– Happy Reading–

You might also like