Oracle8(TM) Server Backup and Recovery Guide
Release 8.0

A54640-01

Library

Product

Contents

Index

Prev Next

8
Performing Backup and Recovery with Recovery Manager

This chapter describes how to use Recovery Manager to manage backups, restores and recovery of your database, and includes the following topics:

Installing the Recovery Catalog

Recovery Manager can operate with or without a recovery catalog. If you wish to use a recovery catalog, you just install it before using Recovery Manager.

To Install the Recovery Catalog

  1. Create or identify the user who will own the catalog. If you wish, you can create a separate tablespace that will contain the recovery catalog.
    create user rman identified by rman
      temporary tablespace temp
      default tablespace rcvcat
      quota unlimited on rcvcat;
    grant recovery_catalog_owner to rman;
    
  2. Connect using the userid created in Step 1, and create the recovery catalog schema:
    connect rman/rman
    @?/rdbms/admin/catrman
    
  3. To connect to target databases over the network (for example, non-local target databases) you will need to configure a password file. Local databases can use operating system authentication.
  4. Start rman

You can now use Recovery Manager.

Registering a Database

If you are creating a new database or migrating an existing Oracle7 database, issue the following command:

      register database;

If Recovery Manager is installed for use with an existing version 8.x database, issue the following command:

      register database;

If there are any existing user-created backups on disk that were created under version 8.x, these should be added to the recovery catalog by issuing the following command:

      catalog datafilecopy `filename';

Note that for an Oracle7 backup to be usable for recovery in an Oracle8 database, it must have been part of a tablespace which was offline normal or read-only when the database was migrated.

Any existing archivelogs should be cataloged as follows:

      catalog archivelog `filename';

See Also: For more information about the recovery catalog, see Chapter 3, "When to Perform Backups".

Maintaining the Recovery Catalog

This section describes how to maintain and manipulate the recovery catalog, and includes the following topics:

Registering a Target Database with the Recovery Catalog

Before using Recovery Manager with a particular target database for the first time, you must register the target database in the recovery catalog. Recovery Manager obtains all information it needs to register the target database from the target database itself. The target database must be mounted for this operation.

Oracle uses an internal, uniquely generated number called the "db identifier" to distinguish one database from another. This number is generated at the time you create the database. Typically, each database has a unique identifier; however, an exception occurs with databases created by copying files from an existing database (instead of using a create database statement). In these cases, the duplicate database identifiers are detected and the register database command fails. If this occurs, you can create a second recovery catalog in another user's schema by re-executing the catrman.sql script from a different Oracle user ID. Then, the database with a duplicate database identifier can be registered into the newly created recovery catalog in the new schema.

Note: If you are using Recovery Manager with different target databases that have the same database name and identifier, you must be extremely careful to always specify the correct recovery catalog schema when invoking Recovery Manager.

Resetting the Information in the Recovery Catalog

Before you can use Recovery Manager again with a target database that has been opened with the RESETLOGS option, you must notify Recovery Manager that the database incarnation has been reset. The reset database command tells Recovery Manager to create a new database incarnation record in the recovery catalog. This new incarnation record becomes the "current" incarnation. All subsequent backups and log archiving done by the target database will be associated with the new database incarnation.

If you issue the ALTER DATABASE OPEN RESETLOGS command, but do not reset the database, then Recovery Manager will not access the recovery catalog because it cannot distinguish between a RESETLOGS command and an accidental restoration of an old control file. Resetting the database tells Recovery Manager that the database has been opened with the RESETLOGS option.

In the rare situation when you wish to undo the effects of opening with the RESETLOGS option by restoring backups of some prior incarnation of the database, you can use the reset database to incarnation key command to change the current incarnation to an older incarnation. You must specify the primary key of the dbinc record for the desired database incarnation. You can obtain the key value by issuing the list incarnation of database identifier command. Then, after issuing the reset database to incarnation command, issue the restore and recover commands to restore and recover the database files from the prior incarnation.

Resynchronizing the Recovery Catalog with a Target Database

You must resynchronize the recovery catalog on a regular basis because the recovery catalog is not updated automatically when a log switch occurs or when a log is archived. Instead, information about log switches and archivelogs is stored in the control file, which must be propagated periodically into the recovery catalog. How frequently you resynchronize the recovery catalog depends upon the rate at which logs are archived. The cost of the operation is proportional to the number of records in the control file that have been inserted or changed since the previous resync. If no records have been inserted or changed, then the cost of resynchronization is very low. Thus, it is feasible to perform this operation frequently (for example, hourly) without incurring undue costs.

Note: The backup, copy, restore and switch commands update the recovery catalog automatically if:

If the recovery catalog is unavailable during a backup or copy, you should resynchronize it.

You must also resynchronize the recovery catalog after making any change to the physical structure of the target database. As with log archive operations, the recovery catalog is not updated automatically when a physical schema change is made. A physical schema change includes any of the following operations:

When resynchronizing the recovery catalog, Recovery Manager compares the recovery catalog to either the current control file of the target database, or a backup control file, and updates the recovery catalog with information that is missing or changed. When resynchronizing from the current control file, Recovery Manager automatically detects the records in the control file that have been updated and resynchronizes only those records. If the target database is open, then information about rollback segments is also updated in the recovery catalog (this information is used for Tablespace Point-In-Time Recovery). When resynchronizing from a backup control file, Recovery Manager does not verify that the backup pieces or file copies actually exist. Thus, it may be necessary to use the change...uncatalog command to remove records for files that no longer exist.

The following classes of recovery catalog records are resynchronized:

log history These records are created when a log switch occurs. Recovery Manager tracks this information so that it knows what archive logs it should expect to find.

archivelog These are records associated with archived logs that were created by archiving an online log, by copying an existing archivelog, or restoring an archivelog backup set.

backup history These are records associated with backup sets, backup pieces, backup set members, and file copies. The resync catalog command updates these records when a backup or copy command is executed.

physical schema These are records associated with datafiles and tablespaces. If the target database is open, then rollback segment information is also updated.

