Welcome to Scribd, the world's digital library. Read, publish, and share books and documents. See more
Download
Standard view
Full view
of .
Save to My Library
Look up keyword
Like this
21Activity
0 of .
Results for:
No results containing your search query
P. 1
Merged Incremental Backup Strategy using Rman

Merged Incremental Backup Strategy using Rman

Ratings: (0)|Views: 1,923 |Likes:
Published by SHAHID FAROOQ

More info:

Published by: SHAHID FAROOQ on Aug 29, 2009
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as DOC, PDF, TXT or read online from Scribd
See more
See less

02/23/2013

pdf

text

original

 
Merged Incremental Backup Strategy using Rman
There are several ways to use a Merged Incremental Backup Strategy. However, before implementing thestrategy, there are several things to consider when not using the basic Oracle Suggested Strategy as given in EM.This note will cover the different ways to implement your strategy tailored to fit your business needs.
Applies to:
Oracle Server - Enterprise Edition - Version: 10.1.0.2 to 11.1.0.6Information in this document applies to any platform.What is a Merged Incremental Backup?Merged Incremental creates a level 0 image copy backup of all of your database's datafiles in a disk location.All datafiles are backed up using the same tag name. The Oracle Database 10g feature
 Block Change Tracking 
can beused for the incremental level 1 backups for 
 Fast Incremental Backups
.Once a level 0 backup copy is created on disk there is no need for future level 0 backups to be taken. Thisreduces the load and backup window for VLDB systems. All future backups will be level 1 backupsets and areused to recover the image copies on disk thus making the current level 0 image backup copies more current eachtime the level 1 incremental is applied. Having the level 0 image copy newer with each level 1 incremental backupsets means there is no need to make another level 0 backup/image copy of your database.
Solution
First let look at the Enterprise Manager Merged Incremental "Oracle-Suggested Strategy".
Daily Script:run {allocate channel oem_disk_backup device type disk;recover copy of database with tag 'ORA$OEM_LEVEL_0';backup incremental level 1 cumulative copies=1for recover of copy with tag 'ORA$OEM_LEVEL_0' database;}
 By default the Merged Incremental Strategy creates cumulative incremental backups. If there are no level 0 copiesthen the first execution will make level 0 datafile copy backups to the specified location or to the Flash RecoveryArea if one is defined in the parameter file of the database.With the default EM script the image copies will always be 24 hours behind the current incremental backup taken. If the business requires that you keep the image backup more current you can change the
recover 
command to beexecuted after the
backup
command so the most current changes are applied to the image copies.
Default behavior for Merged Incremental Backups
 
First Execution, Day 1: The 'recover copy' command will show ' no copy of datafile 1 found to recover' as this is thefirst execution and no level 0 backup existing. The 'backup incremental....' command will make a new level 0 copyas there is no existing level 0.Second Execution, Day 2: The 'recover copy' command will show 'no copy of datafile 1 found to recover' as there isstill no previous level 1 backup. The 'backup incremental...' command will create a level 1 datafile backupset.Third Execution, Day 3: The 'recover copy' command will recover the level 0 image copy and displays 'recoveringdatafile copy fno=....'. The 'backup incremental....' command will create a new level 1 datafile backupset.Future Executions: Each backup taken after the 3rd should show the same behavior as in backup on Day 3.The following is an example of making the Merged Incremental Backups so the image copies remain 24 hours behindthe incremental backups taken. This is the same as one described above through EM.
run {recover copy of database with tag 'MIB_LEVEL_0';backup incremental level 1 cumulative copies=1for recover of copy with tag 'MIB_LEVEL_0' database;}
In this example, the backup and recover commands are flipped. The backup is taken before the recover statement.The recover command will apply the most recent level 1 backup. Thus the image copy backups have the incremental backup applied to them directly after they're taken. This keeps the image copies most current and can beexecuted several times a day according to your business requirements.
run {backup incremental level 1 cumulative copies=1for recover of copy with tag 'MIB_LEVEL_0' database;recover copy of database with tag 'MIB_LEVEL_0';}
If there is not enough space in the Flash Recovery Area or on a single mount to make image copies of the entiredatabase, they can be spread across multiple disk mounts. To do this, the initial level 0 image copy must be executedmanually. For example, the following performs a backup by tablespace written to different mount points. The key isis using the same tag for backup then again for subsequent recovery commands.
run {backup as copy incremental level 0 format '/path/mount1/%U' tag 'MIB_LEVEL_0'tablespace SYSTEM, UNDOTBS1;backup as copy incremental level 0 format '/path/mount2/%U' tag 'MIB_LEVEL_0'tablespace SYSAUX, USERS;backup as copy incremental level 0 format '/path/mount3/%U' tag 'MIB_LEVEL_0'tablespace TEST1, TEST2;}
After the level 0 image copy backup is created to the respective mount points, the daily script to create incremental backupsets to recover the image copies can be executed. Although the image copies are on different mount points,their use of the same tag will cause RMAN to find the most recent copy with the respective tag to apply the recovery.It should be noted, that in this case, it is the DBA's responsibility to maintain/take Incremental Level 0 Backups if for example NEW TABLESPACES or DATAFILES are added to the Database. Of course the RMAN Incremental Level1 Backups will do automatically a Incremental LEvel 0 Backup if there is none available, but then this automatically
 
