Availability and Recovery - Changes to Incremental Backups
(Page 6 of 15 )
Oracle Database 10g offers some new improvements to incremental backups in RMAN. First, the block change tracking file is introduced to allow for better and faster incremental backups. Also, new features allow you to apply incremental backups to file image copies (another Oracle Database 10g new feature introduced earlier in this chapter) for recovery purposes. Let’s look at each of these new features in more detail.
The Block Change Tracking File
Oracle Database 10g improves incremental backups through the introduction of block change tracking. With block change tracking, a block change tracking file is created and used to track all changed blocks. The block change tracking file is updated on a regular basis as redo is generated in the database. The file is then used by RMAN during incremental backups so that, rather than having to read through each datafile to determine whether a block has changed, Oracle Database 10g only needs to read the block change tracking file to know which blocks within a datafile need to be backed up. So, now the time required to back up an Oracle Database 10g database with an incremental backup is more a factor of how much data has changed than a factor of how big the datafiles are. Also, the use of block change tracking has the benefit of reducing the overall size of your incremental backup sets.
By default, Oracle Database 10g does not record block change information in the database. Using the alter database enable block change tracking command, you can enable recording of block change information. Once this command is executed, Oracle Database 10g creates the block change tracking file and keeps it current. To disable block change tracking, you can use the alter database disable block change tracking command.
The block change tracking file is maintained in the directory defined by the db_ create_file_dest parameter, if it is configured. You can also define the location of the block change tracking file via the using file clause of the alter database enable block change tracking command. You can rename the block change tracking file with the alter database rename file command, just as you would with any normal database file. Here is an example of turning on block change tracking, using the using file clause to define where the block change tracking file should be
Alter database enable block change tacking using file '/u01/oracle/RMAN/blocktrack/my_db_tracking.chg';
Jonathan Says… In Chapter 6 we will introduce you to a new feature in Oracle Database 10g, bigfile tablespaces. These tablespaces allow you to store up to 8 exabytes, a rather large amount of data to back up. You probably wondered how you (or RMAN) were going to handle a hot backup of a file that is 8 exabytes—after all, earlier versions of RMAN have to scan the entire file to find out which blocks have changed since the last RMAN backup. Using the block change tracking file is the answer—but it does suggest that if you start thinking about bigfiles, you really ought to be looking at RMAN as your strategic backup mechanism. By the way, this is yet another I/O load on your system—do you have the bandwidth to handle it? Better check the impact carefully. |
The block change tacking file size is a factor of a number of things, including the number of enabled redo threads, the size of the database, and the number of RMAN backups for which change data needs to be stored. The formula looks like this:
R=((T * 2)+ B) * (S/250000)
where the following are the values:
- R The size of the block change tracking file, in bytes
- T The number of enabled redo threads
- S The size of the database, in bytes
- B The number of incremental backups for which RMAN needs to store change tracking data
In a test 800MB database, the tracking file (with one backup) was about 10MB. Note that Oracle Database 10g will only track change tracking data required for a maximum of eight incremental backups.
If you want to see the status of the block change tracking file, you can use the V$BLOCK_CHANGE_TRACKING view, which gives you the name and location of the block change tracking file, its size, and its status.
The V$BACKUP_DATAFILE view can be used to determine how effective the use of the block change tracking file is. This view can tell you what percentage of blocks in the tablespace that RMAN will be reading (via the BLOCKS_READ column). If the percentage is high, then RMAN will take longer to back up the database. If this is the case, you may want to schedule your incremental backups more frequently.
Applying Incremental Backups to Restore Datafile Image Copies
Earlier, this chapter introduced datafile image copies, a new feature in Oracle Database 10g. If you perform incremental backups in Oracle Database 10g, another new feature that might interest you is that you can restore your database using a combination of datafile image copies and incremental backups. To apply incremental backups to datafile copies, you restore the datafile copies (using the RMAN restore command), and then use the recover copy of datafile command to finish the recovery process. Here is an example:
RMAN> Recover copy of datafile 6;
RMAN> recover copy of database;
RMAN> recover copy of tablespace users;
Note that RMAN will return a warning, not an error, if it cannot restore the database forward to the specified or current time with incremental backups.
Recovering Datafiles Not Backed Up
Previous to Oracle Database 10g, a datafile had to have been backed up for RMAN to restore and recover it. In Oracle Database 10g, RMAN allows you to perform recovery of a datafile without it having first been backed up. If the datafile is not available in a backup set, RMAN uses the control file to create an empty copy of that datafile. RMAN can then use archived redo logs to recover the datafile. This implies that, to successfully complete the recovery, Oracle Database 10g requires all archived redo to be available since the datafile was created. RMAN performs this type of recovery automatically if required.
NOTE -- You can only restore missing datafiles with the restore datafile command. Therestore database and restore tablespace commands do not support this functionality.
Automatic Channel Failover
In Oracle Database 10g, the behavior of RMAN changes with regard to the failure of a channel during an RMAN backup. In Oracle Database 10g, if a channel fails, the backup process on that channel fails and will not be restarted. However, backups on other remaining channels will continue to run. Once the backup process is complete, RMAN will report errors that occurred during the backup process. This feature ensures that as many datafiles get backed up as possible, in spite of the error condition.
 This chapter is from Oracle Database 10g New Features, by Robert Freeman (McGraw-Hill/Osborne, 2004, ISBN: 0072229470). Check it out at your favorite bookstore today. Buy this book now.
|
Next: Compressing RMAN Backups >>
More Oracle Articles
More By McGraw-Hill/Osborne
/ 15 