Physical schema information in the recovery catalog is updated only when the target database has the current control file mounted. If the target database has mounted a backup control file, a freshly created control file, or a control file that is less current than a control file that was seen previously, then physical schema information in the recovery catalog is not updated. Physical schema information is not updated when you use the resync catalog from backup controlfile command.

If the target database is open when you resynchronize, a new consistency point is created in the recovery catalog.

Changing the Availability of a Backup Set or File Copy

The Recovery Manager change command enables you to make the following record changes:

You can use the change ... uncatalog operand to remove records that refer to a file that is no longer extant from the recovery catalog. It is important that you use this command to notify Recovery Manager when a backup piece, file copy, or archivelog is deleted by some means other than a change...delete command. change ... uncatalog can only be used when operating with a recovery catalog.

The delete operand functions like the uncatalog operand, but in addition, the operating system or Media Manager is called to delete the backup piece, or backup set. This command must be preceded by an allocate channel for delete command, specifying the device type appropriate for the file being deleted.

When a large number of files have been deleted from disk, the most efficient method of reconciling the recovery catalog with what remains on disk is to use a change ... validate command. This command validates that the specified backup pieces, file copies and archived logs which should be available on disk, are physically there; if a file is not there, the reference to that file is removed from the recovery catalog and the control file.

The unavailable operand is provided for cases when the file cannot be found or has migrated off site. A file that is marked unavailable will not be used in a restore or recover command. If the file is later found or returns to the main site, then it can be marked available again by using the available operand.

The change command operates only on files that are recorded in the recovery catalog (or the control file) and belong to the current database incarnation. The same is true for other commands except catalog and resync from controlfilecopy.

Deleting a Catalog Record: Example

If a cataloged file is deleted through some means other than Recovery Manager, or is otherwise lost or damaged, then the catalog record should be deleted.

If the file is on disk:

change datafilecopy <primary_key> delete;
change archivelog <primary key> delete;

If the file is stored by a Media Manager:

