New 10g Features on RMAN


V$RECOVERFILE
If you aren't using RMAN to perform the recovery, you can query the V$RECOVERFILE table to determine how many files are missing or corrupted before you have them restored. The operators will like you much better and the recovery process will be a lot faster if you restore all of the files that have been lost at the same time.

Watch the NOLOGGING Option
The NOLOGGING option is great for performance but it tends to complicate recoveries that require redo log entries to be applied. If you load or insert data using the NOLOGGING option and you don't immediately take a backup, you're asking for trouble. If you have to execute a database recovery, the database will be out of synch.  During the application of the redo log entries, the data loaded or inserted using the NOLOGGING option will not be in the redo logs.  This means that the data will not be replayed during the database recovery.   If transactions that depend on the missing data are replayed during the recovery, they will be accessing data that's not there!   Bad things will happen to your recovery as a result.   Take a backup after a NOLOGGING statement or utility execution.

Recovery Manager Backup Types
Recovery Manager supports two different types of backups: backup sets and image copies:

1-Backup Sets
Backup sets consist of datafiles or archivelogs.  A single backup set cannot contain a combination of archivelogs and datafiles. A backup set can contain a combination of datafile and control file backups. Recovery Manager allows you to move archived logs from disk to tape. Backup sets containing moved archived logs are called archivelog backup sets.
Backup sets consist of one or more individual backup files. The individual files contained in a backup set are called backup pieces. RMAN uses the backup sets as input for recovery operations. Backup sets can be written to disk or sequential output media (tape). The V$BACKUP_DEVICE contains a list of backup devices that are supported by your platform.
Backup sets can be full or incremental. A full backup is a backup of all of the blocks that make up a datafile or datafiles. RMAN allows you to take full backups of datafiles, datafile copies, tablespaces, archive logs, control files and databases.
Incremental backups copy blocks that have been changed since a previous backup. Incremental copes can be taken of datafiles, tablespaces and databases. RMAN also provides cumulative backups. Cumulative backups copy all blocks that have been changed since the most recent incremental backup.

2- Image Copies
An image copy of a datafile, on the other hand, is much faster to restore because the physical structure of the datafile already exists. Oracle 10g now permits image copies to be created at the database, tablespace, or datafile level through the new RMAN directive BACKUP AS COPY. For example, here is a command script to create image copies for all datafiles in the entire database:
RUN {
# Set the default channel configuration. Note the use of the
# %U directive to insure unique file names for the image copies
ALLOCATE CHANNEL dbkp1 DEVICE TYPE DISK FORMAT 'c:\oracle\rmanbkup\U%';
# Create an image copy of all datafiles in the database
BACKUP AS COPY DATABASE;
}

Another Example:
RUN {
# Set the default channel configuration
ALLOCATE CHANNEL dbkp1 DEVICE TYPE DISK FORMAT 'c:\oracle\rmanbkup\ic_%d_%s_%t_%p';

# Back up specific datafiles and retain them as an image copies
BACKUP AS COPY (DATAFILE 2, 6, 9 MAXSETSIZE 25M);

# Back up a specific tablespace and retain it as an image copy
BACKUP AS COPY (TABLESPACE example MAXSETSIZE 15M);

# Back up the whole database and retain it as an image copy
BACKUP AS COPY DATABASE;
}

Incrementally Updated Backups
Another new Oracle 10g feature, incrementally updated backups, allows me to apply incremental database changes to the corresponding image copy backup - also known as rolling forward the datafile image copy -- of any datafile in the database. Since image copy backups are much faster to restore in a media recovery situation, this new feature gives me the option to have updated image copies ready for restoration without having to recreate the image copies on a regular basis.
To utilize this feature, I will need to use the new BACKUP ... FOR RECOVER OF COPY command to create the incremental level 1 backups to roll forward the changes to the image copy of the datafiles, and use the new RMAN RECOVER COPY OF DATABASE command to apply the incremental backup to the image copies of the datafiles. Note that the TAG directive becomes extremely important to this implementation, as it is used to identify to which image copies the changes are to be rolled forward.
Here is a script that illustrates a daily cycle of creation and application of the incrementally updated backups. This would be appropriate for a database that has sufficient disk space for storage of image copies, and has a relatively high need for quick restoration of media:
RUN {
# Roll forward any available changes to image copy files
# from the previous set of incremental Level 1 backups
RECOVER
COPY OF DATABASE
WITH TAG 'img_cpy_upd';

# Create incremental level 1 backup of all datafiles in the database
# for roll-forward application against image copies
BACKUP
INCREMENTAL LEVEL 1
FOR RECOVER OF COPY WITH TAG 'img_cpy_upd'
DATABASE;
}

