10G RMAN Testing Part 2 - Just call me "The Recovery Kid"

Change Tracking for Incremental Backups
10G's Change Tracking feature improves the performance of incremental backups by recording datafile block changes in a change tracking file.  Without Change Tracking, RMAN incremental backups are required to scan every block in the datafile to identify the blocks that have changed since the last database backup.  

Activating Change Tracking allows RMAN to read the change tracking file to identify the changed blocks.  So, RMAN incremental backups should run much faster because they are no longer required to read each and every block in the datafile.   Sounds logical to me!

What does concern me is that Change Tracking is disabled by default.  Oracle states that this is because the feature does introduce some "minimal overhead" on the database during normal day-to-day operations.  We'll need to perform some in-depth performance testing to determine exactly how much minimal overhead is incurred when Change Tracking is activated.   We intend to execute SQLLDR utilities and DML statements that insert or update millions of rows with Change Tracking off and then run the same workload with Change Tracking activated.   Once we compare the results, I'll make sure to include them in my next blog.

One change tracking file is used to track changes for the entire database.  The file is created as an Oracle managed file and, as a result, is stored in the directory identified in the DB_CREATE_FILE_DEST initialization parameter.  Administrators are also able to specify the name of the change tracking file and place it in any location they choose.

The size of the change tracking file depends on the size of the database and not the frequency of updates.  I still haven't figured out how this works but Oracle states that the size of the block tracking file is 1/30,000 the size of all the database data blocks being tracked by Change Tracking.   Oracle also states that the file is created in 10 MB increments.  For databases up to and including one terabyte, the size of the change tracking file will be 10MEGs, 2 terabyte databases will require 20MEGs and so on.
 
We are very excited about the potential performance improvement that Change Tracking offers.   It seems fairly obvious that the improvements should be considerable.    But we must determine if the level of overhead generated by the Change Tracking feature is low enough to warrant its use.  I'll keep you posted.
  
Compressed Backupsets
10G RMAN now supports binary compression of backupsets.  Administrators activate compression by specifying the AS COMPRESSED BACKUPSET parameters in the BACKUP command.   Oracle states that the backupsets are compressed using an algorithm that is optimized for efficient compression of Oracle database datafiles.  

What I like most about this feature is that you don't need to uncompress the file to use it as input to an RMAN recovery.  RMAN will automatically uncompress the file during the file restoration process.  

Oracle states that compressing the output file does increase CPU overhead for both the backup and restoration processes.   Since the majority of our backups are sent directly to tape devices, having RMAN generate smaller backup files is not really a huge benefit to us.    But there are times when we need to send a database backup to disk for performance reasons. Like many shops, we never seem to have enough disk available for the backup's output files.   We are hoping that the compression utility will help us when we need a backup immediately and are pressed for space. 
 
We'll run one backup with compression off and another with compression activated and compare the size of the output files.   We will then use the compressed backup as input to an RMAN recovery to make sure it works.   I'll let you know the results as soon as we have them!
 
Next Up
Giant Eagle's application developers have also been hard at work testing Oracle10G.  They have been running their entire batch stream nightly for close to two months now with no issues.   Performance results have been VERY positive.   In my next blog, we'll review the results of our application testing and compare some batch and on-line execution times from our 9I data warehouse to its 10G counterpart.    We are getting close to converting a couple of billion rows to Oracle10G, folks.    As one of my DBA stated at the beginning of this project "its going to be a wild ride." 

RMAN Test plan
OK, here's my super-duper Giant Eagle 10G RMAN test plan.  As I said in the introduction, it may seem like overkill but if it makes me less nervous about using 10G RMAN, the time will be well spent.  Since we have been using 10G RMAN to back up our 10G test environments, many of the items below have already been tested.  I'll make sure to provide you with everything I learned during the execution of my test plan. 

Whew, this will be a LOT of recoveries - but I need the practice.   Since I retired as an Oracle instructor, I haven't had a chance to do many recoveries.  This will be one way for me to sharpen my slightly rusty recovery skill sets.

I'll keep you posted.

 THE 10G RMAN TEST PLAN

Commands:
SQL 'ALTER DATABASE MOUNT'
SQL 'ALTER DATABASE OPEN'
 
