Say that your Standby database is lagging behind the Primary database.
You could
a. Fetch and apply all the ArchiveLogs required to cover the lag
b. Take an Incremental Backup from the Primary and apply it to the Standby (the syntax being "backup as compressed backupset incremental from SCN=xxxx format '......' ) and then restore it on the Standby
c. Since 12c, do a complete Refresh of the Standby over the network
(at the end of this post, I have added a link to a 19c demo of Restore+Recovery of a single datafile from the Primary to the Standby)
My Primary reports :
While my Standby reports :
So, I attempt to refresh the Standby with :
The alert log on the Standby even shows the new PDB that I had created on the Primary while the Standby was down. (See my previous BlogPost where I had created NEWPDB)
And I can check whether the datafiles are being updated at the Standby
What are datafiles 5, 6 and 8 ? Even the RMAN RESTORE command had shown them to "already restored to SCN 1443131" -- which is a much lower SCN ?
Those 3 datafiles are of the SEED PDB which does not get updated as it is not opened READ-WRITE.
Note : Here is a 19c demo of Restore+Recovery of a single datafile from Primary to the Standby
You could
a. Fetch and apply all the ArchiveLogs required to cover the lag
b. Take an Incremental Backup from the Primary and apply it to the Standby (the syntax being "backup as compressed backupset incremental from SCN=xxxx format '......' ) and then restore it on the Standby
c. Since 12c, do a complete Refresh of the Standby over the network
(at the end of this post, I have added a link to a 19c demo of Restore+Recovery of a single datafile from the Primary to the Standby)
My Primary reports :
SQL> select max(sequence#) from v$archived_log; MAX(SEQUENCE#) -------------- 79 SQL>
While my Standby reports :
SQL> select high_Sequence# from v$archive_gap; HIGH_SEQUENCE# -------------- 67 SQL>
So, I attempt to refresh the Standby with :
$rman target / Recovery Manager: Release 12.2.0.1.0 - Production on Wed Jun 17 22:55:22 2020 Copyright (c) 1982, 2017, Oracle and/or its affiliates. All rights reserved. connected to target database (not started) RMAN> startup mount; Oracle instance started database mounted Total System Global Area 419430400 bytes Fixed Size 8793496 bytes Variable Size 167772776 bytes Database Buffers 234881024 bytes Redo Buffers 7983104 bytes RMAN> restore database from service ORCL12C; Starting restore at 17-JUN-20 using target database control file instead of recovery catalog allocated channel: ORA_DISK_1 channel ORA_DISK_1: SID=66 device type=DISK skipping datafile 5; already restored to SCN 1443131 skipping datafile 6; already restored to SCN 1443131 skipping datafile 8; already restored to SCN 1443131 channel ORA_DISK_1: starting datafile backup set restore channel ORA_DISK_1: using network backup set from service ORCL12C channel ORA_DISK_1: specifying datafile(s) to restore from backup set channel ORA_DISK_1: restoring datafile 00001 to /STANDBY/database/STDB/datafile/o1_mf_system_2gude3k1_.dbf channel ORA_DISK_1: restore complete, elapsed time: 00:00:36 channel ORA_DISK_1: starting datafile backup set restore channel ORA_DISK_1: using network backup set from service ORCL12C channel ORA_DISK_1: specifying datafile(s) to restore from backup set channel ORA_DISK_1: restoring datafile 00003 to /STANDBY/database/STDB/datafile/o1_mf_sysaux_2hude3l5_.dbf channel ORA_DISK_1: restore complete, elapsed time: 00:00:25 channel ORA_DISK_1: starting datafile backup set restore channel ORA_DISK_1: using network backup set from service ORCL12C channel ORA_DISK_1: specifying datafile(s) to restore from backup set channel ORA_DISK_1: restoring datafile 00007 to /STANDBY/database/STDB/datafile/o1_mf_users_2qude3pc_.dbf channel ORA_DISK_1: restore complete, elapsed time: 00:00:02 channel ORA_DISK_1: starting datafile backup set restore channel ORA_DISK_1: using network backup set from service ORCL12C channel ORA_DISK_1: specifying datafile(s) to restore from backup set channel ORA_DISK_1: restoring datafile 00009 to /STANDBY/database/STDB/49BFF8A6BB912582E0530100007F8BE4/datafile/o1_mf_system_2jude3nb_.dbf channel ORA_DISK_1: restore complete, elapsed time: 00:00:15 channel ORA_DISK_1: starting datafile backup set restore channel ORA_DISK_1: using network backup set from service ORCL12C channel ORA_DISK_1: specifying datafile(s) to restore from backup set channel ORA_DISK_1: restoring datafile 00010 to /STANDBY/database/STDB/49BFF8A6BB912582E0530100007F8BE4/datafile/o1_mf_sysaux_2fude3iu_.dbf channel ORA_DISK_1: restore complete, elapsed time: 00:00:36 channel ORA_DISK_1: starting datafile backup set restore channel ORA_DISK_1: using network backup set from service ORCL12C channel ORA_DISK_1: specifying datafile(s) to restore from backup set channel ORA_DISK_1: restoring datafile 00011 to /STANDBY/database/STDB/49BFF8A6BB912582E0530100007F8BE4/datafile/o1_mf_undotbs1_2iude3mi_.dbf channel ORA_DISK_1: restore complete, elapsed time: 00:00:16 channel ORA_DISK_1: starting datafile backup set restore channel ORA_DISK_1: using network backup set from service ORCL12C channel ORA_DISK_1: specifying datafile(s) to restore from backup set channel ORA_DISK_1: restoring datafile 00012 to /STANDBY/database/STDB/49BFF8A6BB912582E0530100007F8BE4/datafile/o1_mf_users_2mude3op_.dbf channel ORA_DISK_1: restore complete, elapsed time: 00:00:03 channel ORA_DISK_1: starting datafile backup set restore channel ORA_DISK_1: using network backup set from service ORCL12C channel ORA_DISK_1: specifying datafile(s) to restore from backup set channel ORA_DISK_1: restoring datafile 00013 to /STANDBY/database/STDB/49BFF8A6BB912582E0530100007F8BE4/datafile/o1_mf_apex_199_2pude3pb_.dbf channel ORA_DISK_1: restore complete, elapsed time: 00:00:01 channel ORA_DISK_1: starting datafile backup set restore channel ORA_DISK_1: using network backup set from service ORCL12C channel ORA_DISK_1: specifying datafile(s) to restore from backup set channel ORA_DISK_1: restoring datafile 00014 to /STANDBY/database/STDB/49BFF8A6BB912582E0530100007F8BE4/datafile/o1_mf_apex_199_2rude3pe_.dbf channel ORA_DISK_1: restore complete, elapsed time: 00:00:02 channel ORA_DISK_1: starting datafile backup set restore channel ORA_DISK_1: using network backup set from service ORCL12C channel ORA_DISK_1: specifying datafile(s) to restore from backup set channel ORA_DISK_1: restoring datafile 00015 to /STANDBY/database/STDB/datafile/o1_mf_undotbs2_2oude3p4_.dbf channel ORA_DISK_1: restore complete, elapsed time: 00:00:03 Finished restore at 17-JUN-20 RMAN> RMAN> exit Recovery Manager complete. $sqlplus '/ as sysdba' SQL*Plus: Release 12.2.0.1.0 Production on Wed Jun 17 22:58:55 2020 Copyright (c) 1982, 2016, Oracle. All rights reserved. Connected to: Oracle Database 12c Enterprise Edition Release 12.2.0.1.0 - 64bit Production SQL> alter database recover managed standby database disconnect from session; Database altered. SQL>
The alert log on the Standby even shows the new PDB that I had created on the Primary while the Standby was down. (See my previous BlogPost where I had created NEWPDB)
2020-06-17T22:59:13.347236+08:00 Media Recovery Log /STANDBY/fast_recovery_area/stdb/STDB/archivelog/2020_06_17/o1_mf_1_67_hgncbh2m_.arc 2020-06-17T22:59:13.497650+08:00 Media Recovery Log /STANDBY/fast_recovery_area/stdb/STDB/archivelog/2020_06_17/o1_mf_1_68_hgnbvsy2_.arc 2020-06-17T22:59:13.566410+08:00 Completed: alter database recover managed standby database disconnect from session 2020-06-17T22:59:13.659512+08:00 Media Recovery Log /STANDBY/fast_recovery_area/stdb/STDB/archivelog/2020_06_17/o1_mf_1_69_hgncbj0v_.arc 2020-06-17T22:59:13.759502+08:00 Media Recovery Log /STANDBY/fast_recovery_area/stdb/STDB/archivelog/2020_06_17/o1_mf_1_70_hgncbj5z_.arc 2020-06-17T22:59:13.981225+08:00 Media Recovery Log /STANDBY/fast_recovery_area/stdb/STDB/archivelog/2020_06_17/o1_mf_1_71_hgncbjf6_.arc Recovery created pluggable database NEWPDB 2020-06-17T22:59:21.246470+08:00 Recovery copied files for tablespace SYSTEM Recovery successfully copied file /STANDBY/database/STDB/A84987FDF4C51164E0530100007FEB9C/datafile/o1_mf_system_hgnbd696_.dbf from /STANDBY/database/STDB/49BFE9E2D73E2038E0530100007F846C/datafile/o1_mf_system_2lude3oa_.dbf NEWPDB(4):Successfully added datafile 41 to media recovery NEWPDB(4):Datafile #41: '/STANDBY/database/STDB/A84987FDF4C51164E0530100007FEB9C/datafile/o1_mf_system_hgnbd696_.dbf' 2020-06-17T22:59:30.184914+08:00 Recovery copied files for tablespace SYSAUX Recovery successfully copied file /STANDBY/database/STDB/A84987FDF4C51164E0530100007FEB9C/datafile/o1_mf_sysaux_hgnbd6c1_.dbf from /STANDBY/database/STDB/49BFE9E2D73E2038E0530100007F846C/datafile/o1_mf_sysaux_2kude3nr_.dbf NEWPDB(4):Successfully added datafile 42 to media recovery NEWPDB(4):Datafile #42: '/STANDBY/database/STDB/A84987FDF4C51164E0530100007FEB9C/datafile/o1_mf_sysaux_hgnbd6c1_.dbf' 2020-06-17T22:59:32.983486+08:00 Recovery copied files for tablespace UNDOTBS1 Recovery successfully copied file /STANDBY/database/STDB/A84987FDF4C51164E0530100007FEB9C/datafile/o1_mf_undotbs1_hgnbd6c2_.dbf from /STANDBY/database/STDB/49BFE9E2D73E2038E0530100007F846C/datafile/o1_mf_undotbs1_2nude3p1_.dbf NEWPDB(4):Successfully added datafile 43 to media recovery NEWPDB(4):Datafile #43: '/STANDBY/database/STDB/A84987FDF4C51164E0530100007FEB9C/datafile/o1_mf_undotbs1_hgnbd6c2_.dbf' 2020-06-17T22:59:36.310405+08:00 (4):Successfully added datafile 44 to media recovery (4):Datafile #44: '/STANDBY/database/STDB/A84987FDF4C51164E0530100007FEB9C/datafile/o1_mf_my_user__hgncypmz_.dbf' (4):Resize operation completed for file# 42, old size 337920K, new size 348160K (4):Resize operation completed for file# 42, old size 348160K, new size 368640K 2020-06-17T22:59:39.083144+08:00 Media Recovery Log /STANDBY/fast_recovery_area/stdb/STDB/archivelog/2020_06_17/o1_mf_1_72_hgncbjf0_.arc 2020-06-17T22:59:39.235507+08:00 Media Recovery Log /STANDBY/fast_recovery_area/stdb/STDB/archivelog/2020_06_17/o1_mf_1_73_hgnc90l0_.arc 2020-06-17T22:59:39.547295+08:00 Media Recovery Log /STANDBY/fast_recovery_area/stdb/STDB/archivelog/2020_06_17/o1_mf_1_74_hgncbdhw_.arc 2020-06-17T22:59:39.734181+08:00 Media Recovery Log /STANDBY/fast_recovery_area/stdb/STDB/archivelog/2020_06_17/o1_mf_1_75_hgncbdn2_.arc 2020-06-17T22:59:39.856485+08:00 Media Recovery Log /STANDBY/fast_recovery_area/stdb/STDB/archivelog/2020_06_17/o1_mf_1_76_hgncbgvb_.arc 2020-06-17T22:59:40.007157+08:00 Media Recovery Log /STANDBY/fast_recovery_area/stdb/STDB/archivelog/2020_06_17/o1_mf_1_77_hgncbgr5_.arc 2020-06-17T22:59:40.129214+08:00 Media Recovery Log /STANDBY/fast_recovery_area/stdb/STDB/archivelog/2020_06_17/o1_mf_1_78_hgncbmo4_.arc 2020-06-17T22:59:40.266298+08:00 Media Recovery Log /STANDBY/fast_recovery_area/stdb/STDB/archivelog/2020_06_17/o1_mf_1_79_hgncbmmz_.arc Media Recovery Waiting for thread 1 sequence 80 (in transit) 2020-06-17T23:02:19.174414+08:00 Archived Log entry 18 added for thread 1 sequence 80 rlc 937554761 ID 0x2dc76487 LAD2 : 2020-06-17T23:02:19.575536+08:00 Primary database is in MAXIMUM PERFORMANCE mode RFS[2]: Assigned to RFS process (PID:6137) RFS[2]: No standby redo logfiles created 2020-06-17T23:02:19.597702+08:00 Media Recovery Log /STANDBY/fast_recovery_area/stdb/STDB/archivelog/2020_06_17/o1_mf_1_80_hgncrmr3_.arc RFS[2]: Opened log for T-1.S-81 dbid 768045447 branch 937554761 2020-06-17T23:02:20.948511+08:00 Media Recovery Waiting for thread 1 sequence 81 (in transit) 2020-06-17T23:02:31.317814+08:00 Archived Log entry 19 added for thread 1 sequence 81 rlc 937554761 ID 0x2dc76487 LAD2 : RFS[2]: No standby redo logfiles created RFS[2]: Opened log for T-1.S-82 dbid 768045447 branch 937554761 2020-06-17T23:02:31.710951+08:00 Media Recovery Log /STANDBY/fast_recovery_area/stdb/STDB/archivelog/2020_06_17/o1_mf_1_81_hgnd3vlo_.arc Media Recovery Waiting for thread 1 sequence 82 (in transit)
And I can check whether the datafiles are being updated at the Standby
SQL> select current_scn, database_role from v$database; CURRENT_SCN DATABASE_ROLE ----------- ---------------- 3035674 PHYSICAL STANDBY SQL> select file#, checkpoint_change# from v$datafile order by 1; FILE# CHECKPOINT_CHANGE# ---------- ------------------ 1 3035675 3 3035675 5 1443131 6 1443131 7 3035675 8 1443131 9 3035675 10 3035675 11 3035675 12 3035675 13 3035675 14 3035675 15 3035675 41 3035675 42 3035675 43 3035675 44 3035675 17 rows selected. SQL>
What are datafiles 5, 6 and 8 ? Even the RMAN RESTORE command had shown them to "already restored to SCN 1443131" -- which is a much lower SCN ?
SQL> select p.con_id, p.name, p.open_mode, d.file#, d.checkpoint_change# 2 from v$pdbs p, v$datafile d 3 where p.con_id=d.con_id 4 order by d.file# 5 / CON_ID NAME OPEN_MODE FILE# CHECKPOINT_CHANGE# ---------- ------------ ---------- ---------- ------------------ 2 PDB$SEED MOUNTED 5 1443131 2 PDB$SEED MOUNTED 6 1443131 2 PDB$SEED MOUNTED 8 1443131 3 ORCL MOUNTED 9 3035675 3 ORCL MOUNTED 10 3035675 3 ORCL MOUNTED 11 3035675 3 ORCL MOUNTED 12 3035675 3 ORCL MOUNTED 13 3035675 3 ORCL MOUNTED 14 3035675 4 NEWPDB MOUNTED 41 3035675 4 NEWPDB MOUNTED 42 3035675 4 NEWPDB MOUNTED 43 3035675 4 NEWPDB MOUNTED 44 3035675 13 rows selected. SQL>
Those 3 datafiles are of the SEED PDB which does not get updated as it is not opened READ-WRITE.
Note : Here is a 19c demo of Restore+Recovery of a single datafile from Primary to the Standby
No comments:
Post a Comment