In my backup strategy I used to consider an RMAN image backup for my production databases that have sufficient free disk space on the backup location.
But first what is RMAN Image/Copy Backup:
Starting with Oracle 10g, RMAN can backup datafiles as an image copy, the image copy will be a duplicate copy of the datafile contains all allocated+free blocks, it's much similar to the hot backup method where you put the tablespace in begin backup mode then from OS side copy the datafiles to the backup location then put the tablespace in end backup mode, but RMAN takes care of such mechanism automatically.
Why you should consider RMAN Image/Copy Backup in your backup strategy:
The biggest advantage is that you can switch a physically corrupted/lost/damaged datafiles to refer to it's image copy backup then recover the datafile and it will be ready for use without the need to restore the lost datafile back, the thing safe a huge time by skipping the restoration process.
How to perform an RMAN Image/Copy Backup for your database:
Just connect to the RMAN and execute this simple command:
RMAN> backup as copy database format '/backupdisk/rmanbkps/copy/%U' tag='DB_COPY' plus archivelog;
Note: The free space of backup location should be same or greater than the size of the database.
Note: "plus archivelog" , will backup archivelogs before and after the backup to guarantee a consistent restoration of the backup.How to Recover an RMAN Image/Copy Backup:
If you will consider RMAN image/copy backups in your backup strategy you should consider recovering the image copy instead of creating a new image copy every time you perform a backup.
By recovering the image copy you will need only to recover the already exist image backup with the transactions committed on the database since the last backup, the thing leads to cuts down the backup time and CPU overhead during the backup window.
Advantages of recovering an Image backup:
> Reduce the impact caused by a complete backup.
> Reduce the time of backup window.
> Reduce network bandwidth in case of backing up over the network.
> Can be used on a NOARCHIVELOG DB (mount mode).
How to perform recovery of RMAN Image backup:
You will consider using the following script for the whole operation:
# rman target /
RMAN> run{
ALLOCATE CHANNEL C1 DEVICE TYPE DISK FORMAT '/FRA/RMANBKP/%U';
BACKUP AS COMPRESSED BACKUPSET INCREMENTAL LEVEL 1 FOR RECOVER
OF COPY WITH TAG 'FULL_IMAGE_UPDTD_BKP' DATABASE FORMAT
'/FRA/RMANBKP/%d_%t_%s_%p';
RECOVER COPY OF DATABASE WITH TAG ='FULL_IMAGE_UPDTD_BKP';
DELETE NOPROMPT BACKUP TAG ='FULL_IMAGE_UPDTD_BKP';
}
How it works:
> The FIRST run of that script, it will try to create a compressed incremental level 1 backup but will fail due to no base parent incremental level 0 available and will throw this message:
"no parent backup or copy of datafile xx found"
Then it will create the first image Copy backup with tag FULL_IMAGE_UPDTD_BKP and will fail to recover it from incr level 1 as there is no incr level 1 available at that time and will throw this messages:
"no copy of datafile xx found to recover"
> The SECOND run, it will create the first compressed incremental level 1 backup then will use it to recover the already exist image copy from the first run.
At the end, the last command will delete the incremental level 1 backup been used for the recovery of the image backup. In case you don't have a block change tracking file for the database, it's recommended to not delete the last created incremental level 1 backup.
And so on for the next runs ...
Facts:
> Each time a datafile added to the database a new image copy will be created when running above script.
> Tag must be used to identify the image backup.
> Archivelogs are not get involved, so nologging operations will be included in this operation.
To speed up the recovery of Image backup, consider to create a Block Change Tracking file:
SQL> Alter database enable block change tracking using file '/backupdisk/BCT.log' reuse;
> Block Change Tracking help in speeding up the process of creating an incremental backup.
> In RAC environment block change tracking file should be located on shared location between RAC nodes.
> Block Change Tracking realted info can be found in V$BLOCK_CHANGE_TRACKING view.
> Block Change Tracking file size is approximately=1/30000 of data blocks size to be tracked.
> Once you enable block change tracking there is a new process called [CTWR] will handle the read/write to the BCT file.
Note: The disadvantage of creating a block change tracking file is that it will introduce a small performance overhead during the database normal activities.
For more information in how to use the image copy backup in the disaster scenarios please check this line:
http://dba-tips.blogspot.ae/2011/11/switch-database-to-rman-copy-backup-and.html
Reference:
http://docs.oracle.com/cd/E11882_01/backup.112/e10642/rcmbckba.htm#BRADV239
http://www.oracle-base.com/articles/10g/rman-enhancements-10g.php
http://www.pythian.com/documents/Pythian-oracle-block-change.pdf
But first what is RMAN Image/Copy Backup:
Starting with Oracle 10g, RMAN can backup datafiles as an image copy, the image copy will be a duplicate copy of the datafile contains all allocated+free blocks, it's much similar to the hot backup method where you put the tablespace in begin backup mode then from OS side copy the datafiles to the backup location then put the tablespace in end backup mode, but RMAN takes care of such mechanism automatically.
Why you should consider RMAN Image/Copy Backup in your backup strategy:
The biggest advantage is that you can switch a physically corrupted/lost/damaged datafiles to refer to it's image copy backup then recover the datafile and it will be ready for use without the need to restore the lost datafile back, the thing safe a huge time by skipping the restoration process.
How to perform an RMAN Image/Copy Backup for your database:
Just connect to the RMAN and execute this simple command:
RMAN> backup as copy database format '/backupdisk/rmanbkps/copy/%U' tag='DB_COPY' plus archivelog;
Note: The free space of backup location should be same or greater than the size of the database.
Note: "plus archivelog" , will backup archivelogs before and after the backup to guarantee a consistent restoration of the backup.How to Recover an RMAN Image/Copy Backup:
If you will consider RMAN image/copy backups in your backup strategy you should consider recovering the image copy instead of creating a new image copy every time you perform a backup.
By recovering the image copy you will need only to recover the already exist image backup with the transactions committed on the database since the last backup, the thing leads to cuts down the backup time and CPU overhead during the backup window.
Advantages of recovering an Image backup:
> Reduce the impact caused by a complete backup.
> Reduce the time of backup window.
> Reduce network bandwidth in case of backing up over the network.
> Can be used on a NOARCHIVELOG DB (mount mode).
How to perform recovery of RMAN Image backup:
You will consider using the following script for the whole operation:
# rman target /
RMAN> run{
ALLOCATE CHANNEL C1 DEVICE TYPE DISK FORMAT '/FRA/RMANBKP/%U';
BACKUP AS COMPRESSED BACKUPSET INCREMENTAL LEVEL 1 FOR RECOVER
OF COPY WITH TAG 'FULL_IMAGE_UPDTD_BKP' DATABASE FORMAT
'/FRA/RMANBKP/%d_%t_%s_%p';
RECOVER COPY OF DATABASE WITH TAG ='FULL_IMAGE_UPDTD_BKP';
DELETE NOPROMPT BACKUP TAG ='FULL_IMAGE_UPDTD_BKP';
}
How it works:
> The FIRST run of that script, it will try to create a compressed incremental level 1 backup but will fail due to no base parent incremental level 0 available and will throw this message:
"no parent backup or copy of datafile xx found"
Then it will create the first image Copy backup with tag FULL_IMAGE_UPDTD_BKP and will fail to recover it from incr level 1 as there is no incr level 1 available at that time and will throw this messages:
"no copy of datafile xx found to recover"
> The SECOND run, it will create the first compressed incremental level 1 backup then will use it to recover the already exist image copy from the first run.
At the end, the last command will delete the incremental level 1 backup been used for the recovery of the image backup. In case you don't have a block change tracking file for the database, it's recommended to not delete the last created incremental level 1 backup.
And so on for the next runs ...
Facts:
> Each time a datafile added to the database a new image copy will be created when running above script.
> Tag must be used to identify the image backup.
> Archivelogs are not get involved, so nologging operations will be included in this operation.
To speed up the recovery of Image backup, consider to create a Block Change Tracking file:
SQL> Alter database enable block change tracking using file '/backupdisk/BCT.log' reuse;
> Block Change Tracking help in speeding up the process of creating an incremental backup.
> In RAC environment block change tracking file should be located on shared location between RAC nodes.
> Block Change Tracking realted info can be found in V$BLOCK_CHANGE_TRACKING view.
> Block Change Tracking file size is approximately=1/30000 of data blocks size to be tracked.
> Once you enable block change tracking there is a new process called [CTWR] will handle the read/write to the BCT file.
Note: The disadvantage of creating a block change tracking file is that it will introduce a small performance overhead during the database normal activities.
For more information in how to use the image copy backup in the disaster scenarios please check this line:
http://dba-tips.blogspot.ae/2011/11/switch-database-to-rman-copy-backup-and.html
Reference:
http://docs.oracle.com/cd/E11882_01/backup.112/e10642/rcmbckba.htm#BRADV239
http://www.oracle-base.com/articles/10g/rman-enhancements-10g.php
http://www.pythian.com/documents/Pythian-oracle-block-change.pdf
No comments:
Post a Comment