Recovery Manager supports two different types of backups: backup sets and image copies:
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:
# 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;
# 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;
Change Tracking for
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.
-- Activate block change tracking.
ALTER DATABASE ENABLE BLOCK CHANGE TRACKING;
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;
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.
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.
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.