You Asked
I have done some searching on the web with documentation saying when running incremental level 1 for recover of copy backup may need to turn block change tracking on to avoid performance issue. Currently we are having the block change tracking as disabled. However, we did raise oracle SR and the support personnel telling me that the blocking change tracking only has 7 block and incremental level 1 for recover of copy will need unlimited blocks and thus the block change tracking should be disabled. So I am a little bit confused if we do need to enable the block change tracking or leave it disabled? Below is our backup script. Also, when they say it will have performance problem, does it just mean it will take more time to do the restore and recover? Or, is the performance problem means it will have issue restoring at all?
connect target /
set echo on;
configure backup optimization on;
configure retention policy to recovery window of 5 days;
configure controlfile autobackup on;
configure device type disk parallelism $PARALLELISM BACKUP TYPE TO COPY;
configure datafile backup copies for device type disk to 1;
configure archivelog backup copies for device type disk to 1;
configure channel device type disk format '${RMANBACKUP_MOUNTPOINT_FULL}/full/datafile_%U.bkp';
configure controlfile autobackup format for device type disk to '${RMANBACKUP_MOUNTPOINT_FULL}/full/full_controlfile_%d_%F.bkp';
run
{
sql 'alter system archive log current';
backup incremental level 1 for recover of copy with tag 'phoenix_oracle_backup' database;
recover copy of database with tag 'phoenix_oracle_backup';
sql 'alter system archive log current';
backup as backupset format '${RMANBACKUP_MOUNTPOINT_FULL}/archivelogs/%d_%h_%e_%s_%t.arc' archivelog all not backed up;
#Force is to ignore I/O errors
delete noprompt obsolete device type disk;
delete force NOPROMPT expired copy;
delete force NOPROMPT expired backup;
crosscheck backup;
crosscheck copy;
}
configure backup optimization clear;
configure controlfile autobackup clear;
exit
and Connor said...
Block change tracking is a performance feature, which I generally recommend for anyone on enterprise edition - its pretty much performance for free.
Here's how it will pertain to incremental backups. WHen backing up your database, RMAN will read blocks from the datafiles. For a level 0 backup, these blocks could be 2 states:
1- the block has been used at some stage
2- the block has never been used by the database
For example (keeping it simple assuming your database is a single datafile).
- you might have a 100G datafile, that currently has 60G of it used. Some of that 60G might be 'pseudo-empty', ie, a block used to contain rows from a table but those rows been deleted, but the 40G at the high end has never been touched.
Your level 0 backup will need to copy 60G to the backup destination, ie, (1) above. That in itself is a good optimization, because we didn't need to go near the 40G that has never been used. Thus the cost of our level 0 backup is:
a) read 60G from disk
b) wrote 60G to disk (assuming disk for our backup destination)
A day later, you do a level 1 backup. Now the blocks in your database could be in THREE states
1- a block that has never been used (eg, in the top 40G)
2- a block that has been used, and was changed today
3- a block that has been used, and was changed a few days ago.
An incremental backup only needs to backup blocks in (2) above. But that means we need to check the block to see if it was changed recently (since the last level 0). Let's assume there were 4G of changes. Thus the cost of the incremental backup is
a) read 60G from disk (we have to read all the used blocks to see if they were changed)
b) write 4G to disk (assuming disk for our backup destination)
In that scenario, it is quite possible that the 60G of reading is the most expensive part of the backup. Thats where block change tracking comes in. We store metadata about what blocks are changed - it doesn't really have to be down to the level of every blocks - it might just be keep an eye on "ranges" of blocks. Even in that case, an incremental backup then becomes
a) read the block change tracking file to get a list of "probably" changed blocks. That might yield (say) 5G of blocks to be read
b) read the 5G of blocks to find the 4G of blocks that were indeed changed
c) write 4G to disk (assuming disk for our backup destination)
You can see the obvious benefits here.
Just as an aside - I'm never a fan of "crosscheck" in a backup script.
Rating
(1 rating)