Scribd
Upload
3 views

Fix Dataguard Archivelog Gap While Archivelog Files Backed Up and Deleted

The document outlines procedures to fix archivelog gaps in a Dataguard environment when archivelog files are backed up and deleted from the primary database without being shipped to the standby database. Two solutions are provided: one for restoring archivelog files to the default destination and another for a non-default destination, detailing steps for checking gaps, restoring files, and ensuring proper configuration for shipping and applying logs. The document emphasizes the importance of maintaining adequate log switch information and provides SQL commands for monitoring and resolving the gaps.

Uploaded by

Ahmed Abd El Latif
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
3 views

Fix Dataguard Archivelog Gap While Archivelog Files Backed Up and Deleted

The document outlines procedures to fix archivelog gaps in a Dataguard environment when archivelog files are backed up and deleted from the primary database without being shipped to the standby database. Two solutions are provided: one for restoring archivelog files to the default destination and another for a non-default destination, detailing steps for checking gaps, restoring files, and ensuring proper configuration for shipping and applying logs. The document emphasizes the importance of maintaining adequate log switch information and provides SQL commands for monitoring and resolving the gaps.

Uploaded by

Ahmed Abd El Latif
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/ 4

Fix Dataguard Archivelog Gap While Archivelog Files Backed Up and

Deleted
Issue Description:

The archivelog files were backed up using RMAN and deleted from the primary database and were not
shipped to the standby database.

Error message in the standby database alert log file will be like this

FAL[client]: Failed to request gap sequence


GAP - thread 1 sequence 37-43
DBID 1789596466 branch 808476410
FAL[client]: All defined FAL servers have been attempted.
------------------------------------------------------------
Check that the CONTROL_FILE_RECORD_KEEP_TIME initialization
parameter is defined to a value that's sufficiently large
enough to maintain adequate log switch information to resolve
archivelog gaps.
------------------------------------------------------------
Sun Nov 24 09:46:37 2013
Archived Log entry 173 added for thread 1 sequence 48 ID 0x6aaf0ffb dest 1:
Sun Nov 24 09:46:44 2013
Standby controlfile consistent with primary
RFS[4]: Selected log 5 for thread 1 sequence 50 dbid 1789596466 branch 808476410
Sun Nov 24 09:46:53 2013
Archived Log entry 174 added for thread 1 sequence 49 ID 0x6aaf0ffb dest 1:
Sun Nov 24 09:47:06 2013
Standby controlfile consistent with primary
RFS[4]: Selected log 4 for thread 1 sequence 51 dbid 1789596466 branch 808476410
Sun Nov 24 09:47:16 2013
Archived Log entry 175 added for thread 1 sequence 50 ID 0x6aaf0ffb dest 1:

Issue Solution 1: If you will restore the archivelog files to the default archivelog destination on the
primary

To fix this gap issue you need to restore the missing archivelog files from RMAN backup taken from the
primary database to the default archive log destination and they will be shipped and applied
automatically on the standby database.

To do this action plan you need to go through the following steps:

Step 1: On the standby database check the missing log sequence numbers causing this gap

select * from v$archive_gap;


And the output will be like this

Thread Low Sequence High Sequence


---------- ------------ -------------
1 37 43

Step 2: On the primary database, restore the missing archivelog files from RMAN backup taken

RUN {
CONFIGURE DEFAULT DEVICE TYPE TO DISK;
ALLOCATE CHANNEL t1 TYPE DISK ;
RESTORE ARCHIVELOG FROM logseq=37 UNTIL LOGSEQ=43 thread 1;
RELEASE CHANNEL t1;
}

Step 3: On the primary database ensure that LOG_ARCHIVE_DEST_STATE_2 parameter is enabled to be


able to ship the restored archivelog files to the standby database

show parameter LOG_ARCHIVE_DEST_STATE_2

Step 4: Start the managed standby apply process on the standby database

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT
FROM SESSION;

Step 5: Now check the gap between primary and standby it will be fixed

select al.thrd "Thread", almax "Last Seq Received", lhmax "Last Seq Applied"
from (select thread# thrd, max(sequence#) almax
from v$archived_log
where resetlogs_change#=(select resetlogs_change# from v$database)
group by thread#) al,
(select thread# thrd, max(sequence#) lhmax
from v$log_history
where resetlogs_change#=(select resetlogs_change# from v$database)
group by thread#) lh
where al.thrd = lh.thrd order by "Thread";

Issue Solution 2: If you will restore the archivelog files to a none default archivelog destination on the
primary

Step 1: On the standby database check the missing log sequence numbers causing this gap
select * from v$archive_gap;

And the output will be like this

Thread Low Sequence High Sequence


---------- ------------ -------------
1 37 43

Step 2: On the primary database, restore the missing archivelog files from RMAN backup taken to
another destination and in our case we choose /tmp

RUN {
CONFIGURE DEFAULT DEVICE TYPE TO DISK;
ALLOCATE CHANNEL t1 TYPE DISK ;
SET ARCHIVELOG DESTINATION TO '/tmp';
RESTORE ARCHIVELOG FROM logseq=37 UNTIL LOGSEQ=43 thread 1;
RELEASE CHANNEL t1;
}

Step 3: On the primary database, copy the archivelog files restored from RMAN backup to the standby
database

cd /tmp

scp *.arc oracle@standby-server:/tmp

Step 4: On the standby database register the copied archivelog files in the controlfile

ALTER DATABASE REGISTER LOGFILE '/tmp/arch_t1_s37.arc';

ALTER DATABASE REGISTER LOGFILE '/tmp/arch_t1_s38.arc';

ALTER DATABASE REGISTER LOGFILE '/tmp/arch_t1_s39.arc';

ALTER DATABASE REGISTER LOGFILE '/tmp/arch_t1_s40.arc';

ALTER DATABASE REGISTER LOGFILE '/tmp/arch_t1_s41.arc';

ALTER DATABASE REGISTER LOGFILE '/tmp/arch_t1_s42.arc';

ALTER DATABASE REGISTER LOGFILE '/tmp/arch_t1_s43.arc';

Step 5: On the standby database, start the managed standby apply process on the standby database
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT
FROM SESSION;

Step 6: Now check the gap between primary and standby it will be fixed

select al.thrd "Thread", almax "Last Seq Received", lhmax "Last Seq Applied"
from (select thread# thrd, max(sequence#) almax
from v$archived_log
where resetlogs_change#=(select resetlogs_change# from v$database)
group by thread#) al,
(select thread# thrd, max(sequence#) lhmax
from v$log_history
where resetlogs_change#=(select resetlogs_change# from v$database)
group by thread#) lh
where al.thrd = lh.thrd order by "Thread";

You might also like