allocate channel for delete type `tape';
change backuppiece <primary_key> delete;
release channel;

You can obtain the primary keys of the records to be deleted by issuing a list command.

Deleting many Catalog Records: Example

If you need to reconcile the recovery catalog with what is on disk when a large number of files have already been deleted, you may wish to use the change ... validate command:

      change datafilecopy <primary_key> validate;
      change archivelog all validate; 

Cataloging User-Created Backup Files

Often it is useful to make Recovery Manager aware of the existence of file copies which are created via means other than Recovery Manager.

You can use the catalog command to add information to the recovery catalog and control file about a datafile copy, archivelog, or controlfile copy.

Note that Oracle 8.x continues to support the ALTER TABLESPACE BEGIN/END BACKUP which allows open database operating system backups to be made. Although Recovery Manager does not create such backups, they can be added to the recovery catalog so that Recovery Manager is aware of them.

Any such backup must be accessible on disk, and must be a complete image copy of a single file. A datafile backup may be either a consistent or inconsistent whole database, tablespace or datafile backup. Recovery Manger treats all such backups as datafile copies.

For example, if datafiles are stored on mirrored disk drives, then it is possible to create an operating system copy by simply breaking the mirror. In this scenario, the catalog command is used to notify Recovery Manager of the existence of the operating system copy after breaking the mirror. Before the mirror is reformed, a change ... uncatalog command should be issued to notify Recovery Manager that the file copy is being deleted.

The catalog command is restricted to cataloging only those files associated with the current incarnation of the database. Archivelogs and control file copies that were created from version 7.x or earlier cannot be cataloged.

Datafile copies which were created from version 7.x or earlier can be cataloged if the file belongs to a tablespace which was offline normal or read-only when the database was migrated to Oracle8.

Recovering a Lost or Damaged Recovery Catalog Database

If the recovery catalog database is lost or damaged, and recovery of the recovery catalog database via the normal Oracle recovery mechanisms is not possible, then there are two options for partially re-creating its contents:

  1. Issue catalog commands to re-catalog archivelogs, backup control files, and datafile copies.
  2. Use the resync catalog from backup controlfile command to extract information from a backup control file and rebuild the recovery catalog from it.

Note that you can re-create information about backup sets only by using the resync catalog from backup controlfile command because the catalog command does not support re-cataloging of backup pieces or backup sets. Recovery Manager does not verify that the files being re-cataloged still exist, so the resynchronization may add records for files that no longer exist. You should remove such records by issuing change...uncatalog commands.

Using Channel Controls

You can use channel control commands to perform the following tasks:

Each channel allocation establishes a connection from Recovery Manager to a target database instance. Multiple channels can be allocated simultaneously, thus allowing multiple backup sets or file copies to be read or written in parallel by a single job. Thus, the degree of parallelism within a job is controlled by the number of channels (connections) that are allocated.

Each channel allocation uses a separate connection. You can specify a different connect string for each channel. This is useful in an OPS (Oracle Parallel Server) configuration for distributing the workload across different nodes.

Whether or not the allocate channel command actually causes operating system resources to be allocated is operating system dependent. On some platforms, operating system resources are allocated at the time the command is issued. On other platforms, operating system resources are not allocated until a file is opened for reading or writing. Furthermore, when type disk is specified, no operating system resources at all are allocated by this command.

At least one allocate channel command must precede a backup, copy, restore or recover command. The copy command can use only channels that specify type disk. Other devices types that happen to be allocated when a copy command executes are ignored.

See Also: For more information about channel commands, see your operating system-specific Oracle documentation.

Types of Channel Commands

allocate channel

The allocate channel command establishes a connection to a target database instance. Each connection operates on one backup set at a time (for backup, restore, or recover) or one file copy at a time (for copy). If multiple connections are established, then each connection operates on a separate backup set or file copy.

If a backup set is to be written to or read from disk, then you must use the type disk allocate operand. Otherwise, it is assumed that the device is a sequential I/O device (for example, tape). Copies are always written to disk, therefore they can use only channels that have type disk specified.

The allocated channel must be given a name (channel_id) that is used when releasing the channel and when reporting I/O errors. The channel_id is any blank-delimited character string, other than a keyword, that is meaningful to the user.

type This operand specifies either disk or a quoted string. If disk is specified, then all backup sets written or read by this connection are on disk. If a quoted string is specified, then it is assumed to be a platform-specific specification of some type of sequential I/O device or access method.

The exact syntax and semantics of sequential I/O device types are platform-specific. If you do not specify this operand, then you must specify the name operand to identify a particular sequential I/O device.

name This port-specific string specifies the name of the sequential I/O device to allocate. If you do not specify, then any available device of the specified type is used. Do not use this operand if type disk is specified.

parms This port-specific string specifies parameters regarding the device to allocate. Do not use this operand if you've specified type disk.

connect This parameter specifies a connect string to the target database instance where Recovery Manager should conduct the backup or restore conversation. This parameter is intended for use by OPS installations that want to spread the work of backup or restore across different OPS instances. If you do not specify this parameter, then all conversations are conducted on the target database instance specified by the target command-line parameter.

format This parameter specifies the format to use for the names of backup pieces that are created on this channel. This format will only be used if no format option is specified in the backup command. See the description of the format operand of the backup command.

release channel

The release channel command releases a sequential I/O device. However, the connection is maintained for additional channel allocation commands. The operand is simply the channel_id specified when the channel was allocated.

set limit channel

The set limit channel commands specify limits that apply to any backup or copy command that executes using this device.

readrate This limit specifies the maximum number of buffers (each of size db_blocksize * db_file_direct_io_count) per second which will be read for backup or copy from each of the input datafiles. Use this parameter to ensure that the command does not consume excessive disk bandwidth, and thereby degrade on-line performance.

kbytes This specifies the maximum size of backup pieces created on this channel.

maxopenfiles This limit controls the maximum number of input files that a backup will have open at any particular instant. This parameter is used for preventing "too many open files" operating system errors when backing up a large number of files into a single backup set.

If maxopenfiles is not specified, then a maximum of 32 input files may be open concurrently.

Generating Reports

You can use the report command to produce two kinds of reports that answer questions such as the following:

The list command queries the recovery catalog and produces a listing of its contents. The following types of information may be listed:

The report and list commands produce similar output. The list commands simply list the contents of the recovery catalog. The report commands perform more detailed analyses of the recovery catalog. The output from the report and list commands is written to the message log file.

The report need backup and report unrecoverable commands should be used on a regular basis to ensure that the necessary backups are available to perform recovery, and to ensure that the recovery can be performed within a reasonable length of time. The list commands can be used to query what backups or copies are available.

Generating a Report

You can use the report command to produce one of the following types of reports:

Where:

report_object_list This specifies the datafile(s) to be reported on. The report can include the entire database (optionally skipping certain tablespaces), a list of tablespaces, or a list of datafiles.

device_type_list This option can be used to limit the backup sets which will be considered when deciding whether or not a file is unrecoverable or is in need of a more recent backup. If specified, only backup sets which reside on one of the specified device types will be considered. If not specified, all available backup sets will be considered. Datafile copies will always be considered.

Listing Unrecoverable Datafiles

You can use the report unrecoverable command to list all datafiles that are unrecoverable. A datafile is considered unrecoverable if an UNRECOVERABLE operation has been performed against an object residing in the datafile since the last backup of the datafile.

Note that the non-existence of any backup of a datafile is not sufficient reason to consider it unrecoverable. Such datafiles can be recovered through the use of the create datafile command, provided that logs starting from when the file was created are still in existence.

Example: Datafiles Requiring a New Backup

The following command lists all datafiles that cannot be completely recovered from the existing backups because redo may be missing:

report unrecoverable;

Listing Datafiles that Need to be Backed Up

report need backup lists all datafiles that are considered to be in need of a new backup. The report assumes that the most recent backup would be used in the event of a restore.

need_backup_operands are as follows:

incremental An integer specifying a threshold number of incremental backups. If complete recovery of a datafile would require the application of more than this many incremental backups, then the datafile is considered in need of a new full backup. This assumes the most efficient strategy, which is to use the lowest level of incremental backup whenever there is a choice. This is the same strategy that would be used if the file were actually being recovered by the recover command.
Note that files for which no backups exist will not appear in this list. They can be found by using the report need backup days command.

days An integer specifying a threshold number of days of log files that will need application during recovery of this file. For online files, this is the number of days since the last full or incremental backup of a file. The time of day is not considered when calculating the age of a backup set (i.e. a backup taken anytime yesterday is 1 day old). If multiple copies of a backup set exist, the completion time of the original backup set is used. If the most recent backup of this file is older than this number of days, then the file is considered to be in need of a new backup.

If the target database controlfile is mounted and current, the following optimizations will be made to this report:
1. Files which are offline and whose most recent backup contains all changes to the file will not be included.
2. Files which were offline and are now online, and whose most recent backup contains all changes up to the offline time, will only be reported if they have been online for more than the specified number of days.

redundancy An integer specifying the minimum level of redundancy considered necessary. redundancy 2 means that there must be at least 2 backups of each datafile for it for it to be considered not in need of a backup.

Example: Datafiles That Need to be Backed Up

The following command reports all datafiles in the database that would require the application of three or more incremental backups to be recovered to their current state:

report need backup incremental 3 database;

The following command reports all datafiles from tablespace "system" that haven't had a backup (full or incremental) in 5 or more days:

report need backup days 5 tablespace system;

Listing Obsolete Datafile Backups

You can use the report obsolete command to list backup sets and datafile copies that can be deleted because they are redundant.

A backup is obsolete if it meets one of the following criteria:

report_obsolete_operands are as follows:

redundancy An integer specifying the minimum level of redundancy considered necessary. If more than this many full backups or copies exist for a given datafile, then the remainder of the backups are obsolete. This must be non-zero. The default value is one.]

orphan Specifies that backups and copies which can never be used because they belong to incarnations of the database which are not predecessors of the current incarnation, will be considered obsolete.

until-clause If an until-clause is specified, then no backup will be considered obsolete or redundant if it contains any changes beyond the specified time. This is useful if the database must be recoverable to a point in time which is earlier than the present time.

Listing Datafiles at the Current Time

The report schema command lists the names of all datafiles and tablespaces at the specified point in time, or at the current time. A point in time may be specified as a time, an SCN, or a redo log.

The at_clause has the following structure:

at time A Quoted string specifying the time.

at scn An integer representing the SCN is specified.

at logseq integer thread integer

Integers which specify the log sequence number and thread number to consider. This time is the time when the specified log and thread were first opened.

Generating Lists

You can use the list command to produce a detailed report of all information about a specified group of backup sets or copies known to the recovery catalog. The following list commands are available:

List information about datafiles copies and archivelogs.
List information about backup sets.
List information about the incarnations of a database. The listing will include the primary keys of all database incarnation records for the specified database name. The key can then be specified in a reset database command to change the incarnation that Recovery Manager considers to be current to a previous incarnation. If no identifier is specified, then all databases registered in the recovery catalog are listed.

list_object_list

This specifies the tablespaces, datafiles, or archivelogs whose backup sets or copies are to be listed.

database skip_clause Backup sets or datafile copies of all files in the current database are listed. Optionally, tablespaces may be skipped by using the skip_clause

tablespace A list of tablespace names. Backup sets or datafile copies that include at least one datafile from a specified tablespace are listed.

datafile A list of datafile names or numbers. Backup sets or datafile copies that contain at least one of the specified datafiles are listed.

archivelog_record_specifier

list_qualifier_list

List qualifiers are specifications that can be used to limit the the objects whose backup sets or copies are to be listed:

tag tag Datafile copies and backup sets may be restricted by specifying the tag of the copy or backup. If tag is specified, only copies/backups with the specified tag will be listed.

like file_name_pattern Datafile copies and archived logs may be restricted by specifying a file name pattern. The pattern may contain Oracle pattern matching characters `%' and `_'. If file_name_pattern is specified, only files whose name matches the pattern will be listed.

