Recovery Catalog
The recovery catalog can be
loosely compared to a database catalog. Recovery manager uses the
catalog's repository of information to keep track of backup and
recovery operations. The recovery catalog must be contained in an
Oracle database but does not require the creation of an additional
database. The catalog can be placed in an existing database if
desired. It is highly recommended that you create the RMAN
repository
in a separate database that is used only for RMAN operations.
The recovery catalog contains information on:
Administrators are able to create scripts and store them in the recovery catalog. Stored scripts allow administrators to chain a sequence of backup or recovery operations together and execute them as a single unit.
Channels
A channel is a data stream that is sent
to a device. The most common devices are disk and tape.
Administrators are able to automatically configure channels using the
RMAN CONFIGURE command or they can explicity define the channel in the
RMAN backup or recovery script.
The example below shows an RMAN script that allocates a device type of SBT (TAPE) and names the channel TAPE1. The next line tells RMAN to back up the entire database including all of the archive logs.
RUN
{
ALLOCATE CHANNEL tape1 DEVICE TYPE
sbt;
BACKUP DATABASE PLUS ARCHIVELOG;
}
This example allocates a channel to disk with all files created by this channel having the format '/u01/rpprod1/backup/23005tools.bak'. The script backs up one database datafile.
RUN
{
ALLOCATE CHANNEL d1 DEVICE TYPE disk
FORMAT = '/u01/rpprod1/backup/23005tools.bak';
BACKUP DATAFILE '/u01/oracle/oradata/rpprod1/tools01.dbf';
}
Our last example allocates 3 disk channels, performs an incremental level 0 (base) backup and uses channel d1 to backup data files 1, 4 and 5, d2 to backup up data files 2, 3 and 6 and so on. The naming convention of the output files will begin with the characters "df_" followed by database name, set name and piece name.
RUN
{
ALLOCATE CHANNEL d1 DEVICE TYPE disk;
ALLOCATE CHANNEL d2 DEVICE TYPE disk;
ALLOCATE CHANNEL d3 DEVICE TYPE disk;
BACKUP
INCREMENTAL LEVEL = 0
FORMAT = '/u01/rpprod1/backup/df_%d_%s_%p.bak';
(DATAFILE 1, 4, 5 CHANNEL d1 tag=df1)
(DATAFILE 2, 3, 6 CHANNEL d2 tag=df2)
(DATAFILE 7, 8, 9 CHANNEL d3 tag=df3);
sql 'alter system archive log current';
}
Recovery Manager Backup
Types
Recovery Manager supports two different types of backups: backup sets
and image copies:
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. Recovery Manager 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. Recovery Manager 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. Recovery Manager also provides cumulative backups. Cumulative backups copy all blocks that have been changed since the most recent incremental backup.
Image Copies
An image copy is a single datafile
that you can use as input to a recovery. The Oracle server process
validates the blocks in the file during backup and registers the copy
in the recovery catalog. Image copies do not require the
execution of
a recovery operation, the datafile can be renamed to the image copy.
As a result, image copies:
Parallel Backup and Recovery
Recovery Manager is
able to parallelize a single backup, recovery or restore operation, but
is unable to process multiple commands in a stored script in parallel.
The RMAN script below uses three channels to back up three data files identified by their file number. This creates three separate server processes each one sending a data stream to the tape device.
RUN
{
ALLOCATE CHANNEL t1 DEVICE TYPE sbt;
ALLOCATE CHANNEL t2 DEVICE TYPE sbt;
ALLOCATE CHANNEL t3 DEVICE TYPE sbt;
BACKUP DATAFILE 3,4,5 ;
}
Multiplexed Backup Sets
A backup process is able
to take concurrent backups of multiple data files, or one or more
multi-file tablespaces and multiplex the output into a single stream.
Backup/Recovery Reports
Recovery Manager provides two commands to provide information relating
to backups and image copies:
Database Restore and Recovery
The database restoration process is performed by executing the
RMAN RESTORE and RECOVER commands.
The RESTORE command tells RMAN to retrieve files from RMAN backups based on the contents of the RMAN repository.
You use the RECOVER command in Recovery Manager to perform media recovery and apply incremental backups and redo logs (archived or online) if necessary. Recovery Manager uses the recovery catalog to select the backup sets or image copies to use as input to the recovery operation.
There are four variations of the recover command:
This sample recovery script allocates three disk channels, performs a point-in-time recovery to the specified time and resets the logs when opening the database:
RUN
{
ALLOCATE CHANNEL d1 DEVICE TYPE disk;
ALLOCATE CHANNEL d2 DEVICE TYPE disk;
ALLOCATE CHANNEL d3 DEVICE TYPE disk;
SET UNTIL TIME = '2005-02-28:11:00:00';
RESTORE DATABASE;
RECOVER DATABASE;
SQL 'alter database open resetlogs';
}
RMAN Examples
The examples below should give you a general understanding of how RMAN
is used to back up and recover an Oracle database:
Sample RMAN Scripts
This command uses two
backupSpec clauses to back up tablespaces and datafiles and lets RMAN
perform automatic parallelization of the backup. A channel must be
allocated when it accesses a disk or tape drive. The backup is
identifying files by tablespace name and fileid.
RUN
{
ALLOCATE CHANNEL dev1 DEVICE TYPE DISK FORMAT '/fs1/%U';
ALLOCATE CHANNEL dev2 DEVICE TYPE DISK FORMAT '/fs2/%U';
BACKUP
(TABLESPACE SYSTEM,sales1,sales2,sales3
FILESPERSET 10)
(DATAFILE 12,14,15);
}
The following example takes the USERS tablespace offline, uses automatic channels to restore and recover it , then brings it back online. Notice that we don't care what the backupset file names are or where the archived logs are located - RMAN handles it all!
RUN
{
SQL "ALTER TABLESPACE users OFFLINE IMMEDIATE";
RESTORE TABLESPACE tools;
RECOVER TABLESPACE tools;
SQL "ALTER TABLESPACE tools ONLINE";
}
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.