Incremental Backup Synchronization (SYNC)
- Jan Klinke
Incremental backup synchronization is a special one-time action which can be used in specific cases to synchronize your standby database without any archivelogs. The backup and synchronization is done based on SCN difference between primary and standby datafiles. This method is much faster than having to recreate standby database from the scratch.
Do not use this method for daily or automatic sychronization. After The SYNC process, you will be able to resume the synchronization using Automated standby update (ASU).
This type of synchronizatin is relevant in following cases:
Resolving unrecoverable archive log gap, when archive logs were lost or deleted by accident before they were transferred and applied to the standby database.
Fixing logical corruption on the standby database due to nologging operations that were performed on the primary
There is extreme log gap between primary and standby database (for example 1000+ archivelogs)
SYNC process will have to fully scan your primary database and compare it to standby database to detect which blocks will be part of the incremental backup. The whole SYNC process may take long time.
1. Prerequisites
Before running SYNC process, you must ensure following:
A. Standby database must be mounted. Verify this by running on standby:
[oracle@czlin0212 oracle]$ sqlplus / as sysdba
select open_mode,database_role from v$database;
OPEN_MODE DATABASE_ROLE
-------------------- ----------------
MOUNTED PHYSICAL STANDBYIf your standby database is not MOUNTED or can't be MOUNTED, it's very likely in no shape for Incremental backup sync and you should recreate it from the scratch: Creating Basic Synchronization
B. Standby database has no datafile errors. On standby run:
[oracle@czlin0212 oracle]$ sqlplus / as sysdba
select file#, name, status from v$datafile
where status = 'RECOVER' or status = 'OFFLINE' or status = 'SYSOFF' or ERROR = 'FILE NOT FOUND';The result must return no rows, otherwise your standby database is likely in no condition for Incremental backup sync (recreate from the scratch).
C. Standby database has all datafiles which primary database has and is on the same incarnation. On primary and standby run:
[oracle@czlin0211 oracle]$ sqlplus / as sysdba
select file#,name from v$datafile;
select * from v$database_incarnation;The results must match. It's possible to have different paths and names on primary and standby (for example when using OMF and ASM to filesystem conversion), but otherwise the datafiles need to be equal.
D. You need to ensure no archivelog will be deleted on primary from the point in time you start with the process, until the point in time when apply of the incremental backup is finished.
This condition is very important, beacuse if any archivelog is deleted from primary util this process is finished you will be unable to synchronize your standby database and you will have to rerun this process again (after you disable the backup jobs on primary)
E. Prepare backup directory with sufficient space on primary and standby server. The incremental backup shouldn’t take usually more than 1/3 of total primary database size, unless the standby is lagging very far behind or there were excessive changes done on primary.
2. Runinng SYNC process from GUI
From the ACTIONS right pane, choose Synchronize:
On the next page, you will be able to view how much the standby database is currently lagging behind:
You have the option to use transportable media option, which works similar to transportable media option during CSD:
Create Standby Database (CSD) | 6. CSD With Transportable Media option
Modify Source and Target temp folder locations (1&2) with backup folder path you have prepared earlier and start the SYNC process (3).
There will a new SYNC job visible in the dashboard:
And you can view the progress by clicking on the job:
It is expected in some cases that steps “3” and “7” take long time (could be even several hours depeding on the situation). The only possibility to monitor progress is to query v$session_longops on primary and standby server.
Once the SYNC process is completed, the automatic standby update can be enabled and the archivelogs would automatically be shipped from primary and applied on standby.
3. Runinng SYNC process manually
In some cases, where it’s impossible to use the guided GUI process, you can run directly RMAN commands to roll forward your standby database using incremental backups. Note that this is addvanced process which requires above-beginner DBA skills and knowledge. If in doubt, you can always recreate standby database from scratch by runing CSD process.
3.1 Prepare Incremental Backup
A. Find out the lowest needed recovery SCN on standby database
The con_id <> 2 condition is to skip PDB$SEED datafiles.
B. Run incremental backup on your primary database
Be sure to have backup directory ready (in this case /u02/app/oracle/dbvisit_backup). There's unfortunately no way how to predict the size of the incremental backup - all depends on number of changes done to your primary database since last synchronization with standby database.
C. Copy all backup files to standby server
Copy all files located in /u02/app/oracle/dbvisit_backup to same location on standby server via scp
3.2 Restore Incremental Backup on Standby Server
A. Restore controlfile on your standby server
B. Catalog standby database datafiles on standby
This step is necessary to perform if using OMF and/or different datafile locations on primary and standby
You will need to catalog datafiles for each separate location, for example if you would have datafiles in /u02/app/oracle/oradata/MEGA you would need to catalog datafiles in that location as well.
C. Switch database to copy on standb
ALL datafiles need to be switched successfully.
before running next step, following SQL on standby must have ERROR column empty:
D. Apply incremental backup on standby
3.2 Post Steps
A. Synchronize archivelogs which were created in the meantime from your primary server by running following command
B. Apply archivelogs on standby by running on standb
If this step finishes successfullt, you will be able to again enable ASU and continue synchronization with help of archivedlogs.