Release 8.0
A58396-01
 Library |
 Product |
 Contents |
 Index |
| Oracle8 Backup and Recovery Guide Release 8.0 A58396-01 |
|
This chapter describes how to use Recovery Manager to manage backups, restores and recovery of your database, and includes the following topics:
Recovery Manager can operate with or without a recovery catalog. If you wish to use a recovery catalog, you must install it before using Recovery Manager.
create user rman identified by rman temporary tablespace temp default tablespace rcvcat quota unlimited on rcvcat; grant recovery_catalog_owner to rman;
You can now use Recovery Manager.
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';
For an Oracle7 backup to be usable for recovery in an Oracle8 database, it must have been part of a tablespace that 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".
This section describes how to maintain and manipulate the recovery catalog, and includes the following topics:
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 userid. Then, the database with a duplicate database identifier can be registered into the newly created recovery catalog in the new schema.
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.
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 resynchronzie. 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.
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:
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.
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.
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.
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.
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 in 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, which specifies 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 that 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.
If a cataloged file is deleted through some means other than Recovery Manager, or is otherwise lost or damaged, then you should delete the catalog record.
If the file is on disk issue the following statements:
change datafilecopy <primary_key> delete; change archivelog <primary key> delete;
If the file is stored by a Media Manager issue the following statements:
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.
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 following change...validate statements:
change datafilecopy <primary_key> validate; change archivelog all validate;
Often it is useful to make Recovery Manager aware of the existence of file copies that are created via means other than Recovery Manager.
You can use the catalog command to add information about a datafile copy, archivelog, or controlfile copy to the recovery catalog and control file.
You can also use the catalog command to catalog a datafile copy as a level 0 backup, thus enabling you to perform an incremental backup later, using the datafile copy as the base of the incremental.
Oracle 8.x continues to support the ALTER TABLESPACE BEGIN/END BACKUP command, which allows open database operating system backups. 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 Manager 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 that were created from version 7.x or earlier can be cataloged if the file belongs to a tablespace that was offline normal or read-only when the database was migrated to Oracle8.
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 you have two options for partially re-creating its contents:
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.
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.
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.
Following are descriptions of allocate channel operands:
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.
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.
This port-specific string specifies parameters regarding the device to allocate. Do not use this operand if you've specified type disk.
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.
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.
The set limit channel commands specify limits that apply to any backup or copy command that executes using this device.
Following are descriptions of set limit channel operands:
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 online performance.
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.
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 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.
You can use the report command to produce one of the following types of reports:
Where:
Specifies the datafiles to be reported on. The report can include the entire database (optionally skipping certain tablespaces), a list of tablespaces, or a list of datafiles.
Can be used to limit the backup sets that 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 residing 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.
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.
The following command lists all datafiles that cannot be completely recovered from the existing backups because redo may be missing:
report unrecoverable;
The report need backup command lists all datafiles that need a new backup. The report assumes that the most recent backup would be used in the event of a restore.
Following are descriptions of need_backup operands:
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.
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 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 that are offline and whose most recent backup contains all changes to the file will not be included.
2. Files that 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.
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;
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:
Following are descriptions of report_obsolete operands:
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.
Specifies that backups and copies that can never be used (because they belong to incarnations of the database that are not predecessors of the current incarnation), will be considered obsolete.
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:
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.
This specifies the tablespaces, datafiles, or archivelogs whose backup sets or copies are to be listed.
Backup sets or datafile copies of all files in the current database are listed. Optionally, tablespaces may be skipped by using the skip_clause.
A list of tablespace names. Backup sets or datafile copies that include at least one datafile from a specified tablespace are listed.
A list of datafile names or numbers. Backup sets or datafile copies that contain at least one of the specified datafiles are listed.
List qualifiers are specifications that can be used to limit the objects whose backup sets or copies are to be listed:
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.
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.
All files may be qualified with a time range. If from or until is specified, only copies or backups that completed within the specified time period will be listed. Either or both of these options may be specified.
The following command lists all known backups of datafile `?/dbs/foo.f':
list backupset of datafile "?/dbs/foo.f";
The following command lists all copies of datafiles in tablespace "system":
list copy of tablespace system;
A stored script is a named entity that you can assign any meaningful name. The execute script command is used to execute a stored script. 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 perform nightly backups can be collected into a single script called "nightlybackup". Storing the script in the recovery catalog instead of in an operating system 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.
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 also creates a script if one doesn't already exist.
Use the delete script command to delete a stored script from the recovery catalog.
Use the print script command to print a stored script to the Recovery Manager log file.
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 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 databases 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 and Administration.
When backing up files, 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 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 the beginning. Any backup sets that were successfully written prior to the abort are retained.
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 shutdown cleanly 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 the V$BACKUP_CORRUPTION view. You can specify the maximum number of corruptions allowed in a datafile being backed up using 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.
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.
The backup_type applies to all backup_specifications in the backup_specification_list. The following two backup types are available:
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.
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:
- A level 0 backup set must exist, or level 0 datafile copies must exist for each datafile in the backup command. These must also not be marked unavailable.
- Sufficient incremental backups taken since the level 0 must exist and be available such that the incremental backup about to be created could be used.
Multiple levels of incremental backup are supported. A level N incremental backup copies 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.
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.
A backup set can be given a user-specified identifier called a tag, which 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.
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.
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.
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.
When you specify this parameter, Recovery Manager uses the minimum value of the calculated and specified value, which ensures that all devices are used. If you do not specify filesperset, the Recovery Manager uses the minimum value of the calculated value and 64, again ensuring that all channels are used, but limiting the number of files in a backup set.
Recovery Manager always attempts to create enough backup sets so that all allocated channels have work to do. An exception to this occurs when there are more channels than files to back up.
This enables users to specify a maximum size for a backup set. The limit is specified in units of 1K (1024 bytes). Thus, to limit a backup set to 3Mb, you would specify setsize=3000. Recovery Manager attempts to limit all backup sets to this size. This is a particularly useful option when you wish to make each backup set no larger than 1 tape.
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.
Each backup_specification contains exactly one backup_object_list. The backup_object_list specifies which objects to backup.
This specifies a list of one or more tablespaces to back up. 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.
This specifies a list of one or more datafiles to back up. 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.
This specifies a list of one or more datafile copies to back up. 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.
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.
This is a list of operands specifying attributes for the backup sets and backup pieces that are to be created for this backup_specification.
This is a quoted string containing OS-specific information. The string is passed to the OSD layer each time a backup piece is created.
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:
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.
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.
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.
An 8-character name composed of compressed representations of the backup set number and the time the backup set was created.
This operand creates a snapshot of the current control file and places it into each backup set produced by this backup_specification.
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 creates multiple backup sets.
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 dynamically assigns the backup sets for this backup_specification to any available channels during job execution.
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 script will back up the whole database, including all datafiles and the control file. 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, and y will start at 1 for each backup set and will increment as backup pieces are created.
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:
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:
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.
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 operating system 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.
This makes a copy of an archive log. The archive log may have been created by the Oracle log archiving process or by a previous copy command. You must specify the archive log by filename.
Optionally, you can supply the following keywords to the copy command:
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 datafile copies and are recorded as such in the control file and recovery catalog.
It is also possible to restore backup sets containing archive logs, which is not normally necessary because Recovery Manager performs this automatically as needed during recovery. However, you can improve the recovery performance by pre-restoring archive log backup sets that will be needed during the 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 that are in the same run command:
This specifies a point in time for a subsequent restore or recover command. The point in time may be specified using the following key words:
- time string
- logseq integer thread integer
- scn integer
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 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. You can then create a new job specifying channel allocation for devices that are compatible with the existing backup sets or datafile copies.
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.
You must specify a destination name when restoring a control file. The specified filename is created or overwritten if it already exists.
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. This is equivalent to multiple copy controlfile commands. At least one allocate channel command specifying type disk must precede a replicate command.
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 the archive log destination prior to restoring by using the 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.
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.
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 offline. 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.
The following operands apply to the restore command. Some of these operands can also be specified at the restore_specification level.
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.
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.
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.
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.
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.
Each restore_specification contains exactly one restore_object_list. The restore operates against a list of restore_objects.
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.
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);
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 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.
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. Archive log 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.
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 archive log 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.
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.
This specifies a point in time for a subsequent restore or recover command. The point in time may be specified using one of the following keywords:
- time string
- logseq integer thread integer
- scn integer
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.
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.
Perform this form of recovery when a media failure has damaged one or more datafiles.
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.
Perform database recovery under the following circumstances:
This specifies a list of one or more datafiles to recover. Datafiles may be specified by filename or 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 performed, then the old name of the datafile must be used.
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.
The skip clause causes Recovery Manager to take the datafiles belonging to the specified tablespaces offline 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.
The skip forever clause 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.
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.
To identify which server processes correspond to which Recovery Manager channels, use set command id and query the V$SESSION.CLIENT_INFO column.
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.
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';}
You can 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 its 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';