from/until time All files may be qualified with a time range. If from or until is specified, only copies or backups which completed within the specified time period will be listed. Either or both of these options may be specified.

device_type_list This option applies only to the list backupset command. If specified, only backup sets which reside on one of the specified device types will be listed. If not specified, all available backup sets will be listed.

Example: Listing Backups of a Datafile

The following command will list all known backups of datafile `?/dbs/foo.f':

list backupset of datafile "?/dbs/foo.f";

Example: Listing Copies of the Datafiles of a Tablespace

The following command will list all copies of datafiles in tablespace "system":

list copy of tablespace system;

Maintaining Scripts

A stored script is a named entity. Any meaningful name can be given to a stored script. The execute script command is used to execute a stored script. Note that the execute script command is legal only within a job_command_list.

Four stored script commands are available:

The stored script feature is provided primarily to provide a common repository for frequently executed collections of Recovery Manager commands. For example, the Recovery Manager commands needed to do nightly backups can be collected into a single script called "nightlyBackup". Storing the script in the recovery catalog instead of in an OS text file has the advantage that it is accessible to any database administrator- using Recovery Manager, regardless of which machine Recovery Manager is executed upon.

Creating and Replacing Scripts

The create or replace commands either create or replace a stored script and store it in the recovery catalog for future reference. The script is not executed immediately. The execute script command must be used to execute the stored script. The replace script command will also create a script if one doesn't already exist.

Deleting Scripts

Use the delete script command to delete a stored script from the recovery catalog.

Printing Scripts

Use the print script command to print a stored script to the Recovery Manager log file.

Configuring the Snapshot Control File Location

When Recovery Manager needs to read a read-consistent version of the control file, it creates a temporary backup of the control file. By default, the location the name and location of the snapshot control file is port specific.

However, it is possible to choose the name and location this file is written to, by using the set snapshot controlfile name to command. Any subsequent snapshot control files created, will be created according to the name and location specified in the command.

For example:

set snapshot controlfile name to '/oracle/dba/prod/snap_prod.ctl';

It is also possible to set the snapshot control file name to a raw device. This is important for OPS databaases where more than one instance in the cluster will use Recovery Manager; this is because server processes on each node must be able to create a snapshot control file with the same name and location.

For example:

set snapshot controlfile name to '/dev/vgd_1_0/rlvt5';

See Also: Oracle8 Parallel Server Concepts & Administration.

Backing Up Files

When backing up, the target database must be started and mounted. The control file must be current--not a backup control file.

You must give each backup piece a unique name using the format operand. Several substitution variables are available to aid in generating unique names. You can specify the format operand in the backup command, in the backup_specification level, or in the allocate channel command.

You can also limit the number of files to place into a single backup set. Generally, for datafile or datafile copy backups, you should group multiple datafiles into a single backup set to the extent necessary to keep an output tape device streaming, or to prevent the backup from consuming too much bandwidth from a particular datafile. The fewer files there are in a backup set, the faster one of them can be restored, since there is less data belonging to other datafiles that must be skipped. For archivelog backup sets, it is generally advisable to group logs from the same time period into a backup set because it is likely that they will need to be restored at the same time.

I/O errors encountered when reading files or writing to the backup pieces cause jobs to be aborted. The backup pieces that were being written at the time of the error will need to be re-written from their beginning. Any backup sets that were successfully written prior to the abort are retained.

Datafile Backup Sets

If the database is in ARCHIVELOG mode, then the target database can be open or closed. It is not necessary for the database to be closed cleanly. If the database is in NOARCHIVELOG mode, then it must be closed cleanly prior to taking a backup.

Note: If the database is in ARCHIVELOG mode, it is not necessary to cleanly shutdown the database for a cold backup. However, Oracle recommends you do, so that the backup is consistent.

You can also back up offline or read-only tablespaces.

Corrupt datafile blocks are identified by the server process as corrupt and written out to the backup. Oracle records the address of the corrupt block and the type of corruption in the control file. You can access these control file records in V$BACKUP_CORRUPTION. You can specify the maximum number of corruptions allowed in a datafile being backed up, using set maxcorrupt.

set maxcorrupt This sets a limit on the number of previously undetected block corruptions that will be allowed in a specified datafile or list of datafiles. If a backup or copy command detect more than this number of corruptions, then the command is aborted. The default limit is zero, meaning no corrupt blocks will be tolerated.

Performing Backups

Use the backup command to create one or more backup sets. Each resulting backup set contains one or more datafiles, datafile copies, or archivelogs from the target database. You can also place a backup of the control file into a datafile backup set. A file cannot be split across different backup sets. Archivelogs and datafiles cannot be mixed into a single backup set.

The number of backup sets produced during a backup depends on the number of backup_specifications in the command, the number of files specified or implied in each backup_object_list, and the value of the FILESPERSET limit. Each backup_specification produces at least one backup set. If the number of files specified or implied in its backup_object_list exceeds the FILESPERSET limit, then the backup_specification will produce multiple backup sets. If no limit is specified, then each backup_specification produces exactly one backup set.

If multiple backup sets are to be created and multiple channels are allocated, then Recovery Manager automatically parallelizes its operation and writes multiple backup sets in parallel. A single backup set cannot be striped across multiple channels. Recovery Manager automatically assigns a backup set to a device. It is possible to specify that all backup sets for a backup_specification be written to a specific channel.

Types of Recovery Manager Backups

The backup_type applies to all backup_specifications in the backup_specification_list. The following two backup types are available:

full This is the default if neither full nor incremental is specified. A full backup copies all blocks into the backup set, skipping only datafile blocks that have never been used. No blocks are skipped when backing up archivelogs or control files.

A full backup has no effect on subsequent incremental backups, and is not considered to be part of the incremental backup strategy.

incremental An incremental backup at a level greater than 0 copies only those blocks that have changed since the last incremental backup. An incremental backup at level 0 is identical in content to a full backup, but the level 0 backup is considered to be part of the incremental strategy.

Certain checks are performed when attempting to create an incremental backup at a level greater than zero. These checks ensure that the incremental backup would be usable by a subsequent recover command. Among the checks performed are:

Multiple levels of incremental backup are supported. A level N incremental backup will copy only those blocks that have changed since the most recent incremental backup at level N or less.

If incremental is specified, then all backup_object_lists in the command must specify one of the following: datafile, datafilecopy, tablespace, or database. Incremental backups of control files, archivelogs or backup sets are not supported.

Backup Command Operand List

You can specify a number of operands that apply to the entire BACKUP command. Some of these operands may also be specified at the backup_specification level.

tag A backup set can be given a user-specified identifier called a tag. A tag is a character string that is not a reserved word, typically with a meaningful name like "monday_evening_backup" or "weekly_full_backup". Tags must be 30 characters or less.

The syntax allows specification of the tag at the backup_command level or the backup_specification level. If specified at the command level, then all backup sets created by this command are given this tag. If specified at the backup_specification level, then backup sets created as a result of different backup specifications can have different tags. If specified at both levels, then the tag in the backup_specification takes precedence.

cumulative Causes an incremental backup to re-copy all the blocks that the previous backup at the same level copied, in addition to those blocks that have changed in the interim.

nochecksum This suppresses block checksums. Unless this option is specified, a checksum is computed for each block and stored in the backup. The checksum is verified when restoring from the backup and also written to the datafile when restored.

If the database is already maintaining block checksums, then this flag has no effect. The checksum is always verified and stored in the backup in this case.

filesperset This specifies the maximum number of files to place in one backup set. If the number of files specified or implied by the backup specification is greater than filesperset, then the backup specification will cause multiple backup sets to be created.

Backup Specification List

A backup_specification_list contains a list of one or more backup_specifications. A backup_specification minimally contains a list of objects to backup and a format operand to specify a filename template for the backup pieces.

Each backup_specification creates one or more backup sets. A backup_specification will cause multiple backup sets to be created if the number of datafiles specified in or implied by its backup_object_list exceeds the filesperset limit.

Backup Object List

Each backup_specification contains exactly one backup_object_list. The backup_object_list specifies which objects to backup.

database Indicates all datafiles in addition to the control file are backed-up.

tablespace This specifies a list of one or more tablespaces to backup. All datafiles that are currently part of the tablespaces will be backed up. Any number of tablespaces can be specified.

The keywords database and tablespace are provided merely as a convenience. These forms are translated internally into a list of datafiles.

datafile This specifies a list of one or more datafiles to backup. Datafiles can be specified either by filename or by datafile number. If a filename is specified, then it must be the name of a current datafile as listed in the recovery catalog (when a recovery catalog is used); otherwise, as listed in the control file.

If file1 (the first file of the system tablespace) is backed up, the control file is automatically included.

datafilecopy This specifies a list of one or more datafile copies to backup. The files can be specified either by filename or by tag. If specified by tag, and multiple datafile copies with this tag exist, then only the most current datafile copy of any particular datafile is backed up. archivelog This specifies a filename pattern, and/or a time-range or log sequence range used to choose which archivelogs to include in a backup. All archivelogs that meet the specification are included in the backup. If the range is specified by time, then the logs that were current at the begin and end times are included in the backup.

current control file This specifies that the current control file is backed up.

backup controlfile This specifies the filename of a backup control file to backup.

backupset This specifies the primary key of a backup set to backup. The backup set must be on disk.

Backup Operand List

This is a list of operands specifying attributes for the backup sets and backup pieces that are to be created for this backup_specification.

tag If specified, the backup sets are given the specified tag. The tag value is null otherwise.

parms This is a quoted string containing OS specific information. The string is passed to the OSD layer each time a backup piece is created.

format This specifies the file name to use for the backup pieces. The name must be enclosed in quotation marks. Any name that is legal as a sequential filename on the platform is allowed, provided that each backup piece gets a unique name. If backing up to disk, then any legal disk filename is allowed, provided it is unique.

The format operand may be specified in any of these places:

- the backup_specification

- the backup command

- the allocate channel command

If specified in more than one of these places, Recovery Manager will search for the format operand in the order shown above.

The following substitution variables are available in format strings to aid in generating unique filenames:

%p The backup piece number within the backup set. This value starts at 1 for each backup set and is incremented by 1 as each backup piece is created.

%s The backup set number. This is a counter in the control file that is incremented for each backup set. The counter value starts at 1 and is unique for the lifetime of the control file. If a backup control file is restored, then duplicate values may result. Also, CREATE CONTROLFILE initializes the counter back to 1.

%d The database name.

%n The padded database name.

%t The backup set stamp. This is a 4-byte value derived as the number of seconds since a fixed reference date/time. The combination of %s and %t can be used to form a unique name for the backup set.

%u An 8-character name composed of compressed representations of the backup set number and the time the backup set was created.

include current

control file This operand causes a snapshot of the current control file to be created, and to be placed into each backup set produced by this backup_specification.

filesperset This specifies the maximum number of datafiles to place in one backup set. If the number of datafiles specified or implied by the backup specification is greater than filesperset, then the backup specification will cause multiple backup sets to be created.

channel The name of a channel to use when creating the backup sets for this backup_specification. If this operand is not specified, then Recovery Manager will dynamically assign the backup sets for this backup_specification to any available channels during job execution.

delete input This operand causes the input files to be deleted upon successful creation of the backup set. This may be specified only when backing up archived logs or datafile copies. It is equivalent to issuing a change ... delete command for all of the input files.

Backing Up: Scenario

Let's assume there is a database called FOO that a database administrator wants to backup. The administrator has 3 tape drives available for the backup, and the database has 26 datafiles in it. The administrator wants to multiplex the backup, placing 4 files into each backup set, so chooses the number 4 because it is sufficient to keep the tape drive streaming. The administrator is not concerned about how datafiles are grouped into backup sets.

The administrator issues the following commands:

create script foo_full {
allocate channel t1 type `SBT_TAPE';
allocate channel t2 type `SBT_TAPE';
allocate channel t3 type `SBT_TAPE';
backup full filesperset 4
	(database format `FOO.FULL.%n.%s.%p');
run {
execute script foo_full;
}

This backup script will back up the whole database, including all datafiles and the control file into the backup. Since there are 27 files to be backed up (26 datafiles and a control file) and a maximum of 4 files per backup set, 7 backup sets will be created. The backup piece filenames will have the following format: FOO.FULL.database_name.x.y. Assuming no backup sets have been recorded in the recovery catalog prior to this job, then x will range from 1 through 7. y will start at 1 for each backup set and will increment as backup pieces are created.

Copying Datafiles

In many cases, copying datafiles can be more beneficial than backing them up, because when you copy files, the output is suitable for use without any additional processing. In contrast, a backup set must be processed by a restore command before it is usable. So, you can perform media recovery on a datafile copy, but not directly on a backup set, even if it contains only one datafile and is composed of only a single backup piece.

Use the copy command when you wish to create a copy of a file. The output file is always written to disk.

The following types of files can be copied:

Copy Command Specifiers

The copy command has one or more copy_specifiers, each of which specify one input file and one output file. At least one allocate channel command specifying type disk must precede a copy command.

If the copy command contains multiple copy_specifiers and multiple channels are allocated, then it is executed in parallel, with the degree of parallelism determined by the number of allocate channel commands. Following are descriptions of the copy command specifiers:

datafile This makes a copy of a current datafile. The datafile may be specified either by filename or filenumber. If the filename is used, then the filename must be the name of a datafile listed in the control file.

datafilecopy This makes a copy of an existing datafile copy. The existing copy may have been created by either a previous copy command or by some external OS facility. The input file can be specified by filename or tag. The filename must not be the name of a current datafile listed in the control file.

archivelog This makes a copy of an archivelog. The archive log may have been created by the Oracle log archiving process or by a previous copy command. You must specify the archivelog by filename.

current control file This makes a copy of the current control file.

backup control file This makes a copy of an existing backup control file. You can specify the control file either by filename or by tag.

Optionally, you can supply the following keywords to the copy command:

tag When you specify this option, the output file is assigned the specified tag.

level 0 When you specify this option, the datafile copy is included in the incremental backup strategy, and thus can serve as a basis for subsequent incremental backup sets. If you do not specify this option, the datafile copy has no impact on the incremental backup strategy.

Restoring Files

With Recovery Manager you can restore datafiles from backup sets or from copies on disk. The restore may be directed at either the current datafile location (overlaying the file currently there) or to a new location (by using the set newname command). If datafiles are restored to a new location, then they are considered to be datafile copies and are recorded as such in the control file and in the recovery catalog.

It is also possible to restore backup sets containing archivelogs. This is not normally necessary because Recovery Manager performs this automatically as needed during recovery. However, you can improve the recovery performance by pre-restoring archivelog backup sets that will be needed during the recovery.

Database Point-In-Time Recovery

An easy way of specifying the time to restore and recover to, is by using the set until command. This command affects any subsequent restore, switch and recover commands which are in the same run command:

set until This specifies a point in time for a subsequent restore or recover command. The point in time may be specified in one of the following ways:

The set until command takes the following keywords:

If the time keyword is specified then string must be a formatted according to the NLS date format specification currently in effect. This format is specified by the NLS_DATE_FORMAT environment variable on most platforms.

File Selection

Recovery Manager uses the recovery catalog (or target database control file if no recovery catalog is available) to select the best available backup sets or copies for use in the restore. Preference is given to copies rather than backup sets, and when multiple choices are available, the most current backup sets or copies are used, taking into account the until_clause if specified.

All specifications (from_tag, from_type, and until_clause) must be satisfied before a backup set or file copy is selected for restoration. Restore also considers the device types of the allocated channels when performing automatic selection. If no available backup or copy in the recovery catalog satisfies all the specified criteria, then Recovery Manager returns an error during compilation of the restore job. If the file cannot be restored because no backup sets or datafile copies reside on media compatible with the device types allocated in the job, then cancel the job. Then you can create a new job specifying channel allocation for devices that are compatible with the existing backup sets or datafile copies.

Restore Destination for Datafiles

By default, the restore command restores datafiles to their current location as specified in the recovery catalog (for example, the current datafiles are overlaid). If this is not desired, then issue set newname prior to restoring. In this case, the restored datafiles are considered datafile copies, and you must perform a switch to make them the current datafiles. The specified filename is created or overwritten if it already exists.

set newname This sets the default name for all subsequent restore or switch commands that affect the specified datafile. If this command is not used prior to a datafile restore, then Recovery Manager will restore the file to it's default location, as explained above.

Restore Destination for Control Files

You must specify a destination name when restoring a control file. The specified filename is created or overwritten if it already exists.

Replicating Control Files

You can use the replicate command to copy a control file to multiple destinations. You specify the input control file by name, and the output destination files in the control_files initialization parameter of the target database.

You can use the replicate command following a restore command, which has restored the control file, to prepare the database for mounting. It is equivalent to multiple copy controlfile commands. At least one allocate channel command specifying type disk must precede a replicate command.

Restore Destination for Archived Logs

Archived logs are restored to files whose names are constructed using the LOG_ARCHIVE_DEST and LOG_ARCHIVE_FORMAT initialization parameters of the target database. These parameters are combined in a port-specific fashion to derive the name of the restored archived log file. You can override LOG_ARCHIVE_DEST by specifying archivelog destination prior to restoring by using a set archivelog destination to command. The restored archived logs are created or overwritten if they already exist.

Using set archivelog destination, it is possible to manually stage many archived logs to many different locations while a database restore is occurring. Recovery Manager knows where to find the newly restored archive logs; it does not require them to be in the LOG_ARCHIVE_DEST for recovery to find them.

set archivelog

destination This overrides the log_archive_dest initialization parameter in the target database when forming names for restored archive logs during subsequent restore and recover commands.

For example, if you specify a different destination than the one in the init.ora LOG_ARCHIVE_DEST parameter and restore archivelog backups, subsequent restore and recovery operations will detect this new location and will not look for the files in LOG_ARCHIVE_DEST.

Guidelines for Restoring Datafiles

A restore restores full datafile backup sets, incremental level 0 backups or datafile copies. Incremental backups at levels greater than 0 are not restored via the restore command. Instead, you would perform a recovery to apply an incremental backup to a level 0 backup. You typically restore when a media failure has damaged the current copy of a datafile. You also restore prior to performing a point-in-time recovery.

If you issue set newname commands to restore datafiles to a new location, with the intention of performing a recovery afterwards, then you must perform a switch after restoring but before recovering to make the restored datafiles the current datafiles. A to_specifier clause is required when restoring the control file: there is no default location to which the control file is restored.

If you do not specify set newname when restoring datafiles, then either the database must be closed, or the datafiles must be off-line. If the entire database is to be restored, then it must be closed.

If the target database is mounted, then its control file will be updated with any applicable datafile copy and archived log records to describe the restored files.

At least one channel allocation must precede a restore. If you use the from copy operand, then the allocated channels should be of type disk. If using the from backup operand, then the appropriate type of sequential I/O devices must be allocated for the backup sets that will need restoration. If the appropriate type of device is not allocated, then you may not be able to find a candidate backup set or copy for restoration, and the restore fails.

Files within a single restore are restored in parallel if multiple channels are allocated, with the degree of parallelism controlled by the number of allocated channels. You can restore files in separate restore_specifications from the same backup set if the best candidates for restoration are on the same backup set and there are no conflicting PARM or CHANNEL operands on either of the respective restore_specifications.

Restore Command Operand List

The following operands apply to the restore command. Some of these operands can also be specified at the restore_specification level.

from backupset

/datafilecopy This specifies whether a restore should restore from file copies on disk or from backup sets. If this operand is not specified, then the restore chooses the most recent backup set or file copy. "Most recent" is the file copy or backup set that needs the least media recovery.

until In the absence of any other criteria, Recovery Manager will select the most current file copy or backup set to restore. If this is not desired, then an until_clause may be specified to limit the selection to those backup sets or file copies that would be suitable for performing a point-in-time recovery to a specified time.

tag By default, a restore chooses the most recent backup set or file copy available. This automatic selection can be overridden by specifying a from_tag. The from_tag restricts the automatic selection to backup sets or file copies that have a specified tag. If multiple backup sets or file copies are available with a matching tag, then the most recent one is selected.

channel The name of a channel to use for this restore. If no channel is specified, then restore will use any available channel which is allocated with the correct device type to restore the required files.

parms This is a quoted string containing operating system specific information. The string is passed to the OSD layer each time a backup piece is restored.

Restore Specification List

A restore_specification_list consists of one or more restore_specifications. Each restore_specification contains a list of objects to restore and, optionally, restore options that will override the options from the restore_command_operand_list.

Restore Specification

Each restore_specification contains exactly one restore_object_list. The restore operates against a list of restore_objects.

database All datafiles in the database will be restored. Note that, unlike a backup, this does not also include the control file. You can use an optional SKIP argument to skip restoring certain tablespaces. This is useful for avoiding restoration of tablespaces containing only temporary data.

tablespace All datafiles in the specified tablespaces will be restored.

datafile The specified datafiles will be restored.

controlfile The control file will be restored to the specified location.

archivelog The specified archivelogs will be restored.

The tablespace and database forms of restore_object are provided simply for convenience. They are translated into the corresponding list of datafile numbers.

It is a mistake to specify a datafile more than once in one restore job. For example, the following is considered illegal since datafile 1 is specified both explicitly and implied by the system tablespace:

restore (tablespace system) (datafile 1);

Switching Datafiles

When you switch datafiles, you are converting a datafile copy into a current datafile. By "current datafile" we mean the file that the control file points to (for example, the filename of the datafile copy becomes the new filename of the datafile as listed in the control file). Media recovery will be required for the datafile.

You should switch datafiles when you want to have a datafile copy become the current version of a datafile. This is equivalent to using the ALTER DATABASE RENAME DATAFILE command. Note that this effectively causes the location of the current datafile to change. Also note that switching "consumes" the copy. The corresponding records in the recovery catalog and the control file are deleted.

The datafile that is the target of the switch can be specified either by filename or by filenumber. You can specify the datafile copy to use either by filename or by a tag. If the tag is ambiguous, then the most current copy is used (the one that requires the least media recovery).

If you do not specify the target of the switch, then the filename specified in a prior set newname for this file number is used as the switch target. If you specify switch datafile all, then all datafiles for which a set newname has been issued in this job are switched to their new name.

Recovering Datafiles

You can use the Recovery Manager recover command to perform media recovery and apply incremental backups. Only current datafiles may be recovered or have incremental backups applied to them. Archivelog backup sets are restored as needed to perform the media recovery. By default, the logs are restored to the current log archive destination as specified in the init.ora file. An operand is provided for specifying a different location.

If Recovery Manager has a choice between applying an incremental backup or applying redo, then it always chooses to use the incremental backup. If over-lapping levels of incremental backup are available, then the lowest level of incremental backup (the one covering the longest period of time) is chosen automatically.

Guidelines for Recovering Datafiles

If possible, the recovery catalog should be made available to perform the recovery. If it is not available, then Recovery Manager uses information from the target database control file to perform the recovery if possible. Note that if control file recovery is required, then the recovery catalog must be available. Recovery Manager cannot operate when neither the recovery catalog nor the target database controlfile are available.

At least one allocate channel command must precede the recover command unless it is known that no archivelog or incremental datafile backup sets will need restoration. Furthermore, the appropriate type of device(s) must be allocated for the backup sets that will need restoration. If the appropriate type of device is not available, then the recover command will fail. The restores of datafile incremental backup sets are performed in parallel if multiple channels are allocated, with the degree of parallelism controlled by the number of allocate channel commands.

Database Point-In-Time Recovery

An easy way of specifying the time to is to use set until. This command affects any subsequent restore, switch and recover commands in the same run command. If a set until command is specified after a restore and before a recover, you may not be able to recover the database to the point in time required, as the files restored may already have timestamps more recent than that time; for this reason, the set until command is usually specified before the restore or switch command.

set until This specifies a point in time for a subsequent restore or recover command. The point in time may be specified in one of the following ways:

The set until command takes the following keywords:

If the time keyword is specified then string must be a formatted according to the NLS date format specification currently in effect. This format is specified by the NLS_DATE_FORMAT environment variable on most platforms.

Recovery Commands

There are three forms of Recovery Manager recover commands:

For datafile and tablespace recovery, the target database must be started and mounted. If it is open, then the datafile(s) or tablespace(s) to be recovered must be offline.

For database recovery, the database must be started but not open. If possible, the target database should be mounted. If the target database is not mounted, then Recovery Manager uses the values of the db_name and db_domain init.ora parameters to determine which target database it is operating against. If the db_name parameter is not specified in the target database init.ora file, then the recover command will fail. If there are multiple target databases with the same name and domain in the recovery catalog, again, the recover command will fail.

Datafile Recovery

Perform this form of recovery when a media failure has damaged one or more datafiles.

Tablespace Recovery

Perform this form of recovery when a media failure has damaged all datafiles for a tablespace, or when a tablespace is to be recovered to a previous point-in-time.

Performing tablespace recovery is also an easy way of naming the files that are to be recovered. Any files not requiring recovery are simply ignored.

Database Recovery

Perform database recovery under the following circumstances:

Recover Command Object List

datafile This specifies a list of one or more datafiles to recover. Datafiles may be specified by filename or by filenumber. The name must be the current name of the datafile as known in the recovery catalog. If the datafile has been renamed in the control file since the last time it was backed up or the last time a resync catalog was done, then the old name of the datafile must be used.

tablespace This specifies a list of one or more tablespaces to recover.

database This specifies that the entire database is to be recovered. You can specify an optional until_clause that causes the recovery to stop when the specified until condition has been reached.

An optional skip_clause may also be specified. The skip_clause lists tablespaces that should not be recovered. This is useful for avoiding recovery of tablespaces containing only temporary data, or for postponing recovery of some tablespaces until a later time.

skip causes Recovery Manager to take offline the datafiles belonging to the specified tablespaces before starting media recovery. These files are left offline after the media recovery is complete. If an incomplete recovery is being performed, then skip is not allowed. Instead, you must use skip forever, with the intention of dropping the skipped tablespaces after opening the database with the RESETLOGS option.

skip forever causes Recovery Manager to take the datafiles offline using the drop option. Only use skip forever when the specified tablespaces will be dropped after opening the database.

Monitoring Backups and Restores

There are a number of ways to identify what a server process performing a backup, restore or copy is doing. This section discusses two options.

Connecting a Session to Channels

To identify which server processes correspond to which Recovery Manager channels, use set command id and query the V$SESSION.CLIENT_INFO column.

set command id This enters the specified string into the V$SESSION.CLIENT_INFO column of all channels. This can be used to identify which Oracle server processes correspond to which channels.

The V$SESSION.CLIENT_INFO column will contain information for each Recovery Manager server process, in one of the following formats:

This form appears for the first connection to the target database established by Recovery Manager.
This form appears for all allocated channels.

Example: Using set command id

run {
  set command id to 'rman';
  allocate channel t1 type 'SBT_TAPE';
  allocate channel t2 type 'SBT_TAPE';
  backup 
    incremental level 0
    format 'df_%t_%s_%p'
    filesperset 5
    (tablespace data_1);

sql 'alter system archive log all';

}

Monitoring Progress

It is possible to monitor the progress of backups, copies, and restores by querying the view V$SESSION_LONGOPS.

Each server process performing a backup, restore or copy reports its progress compared to the total amount of work to do for that particular part of the restore.

For example, if a restore was being performed using two channels, and each channel had two backup sets to restore (a total of 4 sets), each server process would update report it's progress through a single set. When that set was completely restored, it would then start reporting progress on the next set to restore.

The information can be queried using the following SQL statement:

select sid, serial#, context, sofar, totalwork
        round(sofar/totalwork*100,2) "% Complete",
  from v$session_longops
 where compnam = 'dbms_backup_restore';



Prev

Next
Oracle
Copyright © 1997 Oracle Corporation.

All Rights Reserved.

Library

Product

Contents

Index