Though this appears a bit counter-intuitive at first, here is an explanation of what happens during the initial run of this script:
    * The RECOVER command actually has no effect, because it cannot find any incremental backups with a tag of img_cpy_upd.
    * However, the BACKUP command will create a new Incremental Level 0 backup that is labeled with a tag of img_cpy_upd because no backups have been created yet with this tag.

And during the second run of this script:
    * The RECOVER command still will have no effect, because it cannot find any Level 1 incremental backups with a tag of img_cpy_upd.
    * The BACKUP command will create its first Incremental Level 1 backup that is labeled with a tag of img_cpy_upd.

But during the third and subsequent runs of this script:
    * The RECOVER command finds the incremental level 1 image copy backups from the previous night's run tagged as img_cpy_upd, and applies them to the existing datafile image copies.
    * The BACKUP command will create the next Incremental Level 1 backup that is labeled with a tag of img_cpy_upd.
After the third run of this script, RMAN would then choose the following files during a media recovery scenario: the image copy of the database for tag img_cpy_upd from the previous night, the most recent incremental level 1 backup, and all archived redo logs since the image copy was taken. This strategy offers a potentially quick and flexible recovery, since the datafile image copies will be relatively quick to restore, and the incremental level 1 backup plus all archived redo logs can be used to perform either a point-in-time or a complete recovery.


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!
Oracle states that this feature does introduce some "minimal overhead" on the database during normal day-to-day operations. 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. 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 one terabyte, the size of the change tracking file will be 10MB, 2 terabyte databases will require 20MB and so on. 
Oracle does recommend that this feature be activated for any database whose disaster recovery plan utilizes incremental backups of differing levels.
Example:
-- Activate block change tracking.
ALTER DATABASE ENABLE BLOCK CHANGE TRACKING; 
or
ALTER DATABASE ENABLE BLOCK CHANGE TRACKING USING FILE 'c:\oracle\rmanbkup\ocft\cft.f' REUSE;

-- Verify block change tracking file's existence
SELECT * FROM v$block_change_tracking;


Server Parameter File (SPFILE) AutoBackups
Oracle 9i added the ability to configure automatic control file backups to occur whenever specific RMAN operations happened, or when the DBA performed a significant modification of the database's logical or physical structure that affected the control file (e.g. adding a new tablespace, or renaming a datafile).
Oracle 10g expands this feature to include the auto-backup of the database's server parameter file - the binary copy of the initialization parameter file -- as well.

Enhanced BEGIN BACKUP
Finally, here is a neat enhancement for user-managed backups: The BEGIN BACKUP command that is used to take tablespaces offline one at a time has been enhanced so that all of the database's tablespaces can be taken offline at once:
-- Take all datafiles offline before starting user-managed backup
ALTER DATABASE BEGIN BACKUP;
-- Bring all datafiles back online after completing user-managed backup
ALTER DATABASE END BACKUP;
This command certainly has value for smaller but no less mission-critical databases like OEM or RMAN recovery catalog repositories.

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.

Restoration and Recovery Enhancements
RESTORE Failover
Oracle 10g has also significantly improved the restoration process during initial restoration and recovery efforts:
    * If RMAN should detect a damaged or missing backup file, it will automatically attempt to locate another usable copy of the image copy or backup piece, either at the default location or at an alternate multiplexed location.
    * If it cannot find a usable current copy, it then looks at prior backup pieces or image copies and attempts to restore from those files.
    * If RMAN cannot locate any appropriate backup or image copy, only then will it issue an error and terminate the RMAN session.

RESTORE ... PREVIEW
If you have ever wondered exactly what backup files or image copies RMAN will use to perform restoration, Oracle 10g now offers the RESTORE ... PREVIEW command set to show exactly what backup pieces or image copies RMAN plans to utilize.
-- What files will RMAN use during a RESTORE operation?
-- NOTE: These commands should be issued from within an active RMAN session
# Spool output to a log file
SPOOL LOG TO c:\oracle\rmancmd\restoresummary.lst;

# Show what files will be used to restore the SYSTEM tablespace's datafile
RESTORE DATAFILE 1 PREVIEW;

# Show what files will be used to restore a specific tablespace
RESTORE TABLESPACE hr PREVIEW;

# Show a summary for a full database restore
RESTORE DATABASE PREVIEW SUMMARY;

# Close the log file
SPOOL LOG OFF;