created Incr LEvel 0 Backup does not go to one of the Destination Mount Points, but to a DEFAULT Location i.e.FRA or $ORACLE_HOME/dbs is FRA is not specified.
run {backup incremental level 1 for recover of copy with tag 'MIB_LEVEL_0' database;recover copy of database with tag 'MIB_LEVEL_0';}
 When using the Oracle-Suggested Strategy or daily Merged Incremental Backup and using a Flash Recovery Areathen keep the RMAN Retention Policy set for Redundancy 1. This will ensure that Oracle space management willautomatically remove the level 1 incremental backups from the FRA after they have been applied to the image copy based on space pressure in the FRA. If you increase the redundancy or set a Recovery Window the space will nolonger be automatically reclaimed by Oracle. This works only when retention policy is set to the default of redundancy=1. If the configured retention policy is set to recovery window or to a redundancy > 1, then RMANcannot satisfy the retention policy if there is only one copy of database and it is at a later point in time. So, in order tosatisfy the retention policy Oracle keeps all the incrementals and archivelogs since database creation because ideallya datafile can be re-created and archivelogs can be applied to satisfy the retention policy (though not followed in practical case).When the business requires a retention policy to recovery window of 7 days. The retention policy can be configuredas such by the user. In addition, a customized script using a UNTIL CLAUSE of 8 days must be created. This willkeep the copy of the database to at least 8 days older. This will satisfy the retention policy and make the archivelogsand incremental deletable from FRA.Another image copy can be made back to lag the recover using 'SYSDATE-x' for the 'recover the copy' command.The only caveat is the tag being used and another incremental backup is required using the tag for the copy you wishto recover.
RECOVER COPY OF DATABASE WITH TAG 'MIB_LEVEL_0' UNTIL TIME "SYSDATE-8";
This would keep the copy of database to satisfy the retention policy of 7 days.
Block Change Tracking and Merged Incrementals
If using BCT Block Change Tracking for the level 1 incremental backups you must note the BCT file will only allowup to 8 bitmaps by default. So it can only trace 8 days or 8 incremental backups between each recover command.The limit can be increased using the underscore parameter listed in Note 452455.1A database with Block Change Tracking enabled and if more than 8 RMAN incremental backups are executedwithout consolidating them into image copies, then the backup process will be very slow since the Block ChangeTracking won't be used in subsequent backups.The limit is set by the "_bct_bitmaps_per_file" parameter. This parameter sets the number of bitmaps to be stored for each datafile, and its default value is 8. In order to avoid this limit one can either run less than 8 incremental backupsor can increase the "_bct_bitmaps_per_file" parameter.
Cumulative vs. Differential Incremental Backups

Activity (21)

You've already reviewed this. Edit your review.
1 hundred reads
1 thousand reads
Mike Killough liked this
Mike Killough liked this
Mike Killough liked this
Mike Killough liked this
Mike Killough liked this
sj_savio liked this
Prachi Pahtare liked this
sproxor liked this

You're Reading a Free Preview

Download
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->