ALTER SYSTEM SWITCH LOGFILE
ALTER SYSTEM ARCHIVE LOG CURRENT
 
ALLOCATE SINGLE TAPE CHANNEL (backup)
ALLOCATE SINGLE TAPE CHANNEL (restore)
ALLOCATE MULTIPLE TAPE CHANNELS (backup)
ALLOCATE MULTIPLE TAPE CHANNELS (restore)
ALLOCATE SINGLE DISK CHANNEL (backup)
ALLOCATE SINGLE DISK CHANNEL (restore)
ALLOCATE MULTIPLE DISK CHANNELS (backup)
ALLOCATE MULTIPLE DISK CHANNELS (restore)

CONFIGURE RETENTION POLICY TO REDUNDANCY 3
CONFIGURE DEFAULT DEVICE TYPE TO TAPE
CONFIGURE CONTROLFILE AUTOBACKUP ON
 
CREATE CATALOG
 
CROSSCHECK ARCHIVELOG ALL
CROSSCHECK BACKUP
DELETE EXPIRED BACKUP
 
LIST BACKUP
LIST BACKUP SUMMARY
LIST COPY
LIST INCARNATION OF DATABASE
 
REGISTER DATABASE
REPORT NEED BACKUP INCREMENTAL 3 DATABASE
REPORT NEED BACKUP DAYS 3 DATABASE
REPORT NEED BACKUP DAYS 3 TABLESPACE SYSTEM
REPORT NEED BACKUP REDUNDANCY 3
REPORT UNRECOVERABLE
REPORT OBSOLETE
 
RESET DATABASE
RESYNC CATALOG
SHOW ALL
 
SHUTDOWN
STARTUP
 
VALIDATE
VIEW SCHEMA
 
Backup: 
Database Backup Commands (to tape):
Hot backup of entire database (multiple channels)
Hot backup of entire database (single channel)
Hot backup of multiple tablespaces (multiple channels)
Hot backup of multiple tablespaces (single channel)
Hot backup of single tablespace (multiple channels)
Hot backup of single tablespace (single channel)
Hot backup of single datafile (single channel)
 
Hot backup of controlfiles
 
Individual data file image copy
 
Hot incremental backup of entire database (multiple channels)
Hot incremental backup of multiple tablespaces (multiple channels)
Hot incremental backup of single tablespace (multiple channels)
 
Cold backup of entire database (multiple channels)
Cold backup of entire database (single channel)
Cold backup of multiple tablespaces (multiple channels)
 
Cold backup of single tablespace (multiple channels)
Cold backup of controlfiles 
 
Cold incremental backup of entire database (multiple channels)
Cold incremental backup of multiple tablespaces (multiple channels)
Cold incremental backup of single tablespace (multiple channels)
 
Database Backup Commands (to disk):
Hot backup of entire database (multiple channels)
Hot backup of entire database (single channel)
Hot backup of multiple tablespaces (multiple channels)
Hot backup of single tablespace (multiple channels)

Hot backup of controlfiles

Cold backup of entire database with no log archiving (multiple channels)
Cold backup of entire database with archiving (multiple channels)
Cold backup of multiple tablespaces (multiple channels)
Cold backup of single tablespace (multiple channels)
Cold backup of controlfiles
 
Archive log backup (multiple channels)
 
Database Restore Commands (tape):
Complete database restore from cold backup (multiple channels)
Complete database restore from cold backup (single channel)
 
Complete database restore from hot backup to current point-in-time with archive log roll forward (multiple channels)
Complete database restore to previous point-in-time (incomplete recovery) (multiple channels)
 
Restore multiple tablespaces from hot backup (multiple channels)
Restore single tablespace from hot backup (multiple channels)
 
Complete database restore using cumulative incremental backups to current point-in-time (multiple channels)
Complete database restore using cumulative incremental backups to current point-in-time (single channel)
 
Complete database restore using incremental backups to previous point-in-time (incomplete recovery) (multiple channels)
 
Restore of multiple tablespaces to current point-in-time (multiple channels)
Restore of multiple tablespaces to current point-in-time (single channel)
 
Restore of single tablespace to current point-in-time (multiple channels)
 
Restore of individual datafile to current point-in-time (single channel)
 
Relocating tablespace to a new location during current point-in-time restore