To Check the below query to confirm ARCHIVE GAP Primary and Standby servers.
A Physical Standby database syncs with Primary by continuous apply of archive logs from a Primary Database.
When the logs are missing on standby difference is huge (Suppose more than 600 logs), you have to rebuild the standby database from scratch.
Please use below query to find out archive gap on Standby STEP 1:
set time on
set lines 200
prompt ++++++++++++++++++++LAST SEQUENCE RECIEVED FROM PRODUCTION and APPLIED ON STANDBY+++++++++++++++++++++++++
SELECT ARCH.THREAD# "Thread", ARCH.SEQUENCE# "Last Sequence Received", APPL.SEQUENCE# "Last Sequence Applied", (ARCH.SEQUENCE# - APPL.SEQUENCE#) "Difference"
FROM
(SELECT THREAD# ,SEQUENCE# FROM V$ARCHIVED_LOG WHERE (THREAD#,FIRST_TIME ) IN (SELECT THREAD#,MAX(FIRST_TIME) FROM V$ARCHIVED_LOG GROUP BY THREAD#)) ARCH,
(SELECT THREAD# ,SEQUENCE# FROM V$LOG_HISTORY WHERE (THREAD#,FIRST_TIME ) IN (SELECT THREAD#,MAX(FIRST_TIME) FROM V$LOG_HISTORY GROUP BY THREAD#)) APPL
WHERE
ARCH.THREAD# = APPL.THREAD#
;
OUTPUT ARCHIVE:-
Thread Last Sequence Received Last Sequence Applied Difference
---------- ---------------------- --------------------- ----------
2 31852 31852 50
1 49127 49127 50
prompt ++++++++++++++++++++CHECK FOR GAP AT STANDBY+++++++++++++++++++++++++
SELECT THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE# FROM V$ARCHIVE_GAP;
exit
Find the SCN on the PRIMARY STEP 2:SQL> select current_scn from v$database; CURRENT_SCN ———– 222271661Find the SCN on the STANDBY:SQL> select current_scn from v$database; CURRENT_SCN ———– 223762173Clearly you can see there is differenceIn Primary Server will take increment level backup with SCN STEP 3:-run {allocate channel c1 type disk format ‘/oradata/ora_backup/rman/QTSMMDB/%U.bkp’;backup AS COMPRESSED BACKUPSET incremental from scn 223762173 database;}run{allocate channel c1 type disk format‘/oradata/ora_backup/rman/QTSMMDB/%U.bkp’;backup current controlfile for standby;}Stop and shutdown the managed standby apply process STEP 4:SQL> alter database recover managed standby database cancel;Database altered.Shutdown the standby databaseSQL> shut immediateStep 5:-Copy the backup dump to standby instance.step 6:-Connect to RMAN on STANDBY, Catalog backup files to RMAN using below commands STEP 7:$ rman target /RMAN> startup nomount;RMAN> catalog start with ‘/oradata/ora_backup/Standby/c-3875280703-20150907-02’;RMAN> restore standby controlfile from'/oradata/ora_backup/Standby/c-3875280703-20150907-02';RMAN> sql 'alter database mount standby database';RMAN> catalog start with ‘/oradata/ora_backup/Standby/’;PERFORM RECOVER:RMAN> recover database;Start managed recovery process STEP 8:SQL> alter database recover managed standby database disconnect from session;Database altered.Check the SCN’s in primary and standby it should be close to each other.
super ji
ReplyDeleteHello,
ReplyDeleteCan you please help on below:
In our case, we are using ASM. and location of datafile is different on primary and standby. On primary we have +DATAC2 and on standby we have +DATAC1. So if we create a control file for standby from primary database, it has location as +DATAC2. Now we start the standby database with this control file, will it automatically change the location to +DATAC1? Do we need to manually update that. Is there any other way to work around this. Please help on the same. Thank You!
Hi,
DeleteIf you've mentioned db_file_name_convert and log_file_name_convert parameters.Locations will get updated automatically based on that...
I configure for RAC to 1 STANDBY DG NODE, I get the following error:
DeleteRMAN> recover database;
Starting recover at 23-AUG-19
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=11 device type=DISK
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 08/23/2019 11:05:12
RMAN-06094: datafile 1 must be restored
RMAN>
Hi Matrix,
DeleteYou got this error because a standby controlfile is recreated, by restoring it from the primary site, the datafile names as shown in v$datafile and RMAN's REPORT SCHEMA will actually reflect those of the primary database rather than the standby database.
You can check this by REPORT SCHEMA command in RMAN.
Please follow the doc id--RMAN-06094 or RMAN-06571 During Recovery or Switch to Copy at Standby Site (Doc ID 1339439.1)
Although you must have solved it. You've got this long back.
Thanks,
quick qustion please, with the primary and stby having the same scn, does it mean the lag caught up?
ReplyDelete