Release 2 (8.1.6)
Part Number A76990-01
 Library |
 Product |
 Contents |
 Index |
| Oracle8i Recovery Manager User's Guide and Reference Release 2 (8.1.6) Part Number A76990-01 |
|
This chapter describes the basic concepts for the Oracle Recovery Manager (RMAN) utility, and includes the following topics:
Recovery Manager (RMAN) is an Oracle tool that allows you to back up, copy, restore, and recover datafiles, control files, and archived redo logs. It is included with the Oracle server and does not require separate installation. You can invoke RMAN as a command line utility from the operating system (O/S) prompt or use the GUI-based Enterprise Manager Backup Manager.
RMAN users server sessions to automate many of the backup and recovery tasks that were formerly performed manually. For example, instead of requiring you to locate appropriate backups for each datafile, copy them to the correct place using operating system commands, and choose which archived logs to apply, RMAN manages these tasks automatically.
When you start RMAN, the following events occur:
When you use RMAN to connect to the target database, RMAN allocates server sessions to perform the backup and recovery operations through a PL/SQL interface. RMAN physically stores its backups and copies on disk or, if you use media management software, on tape.
RMAN stores metadata about its backup and recovery operations in the recovery catalog, which is a centralized repository of information, or exclusively in the control file. Typically, the recovery catalog is stored in a separate database. If you do not use a recovery catalog, RMAN uses the control file as its repository of metadata.
RMAN automates important backup and recovery operations. For example, Recovery Manager is able to:
Getting to Know Oracle8i for a description of RMAN features that are new to this version of Oracle.
See Also:
RMAN is not:
RMAN provides commands that you can use to manage all aspects of backup and recovery operations.
This section contains the following topics:
Chapter 10, "Recovery Manager Command Syntax" for a complete account of RMAN commands and their syntax.
See Also:
The RMAN executable uses PL/SQL procedures to interpret commands. The PL/SQL packages perform two main functions:
The DBMS_RCVCAT and DBMS_RCVMAN packages are created by the create catalog command. RMAN uses DBMS_RCVCAT to maintain information in the recovery catalog and DBMS_RCVMAN to query the recovery catalog or control file.
The DBMS_BACKUP_RESTORE package is created by the dbmsbkrs.sql and prvtbkrs.plb scripts. This package is automatically installed in every Oracle database when the catproc.sql script is run. This package interfaces with the Oracle server and the operating system to provide the I/O services for backup and restore operations as directed by Recovery Manager.
|
See Also:
Oracle8i Supplied PL/SQL Packages Reference for more information about the DBMS_RCVCAT, DBMS_RCVMAN, and DBMS_BACKUP_RESTORE packages. |
Recovery Manager processes commands in two phases:
When you issue a Recovery Manager command such as backup, RMAN generates output alerting you to the various phases of command processing. Following is sample output for a backup tablespace command. Note the RMAN messages that begin RMAN-03xxx:
RMAN-03022: compiling command: backup RMAN-03023: executing command: backup RMAN-08008: channel ch1: starting full datafile backupset RMAN-08502: set_count=48 set_stamp=346765191 creation_time=15-OCT-98 RMAN-08010: channel ch1: specifying datafile(s) in backupset RMAN-08522: input datafile fno=00017 name=/oracle/dbs/tbs_14.f RMAN-08522: input datafile fno=00003 name=/oracle/dbs/tbs_11.f RMAN-08522: input datafile fno=00004 name=/oracle/dbs/tbs_12.f RMAN-08522: input datafile fno=00007 name=/oracle/dbs/tbs_13.f RMAN-08013: channel ch1: piece 1 created RMAN-08503: piece handle=/oracle/dbs/1gaamds7_1_1 comment=NONE RMAN-08525: backup set complete, elapsed time: 00:00:04 RMAN-03023: executing command: partial resync RMAN-08003: starting partial resync of recovery catalog RMAN-08005: partial resync complete RMAN-08031: released channel: ch1
During the compilation phase, RMAN performs two operations:
Most RMAN commands require you to identify what object the command should operate on. Name translation is the operation whereby RMAN translates what you specified in the command into a list of one or more entities that it really operates on. An entity in this sense can be a datafile, an archived redo log, a datafile copy, a control file copy, and so forth. For example, when you enter the command backup database, RMAN translates the keyword database into a list of all the datafiles that are in the database. Similarly, when you issue the following:
backup archivelog from time='xxx' until time='yyy'
RMAN translates the archivelogRecordSpecifier clause (the from ... until ... part of the command) into a list of archived redo logs.
RMAN performs its work by dynamically generating one or more PL/SQL programs and then executing them. In essence, RMAN compiles the commands you issue into PL/SQL programs. RMAN itself contains a copy of the PL/SQL engine, and executes the PL/SQL programs internally during the execution phase. These programs make remote procedure calls to the target database to perform backup, restore, and other necessary operations.
A single RMAN command can result in the generation of multiple PL/SQL programs. For example, a backup database command generates one PL/SQL program for each backup set that is to be created. Similarly, restore database generates one PL/SQL program for each backup set that needs to be restored.
During the execution phase, RMAN schedules and runs the PL/SQL programs it compiled during the compilation phase. RMAN assigns one PL/SQL program to each channel (that is, each server session) that you have allocated. The channels execute their PL/SQL program concurrently. For example, if you allocate three channels, then RMAN executes three of the PL/SQL programs at the same time.
RMAN is able to execute concurrent PL/SQL programs because the remote procedure calls (RPCs) that the programs make to the target database use the non-blocking User Program Interface (UPI) feature, thereby allowing RMAN to switch to another channel when one channel makes a non-blocking RPC call. RMAN uses an internal polling mechanism to detect when a non-blocking RPC call has completed. After it completes, RMAN resumes the PL/SQL program.
RMAN uses two basic types of commands: stand-alone commands and job commands. With the exception of the change, crosscheck, and delete commands, stand-alone commands are self-contained. In contrast, job commands must appear within the brackets of a run command.
After you connect to the target and optional recovery catalog, you will execute most of your RMAN commands within run. Following is a typical example of a run statement:
run { allocate channel c1 type 'sbt_tape'; restore database; recover database; }
| See Also: Chapter 10, "Recovery Manager Command Syntax" for an exhaustive description of RMAN syntax.: |
Unlike job commands, stand-alone commands do not appear as sub-commands within run. Following are some of the commands that can appear by themselves:
Some of these commands are not strictly stand-alone, however, because they must be preceded by an allocate channel for maintenance command.
Unlike stand-alone commands, job commands must appear within the brackets of a run command. Following are examples of job commands:
RMAN executes the job commands inside of a run command block sequentially. If any command within the block fails, RMAN ceases processing--no further commands within the block are executed. In effect, the run command defines a unit of command execution. When the last command within a run block completes, Oracle releases any server-side resources such as I/O buffers or I/O slave processes allocated within the block.
Most commands are either stand-alone commands or job commands. If you try to issue a job command outside of a run block or issue a stand-alone command inside a run block, RMAN issues a syntax error message. The following exceptions, however, can function as both stand-alone and job commands:
RMAN supports a number of command-line arguments that you can specify when you connect to RMAN. You can specify most of these arguments only on the command line; the exceptions are target and catalog, which you can specify either on the command line or through the connect command after RMAN has started. The connect command allows you to avoid putting passwords on the command line, since this practice sometimes poses a security problem.
RMAN uses a command language interpreter (CLI) that allows you to execute commands in interactive or batch mode. You can also specify the log option at the command line to write RMAN output into a log file.
To run RMAN commands interactively, start RMAN and then type commands into the command line interface. For example, you can start RMAN from the UNIX command shell and then execute interactive commands as follows:
% rman target sys/sys_pwd@prod1 catalog rman/rman@rcat RMAN> run { 2> allocate channel d1 type disk; 3> backup database; 4> }
You can type RMAN commands into a file, and then run the command file by specifying its name on the command line. The contents of the command file should be identical to commands entered at the command line.
When running in batch mode, RMAN reads input from a command file and writes output messages to a log file (if specified). RMAN parses the command file in its entirety before compiling or executing any commands. Batch mode is most suitable for performing regularly scheduled backups via an operating system job control facility.
In this example, the RMAN sample script from "Interactive Mode" has been placed into a command file called b_whole_10.rcv. You can run this file from the operating system command line and write the output into the log file rman_log.f as follows:
% rman target / catalog rman/rman@rcat @b_whole_l0.rcv log rman_log.f
A stored script is a set of RMAN commands that is enclosed in braces and stored in the recovery catalog. Maintaining a stored script allows you to plan, develop, and test a set of commands for backing up, restoring, or recovering the database. Stored scripts also minimize the potential for operator errors. Each stored script relates to only one database.
To create a stored script, either enter your script interactively into the RMAN command-line interface, or type the RMAN commands into a command file and run the command file.
Following is an example of a stored script:
replace script b_whole_l0 { # back up whole database and archived logs allocate channel d1 type disk; allocate channel d2 type disk; allocate channel d3 type disk; backup incremental level 0 tag b_whole_l0 filesperset 6 format '/dev/backup/prod1/df/df_t%t_s%s_p%p' (database); sql 'ALTER SYSTEM ARCHIVE LOG CURRENT'; backup filesperset 20 format '/dev/backup/prod1/al/al_t%t_s%s_p%p' (archivelog all delete input); } View stored scripts by querying the recovery catalog view RC_STORED_SCRIPT: SQL> SELECT * FROM rc_stored_script; DB_KEY DB_NAME SCRIPT_NAME ---------- ------- ------------------------------------------------------ 1 RMAN full_backup 1 RMAN incr_backup_0 1 RMAN incr_backup_1 1 RMAN incr_backup_2 1 RMAN log_backup
|
See Also:
"Storing Scripts in the Recovery Catalog" for more information on scripts. Also refer to the sample scripts stored in your |
You have two methods for terminating an RMAN job while it is executing:
kill command.
You can identify the session ID for an RMAN channel by looking in the RMAN log for the RMAN-08500 message, which is displayed for each allocated channel.
On various occasions it may be important for you to determine whether RMAN successfully executed your command. For example, if you are trying to write a script that performs an unattended backup using RMAN, you may want to know whether the backup was a success or failure.
The simplest way to determine whether RMAN encountered an error is to examine its return code. RMAN returns 0 to the operating system if no errors occurred, 1 otherwise. For example, if you are running UNIX and using the C shell, RMAN outputs the return code into a shell variable called $status.
The second easiest way is to search the Recovery Manager output for the string RMAN-00569, which is the message number for the error stack banner. All RMAN errors are preceded by this error message. If you do not see an RMAN-00569 message in the output, then there are no errors. Following is sample output for a syntax error:
RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =========================================================== RMAN-00558: error encountered while parsing input commands RMAN-01005: syntax error: found "}": expecting one of: "archivelog, backup, backupset, channel, comma, controlfilecopy, current, database, datafile, datafilecopy, delete, diskratio, filesperset, format, include, (, parms, pool, ;, skip, setsize, tablespace, tag" RMAN-01007: at line 1 column 58 file: standard input
|
See Also:
Chapter 9, "Recovery Manager Troubleshooting" to learn how to interpret RMAN error messages and troubleshoot problems. |
The RMAN repository is the collection of metadata about your target databases that RMAN uses to conduct its backup, recovery, and maintenance operations. You can either create a recovery catalog in which to store this information, or let RMAN store it exclusively in the target database control file. Although RMAN can conduct all major backup and recovery operations using just the control file, some RMAN commands function only when you use a recovery catalog.
The recovery catalog is maintained solely by RMAN; the target database never accesses it directly. RMAN propagates information about the database structure, archived redo logs, backup sets, and datafile copies into the recovery catalog from the target database's control file.
|
See Also:
Chapter 3, "Managing the Recovery Manager Repository" to learn how to manage the RMAN repository, and "Understanding Catalog-Only Command Restrictions" for a list of catalog-only commands. |
The recovery catalog is an optional repository of information about your target databases that RMAN uses and maintains. Conveniently, you do not need an additional database for storing the recovery catalog because you can put the recovery catalog in an existing database. RMAN uses the information in the recovery catalog, which is obtained from the control file, to determine how to execute requested backup and recovery operations.
This section contains the following topics:
The recovery catalog contains information about:
The recovery catalog obtains crucial RMAN metadata from the target database control file. Resynchronization of the recovery catalog ensures that the metadata that RMAN obtains from the control file stays current.
Resynchronizations can be full or partial. In a partial resynchronization, RMAN reads the current control file to update changed data, but does not resynchronize metadata about the database physical schema: datafiles, tablespaces, redo threads, rollback segments (only if the database is open), and online redo logs. In a full resynchronization, RMAN updates all changed records, including schema records.
When you issue certain commands in RMAN, the program automatically detects when it needs to perform a full or partial resynchronization and executes the operation as needed. You can also force a full resynchronization by issuing a resync catalog command.
It is a good idea to run RMAN once a day or so and issue the resync catalog command to ensure that the catalog stays current. Because the control file employs a circular reuse system, backup and copy records eventually get overwritten. Resynchronizing the catalog ensures that these records are stored in the catalog and so are not lost.
RMAN generates a snapshot control file, which is a temporary backup control file, each time it resynchronizes. This snapshot control file ensures that RMAN has a consistent view of the control file either when refreshing the recovery catalog or when querying the control file. Because the snapshot control file is intended for RMAN's short-term use, it is not registered in the recovery catalog. RMAN records the snapshot control file checkpoint in the recovery catalog to indicate how current the recovery catalog is.
The Oracle8i server ensures that only one RMAN session accesses a snapshot control file at any point in time. This safeguard is necessary to ensure that two RMAN sessions do not interfere with each other's use of the snapshot control file.
|
Note: You can specify the name and location of a snapshot control file. For instructions, see "Determining the Snapshot Control File Location". |
|
See Also:
"Resynchronizing the Recovery Catalog" to learn how to resynchronize the recovery catalog, and "resync" for resync catalog syntax. |
A single recovery catalog is able to store information for multiple target databases. Consequently, loss of the recovery catalog can be disastrous. You should back up the recovery catalog frequently.
If the recovery catalog is destroyed and no backups of it are available, then you can partially reconstruct the catalog from the current control file or control file backups. Nevertheless, you should always aim to have a valid, recent backup of your recovery catalog.
When you use RMAN with a recovery catalog, the RMAN environment is constituted by the following components:
Each of these components has a release number associated with it. For example, you can use an 8.1.6 RMAN executable with an 8.1.4 target database, and store the repository in an 8.1.5 recovery catalog database whose catalog tables were created in version 8.1.6.
The RMAN configure compatible command allows you to specify the compatibility level of the recovery catalog. For example, you can specify that a catalog can only function with an RMAN executable of release 8.1.5 or later. The compatibility setting determines the behavior of certain commands such as change ... delete and backup ... delete input.
|
See Also:
|
Because most information in the recovery catalog is also available in the target database's control file, RMAN supports an operational mode in which it uses the target database control file instead of a recovery catalog. This mode is especially appropriate for small databases where installation and administration of another database for the sole purpose of maintaining the recovery catalog is burdensome.
Oracle does not support the following features in this operational mode:
When you do not use a recovery catalog, the control file is the exclusive source of information about backups and copies as well as other relevant information. The control file contains two types of records: circular reuse records and non-circular reuse records.
Circular reuse records contain non-critical information that is eligible to be overwritten if the need arises. These records contain information that is continually generated by the database. Some examples of information circular reuse records include:
Circular re-use records are arranged in a logical ring. When all available record slots are full, Oracle either expands the control file to make room for a new records or overwrites the oldest record. The CONTROL_FILE_RECORD_KEEP_TIME initialization parameter specifies the minimum age in days of a record before it can be reused.
|
See Also:
"Monitoring the Overwriting of Control File Records" to learn how to manage Oracle's treatment of circular-reuse records. |
Non-circular reuse records contain critical information that does not change often and cannot be overwritten. Some examples of information in circular reuse records include:
To restore and recover your database without using a recovery catalog, Oracle recommends that you:
"Understanding Catalog-Only Command Restrictions" for a complete list of commands that are disabled unless you use a recovery catalog.
See Also:
To utilize tape storage for your database backups, RMAN requires a media manager. A media manager is a utility that loads, labels, and unloads sequential media such as tape drives for the purpose of backing up and recovering data.
|
Note: The Oracle kernel uses a Legato shared library that allows it to perform backups through the Legato Storage Manager, which is a media manager bundled with Oracle on certain operating systems. See the Legato Storage Manager Administrator's Guide for more information. |
Oracle publishes a media management API that third-party vendors can use to build software that works with RMAN. To use RMAN to make backups to sequential media such as tape, integrate media management software with your Oracle software. Note that Oracle does not need to connect to the media management library (MML) software when it backs up to disk.
|
Note: Because RMAN uses the same media management API as the Oracle7 Enterprise Backup Utility (EBU), RMAN is compatible with the same media managers as EBU. Check with your vendor to see whether your version of the media software is compatible with RMAN (see "Backup Solutions Program"). |
Some media management products can manage the entire data movement between Oracle datafiles and the backup devices. Such products may use technologies such as high-speed connections between storage and media subsystems, which can remove much of the backup load from the primary database server.
Figure 1-4 shows the architecture for a media manager integrated with Oracle.
The Oracle executable is the same used when a user connects to the database. The MML in the diagram above represents vendor-supplied media management software that can interface with Oracle. Oracle calls MML software routines to back up and restore datafiles to and from media controlled by the media manager.
The following Recovery Manager script performs a datafile backup to a tape drive controlled by a media manager:
run { # Allocating a channel of type 'sbt_tape' specifies a media management device allocate channel ch1 type 'sbt_tape'; backup datafile 10; }
When Recovery Manager executes this command, it sends the backup request to the Oracle server session performing the backup. The Oracle server session identifies the output channel as a media management device and requests the media manager to load a tape and write the output.
The media manager labels and keeps track of the tape and names of files on each tape. If your site owns an automated tape library with robotic arm, the media manager automatically loads and unloads the tapes required by Oracle; if not, the media manager requests an operator to load a specified tape into the drive.
The media manager handles restore as well as backup operations. When you restore a file, the following steps occur:
Sometimes tapes in the media management library become unavailable. RMAN can perform crosschecks to determine that backup pieces are still available; in this way, the RMAN repository stays synchronized with the media management catalog.
For example, you can issue a crosscheck backup command to check all backups on tape. If RMAN cannot find a particular backup, it changes its status to EXPIRED in the RMAN repository. Issue a list command or access the recovery catalog views to determine the status of backups and copies.
|
See Also:
|
Oracle has integrated proxy copy functionality into its media management API. Vendors can use this API to develop media management software that takes control of backup and restore operations. RMAN provides a list of files requiring backup or recovery to the media manager, which in turn makes all decisions regarding how and when to move the data.
For each file that you attempt to back up using the backup proxy command, RMAN queries the media manager to determine whether it can perform proxy copy. If the media manager cannot proxy copy the file, then RMAN uses conventional backup sets to perform the backup. An exception occurs when you use the proxy only option, which causes Oracle to issue an error message when it cannot proxy copy.
Oracle records a record of each proxy-copied file in the control file. RMAN uses this information to resynchronize the recovery catalog. Access the V$PROXY_DATAFILE and V$PROXY_ARCHIVEDLOG dynamic performance views to obtain the proxy copy information. Use the change ... proxy command to delete or change the status of a proxy backup.
|
See Also:
Oracle8i Reference for more information about V$PROXY_DATAFILE and V$PROXY_ARCHIVEDLOG, and "backup" for backup command syntax |
A new client program, sbttest, is a stand-alone test of the media management software that is linked with Oracle to perform backups to tape. Use it when Oracle is unable to create or restore backups using either the bundled Legato Storage Manager or another vendor's media management product. Only use the sbttest program at the direction of Oracle support.
The Oracle Backup Solutions Program (BSP) provides a range of media management products that are compliant with Oracle's Media Management Library (MML) specification. Software that is compliant with the MML interface enables an Oracle server session to issue commands to the media manager to back up or restore a file. The media manager responds to the command by loading, labeling, or unloading the requested tape.
One MML-compliant product is the Legato Storage Manager (LSM), which is available for several common platforms. Oracle includes LSM with software that it ships for these platforms. If your version of the Oracle software includes LSM, refer to the Legato Storage Manager Administrator's Guide to learn about its features. If your shipment includes other BSP media management products, then refer to your platform-specific documentation for information.
Several other products may be available for your platform from media management vendors. For a current list of available products, you can link to the BSP page from the Oracle Backup and Recovery website:
http://www.oracle.com/database/recovery
You can also contact your Oracle representative for a complete list.
If you wish to use a specific media management product, contact the media management vendor directly to determine whether it is a member of the Oracle BSP. Note that Oracle does not certify media vendors for compatibility with RMAN, so any questions about availability, version compatibility, and functionality should be directed to the media vendor, not Oracle.
Use RMAN's report and list commands to gain information about backups and image copies. RMAN obtains the information from the RMAN repository: either the control file or the recovery catalog.
The list command lists the contents of the RMAN repository, whereas the report command performs a more detailed analysis. RMAN writes the output from these commands to the screen or to a log file.
The list command queries the recovery catalog or control file and produces a record of its contents. Use it to list:
"Generating Lists" to learn how to generate lists of backups and image copies, and "list" for reference material on the list command.
See Also:
RMAN reports are intended to provide analysis of your backup and recovery situation. An RMAN report can answer questions such as:
Issue the report need backup and report unrecoverable commands regularly to ensure that the necessary backups are available to perform media recovery, as well as to ensure that you can perform media recovery within a reasonable amount of time.
The report command lists backup sets and datafile copies that can be deleted either because they are redundant or because they are unrecoverable. A datafile is considered unrecoverable if an unrecoverable operation has been performed against an object residing in the datafile subsequent to the last backup.
The report command allows you to list orphaned backups. Orphaned backups are backups that are unusable because they belong to incarnations of the database that are not direct ancestors of the current incarnation.
For example, see the incarnation scenario depicted in Figure 1-7:
Incarnation A of the database started at SCN 1. At SCN 10, assume that you performed a RESETLOGS operation and created incarnation B. At SCN 20, you performed another RESETLOGS operation on incarnation B and created a new incarnation C.
The following table explains which backups are orphans depending on which incarnation is current:
|
See Also:
"Generating Reports" to learn how to generate reports, and "report" for reference material on the report command. |
You must allocate a channel before you execute backup and recovery commands. Each allocated channel establishes a connection from RMAN to a target or auxiliary database (either a database created with the duplicate command or a temporary database used in TSPITR) instance by starting a server session on the instance. This server session performs the backup and recovery operations. Only one RMAN session communicates with the allocated server sessions.
The allocate channel command (executed within a run command) and allocate channel for maintenance command (executed at the RMAN prompt) specify the type of I/O device that the server session will use to perform the backup, restore, or maintenance operation. Each channel usually corresponds to one output device, unless your media management library is capable of hardware multiplexing.
|
See Also:
"allocate" for reference material on the allocate channel command, and "allocateForMaint" for reference material on the allocate channel for maintenance command. |
Use channel control commands to:
On some platforms, these commands specify the name or type of an I/O device to use. On other platforms, they specify which operating system access method or I/O driver to use. Not all platforms support the selection of I/O devices through this interface; on some platforms, I/O device selection is controlled through platform-specific mechanisms.
Whether the allocate channel command causes your media manager to allocate resources is vendor-specific. Some media managers allocate resources when you issue the command; others do not allocate resources until you open a file for reading or writing.
In version 8.1, the allocate channel command causes RMAN to contact the media manager whenever the type specified is other than disk. Depending on the media management software used, the media manager allocates resources at this time or waits until a backup file is opened for reading or writing. Note that in version 8.0, the allocate channel command does not cause RMAN to contact the media manager; RMAN does not call the media manager unless a backup, restore, or recover command is issued.
You must allocate a maintenance channel before issuing a change ... delete command, which calls the operating system to delete a file, or a change ... crosscheck command. A maintenance channel is useful only for a maintenance task; you cannot use it as an input or output channel for a backup or restore job. You can only allocate one maintenance channel at a time.
|
See Also:
"set" for reference material on the set command, and "allocateForMaint" for reference material on the allocate channel for maintenance command. |
You can allocate multiple channels, thus allowing a single RMAN command to read or write multiple backups or image copies in parallel. Thus, the number of channels that you allocate affects the degree of parallelism within a command. When backing up to tape you should allocate one channel for each physical device, but when backing up to disk you can allocate as many channels as necessary for maximum throughput.
Each allocate channel or allocate auxiliary channel command uses a separate connection to the target or auxiliary database. You can specify a different connect string for each channel to connect to different instances of the target database, which is useful in an Oracle Parallel Server (OPS) configuration for distributing the workload across different nodes.
RMAN internally handles parallelization of backup, copy, and restore commands. You only need to specify:
RMAN executes commands serially; that is, it completes the current command before starting the next one. Parallelism is exploited only within the context of a single command. Consequently, if you want 5 datafile copies, issue a single copy command specifying all 5 copies rather than 5 separate copy commands.
The following RMAN script uses serialization to create the file copies: 5 separate copy commands are used to back up the files. Only one channel is active at any one time.
run { allocate channel c1 type disk; allocate channel c2 type disk; allocate channel c3 type disk; allocate channel c4 type disk; allocate channel c5 type disk; copy datafile 22 to '/dev/prod/backup1/prod_tab5_1.dbf'; copy datafile 23 to '/dev/prod/backup1/prod_tab5_2.dbf'; copy datafile 24 to '/dev/prod/backup1/prod_tab5_3.dbf'; copy datafile 25 to '/dev/prod/backup1/prod_tab5_4.dbf'; copy datafile 26 to '/dev/prod/backup1/prod_tab6_1.dbf'; }
The following statement uses parallelization on the same example; one RMAN copy command copies 5 files, with 5 channels available. All 5 channels are concurrently active--each channel copies one file.
run { allocate channel c1 type disk; allocate channel c2 type disk; allocate channel c3 type disk; allocate channel c4 type disk; allocate channel c5 type disk; copy datafile 5 to '/dev/prod/backup1/prod_tab5_1.dbf', datafile 23 to '/dev/prod/backup1/prod_tab5_2.dbf', datafile 24 to '/dev/prod/backup1/prod_tab5_3.dbf', datafile 25 to '/dev/prod/backup1/prod_tab5_4.dbf', datafile 26 to '/dev/prod/backup1/prod_tab6_1.dbf'; }
|
See Also:
Oracle8i Parallel Server Documentation Set: Oracle8i Parallel Server Concepts; Oracle8i Parallel Server Setup and Configuration Guide; Oracle8i Parallel Server Administration, Deployment, and Performance for information about parallelization in an OPS configuration. |
When you execute the backup command, you create one or more backup sets. A backup set, which is a logical construction, contains one or more physical backup pieces. Backup pieces are operating system files that contain the backed up datafiles, control files, or archived redo logs. You cannot split a file across different backup sets or mix archived redo logs and datafiles into a single backup set.
A backup set is a complete set of backup pieces that constitute a full or incremental backup of the objects specified in the backup command. Backup sets are in an RMAN-specific format; image copies, in contrast, are available for use without additional processing.
When backing up files, the target database must be mounted or open. If the database is mounted and was not shut down abnormally prior to mounting, then RMAN produces a consistent backup. The control file must be current.
If the database is in ARCHIVELOG mode, then the target database can be open or closed; you do not need to close the database cleanly (although Oracle recommends you do so that the backup is consistent). If the database is in NOARCHIVELOG mode, then you must close it cleanly prior to taking a backup.
This section contains the following topics:
Chapter 5, "Making Backups and Copies with Recovery Manager" to learn how to make backups, and "backup" for information on the backup command.
See Also:
RMAN can create backup sets that are written to disk or tertiary storage. If you specify type disk, then you must back up to random-access disks. You can make a backup on any device that can store an Oracle datafile: in other words, if the statement CREATE TABLESPACE tablespace_name DATAFILE 'filename' works, then 'filename' is also a valid backup pathname.
Using a sequential output device or media management system that is available and supported by Oracle on your operating system, you can write backup sets to sequential output media such as magnetic tape. If you specify type 'sbt_tape', then you can back up to any media supported by the media management software.
Note that you cannot archive directly to tape, but RMAN does allow you to back up archived redo logs from disk to tape. If you specify the delete input option, RMAN deletes the file after backing it up. RMAN automatically stages the required archived logs from tape to disk during recovery.
|
Note: RMAN cannot delete obsolete backups automatically. To learn how to delete old backups manually, see "Deleting Backups and Copies and Updating Their Status in the RMAN Repository". |
RMAN performs compression on its backups, which means that the server session does not write datafile blocks that have never been used. Image copies of a datafile, however, always contain all datafile blocks.
Data blocks in the datafile are grouped into buffers. When RMAN encounters a used data block in a buffer, it writes only the used block to the backup set. When RMAN encounters four contiguous buffers of unused input blocks, it writes one compression block (of size DB_BLOCK_SIZE) to the backup set.
Use the DB_FILE_DIRECT_IO_COUNT initialization parameter to set the size of the buffer. For example, set the parameter to a value of 64K. In this case, RMAN writes one compression block for each 256K of contiguous unused input blocks in the input file.
You can either let RMAN determine a unique name for the backup piece or use the format parameter to specify a name. If you do not specify a filename, RMAN uses the %U substitution variable to guarantee a unique name. The backup command provides substitution variables that allow you to generate unique filenames.
|
See Also:
"backup" for reference material on the format parameter and the substitution variables of the backup command. |
Use the backupSpec clause to list what you want to back up as well as specify other useful options. The number and size of backup sets depends on:
The most important rules in the algorithm for backup set creation are:
The filesperset parameter limits the number of files that can go in a backup set. The default value of this parameter is calculated by RMAN as follows: RMAN compares the value 64 to the rounded-up ratio of number of files / number of channels, and sets filesperset to the lower value. For example, if you back up 70 files with one channel, RMAN divides 70/1, compares this value to 64, and sets filesperset to 64 because it is the lowest value.
The number of backup sets produced by RMAN is the rounded-up ratio of number of datafiles / filesperset. For example, if you back up 70 datafiles and filesperset is 64, then RMAN produces 2 backup sets.
RMAN tries to make backup sets roughly the same size as the ratio of total number of blocks / total number of sets. The total number of blocks in a backup is equal to the number of blocks in each file that is backed up. For example, if you back up 70 files that each contain 50 blocks, and the number of sets is 2, then RMAN attempts to make each backup set about 3500 / 2 = 1750 blocks.
Assume the following example in which RMAN backs up 8 files using 3 channels. Because filesperset is not specified, RMAN compares 64 to 3 (8/3 rounded up) and chooses the lesser value of 3. RMAN creates 3 backup sets and groups the files into the sets so that each set is approximately the same size:
List of Backup Sets Key Recid Stamp LV Set Stamp Set Count Completion Time ------- ---------- ---------- -- ---------- ---------- ---------------------- 1677 90 368815605 0 368815602 98 22-JUN-99 List of Backup Pieces Key Pc# Cp# Status Completion Time Piece Name ------- --- --- ----------- ---------------------- ------------------------ 1681 1 1 AVAILABLE 22-JUN-99 /vobs/oracle/dbs/32avnbfi_1_1 List of Datafiles Included File Name LV Type Ckp SCN Ckp Time ---- ------------------------------------- -- ---- ---------- ------------- 10 /vobs/oracle/dbs/tbs_31.f 0 Full 75989 22-JUN-99 19 /vobs/oracle/dbs/tbs_33.f 0 Full 75989 22-JUN-99 List of Backup Sets Key Recid Stamp LV Set Stamp Set Count Completion Time ------- ---------- ---------- -- ---------- ---------- ---------------------- 1678 91 368815605 0 368815602 97 22-JUN-99 List of Backup Pieces Key Pc# Cp# Status Completion Time Piece Name ------- --- --- ----------- ---------------------- ------------------------ 1682 1 1 AVAILABLE 22-JUN-99 /vobs/oracle/dbs/31avnbfi_1_1 List of Datafiles Included File Name LV Type Ckp SCN Ckp Time ---- ------------------------------------- -- ---- ---------- ------------- 9 /vobs/oracle/dbs/tbs_24.f 0 Full 75988 22-JUN-99 11 /vobs/oracle/dbs/tbs_32.f 0 Full 75988 22-JUN-99 18 /vobs/oracle/dbs/tbs_25.f 0 Full 75988 22-JUN-99 List of Backup Sets Key Recid Stamp LV Set Stamp Set Count Completion Time ------- ---------- ---------- -- ---------- ---------- ---------------------- 1679 92 368815605 0 368815601 96 22-JUN-99 List of Backup Pieces Key Pc# Cp# Status Completion Time Piece Name ------- --- --- ----------- ---------------------- ------------------------ 1683 1 1 AVAILABLE 22-JUN-99 /vobs/oracle/dbs/30avnbfh_1_1 List of Datafiles Included File Name LV Type Ckp SCN Ckp Time ---- ------------------------------------- -- ---- ---------- ------------- 5 /vobs/oracle/dbs/tbs_21.f 0 Full 75990 22-JUN-99 6 /vobs/oracle/dbs/tbs_22.f 0 Full 75990 22-JUN-99 8 /vobs/oracle/dbs/tbs_23.f 0 Full 75990 22-JUN-99
If you back up 8 datafiles using 3 channels and specify filesperset = 2, RMAN places no more than 2 datafiles in each backup set. Consequently, RMAN creates at least 8 / 2 = 4 backup sets: it may create more depending on the sizes of the datafiles as well as other factors.
List of Backup Sets Key Recid Stamp LV Set Stamp Set Count Completion Time ------- ---------- ---------- -- ---------- ---------- ---------------------- 1713 96 368815867 0 368815865 102 22-JUN-99 List of Backup Pieces Key Pc# Cp# Status Completion Time Piece Name ------- --- --- ----------- ---------------------- ------------------------ 1718 1 1 AVAILABLE 22-JUN-99 /vobs/oracle/dbs/36avnbnp_1_1 List of Datafiles Included File Name LV Type Ckp SCN Ckp Time ---- ------------------------------------- -- ---- ---------- ------------- 5 /vobs/oracle/dbs/tbs_21.f 0 Full 75996 22-JUN-99 8 /vobs/oracle/dbs/tbs_23.f 0 Full 75996 22-JUN-99 List of Backup Sets Key Recid Stamp LV Set Stamp Set Count Completion Time ------- ---------- ---------- -- ---------- ---------- ---------------------- 1714 97 368815867 0 368815865 103 22-JUN-99 List of Backup Pieces Key Pc# Cp# Status Completion Time Piece Name ------- --- --- ----------- ---------------------- ------------------------ 1719 1 1 AVAILABLE 22-JUN-99 /vobs/oracle/dbs/37avnbnp_1_1 List of Datafiles Included File Name LV Type Ckp SCN Ckp Time ---- ------------------------------------- -- ---- ---------- ------------- 6 /vobs/oracle/dbs/tbs_22.f 0 Full 75997 22-JUN-99 9 /vobs/oracle/dbs/tbs_24.f 0 Full 75997 22-JUN-99 List of Backup Sets Key Recid Stamp LV Set Stamp Set Count Completion Time ------- ---------- ---------- -- ---------- ---------- ---------------------- 1715 98 368815867 0 368815866 104 22-JUN-99 List of Backup Pieces Key Pc# Cp# Status Completion Time Piece Name ------- --- --- ----------- ---------------------- ------------------------ 1720 1 1 AVAILABLE 22-JUN-99 /vobs/oracle/dbs/38avnbnq_1_1 List of Datafiles Included File Name LV Type Ckp SCN Ckp Time ---- ------------------------------------- -- ---- ---------- ------------- 10 /vobs/oracle/dbs/tbs_31.f 0 Full 75998 22-JUN-99 18 /vobs/oracle/dbs/tbs_25.f 0 Full 75998 22-JUN-99 List of Backup Sets Key Recid Stamp LV Set Stamp Set Count Completion Time ------- ---------- ---------- -- ---------- ---------- ---------------------- 1716 99 368815870 0 368815869 105 22-JUN-99 List of Backup Pieces Key Pc# Cp# Status Completion Time Piece Name ------- --- --- ----------- ---------------------- ------------------------ 1721 1 1 AVAILABLE 22-JUN-99 /vobs/oracle/dbs/39avnbnt_1_1 List of Datafiles Included File Name LV Type Ckp SCN Ckp Time ---- ------------------------------------- -- ---- ---------- ------------- 11 /vobs/oracle/dbs/tbs_32.f 0 Full 75999 22-JUN-99 19 /vobs/oracle/dbs/tbs_33.f 0 Full 75999 22-JUN-99
For datafile or datafile copy backups, 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 the files that are contained in a backup set, the faster one of them can be restored, because there is less data belonging to other datafiles that must be skipped. For backup sets containing archived logs, group logs from the same time period into a backup set because they will probably need to be restored at the same time.
|
See Also:
"backup" to learn about the backupSpec clause, and Oracle8i Designing and Tuning for Performance to learn about RMAN buffer management. |
Each channel produces at least one backup set. To specify the maximum size of the backup set in bytes, use the setsize parameter in the backup command. By limiting the overall size of the backup set, the parameter indirectly limits the number of files in the set and can possibly force RMAN to create more than one backup set.
If you are writing to disk, use the setsize parameter of the backup command to restrict the total byte size of a backup set to the maximum file size supported by your media manager or operating system.
The following table compares the setsize parameter to the filesperset parameter:
Because filesperset has a default value, if you set setsize you must also account for the behavior of filesperset. When both parameters are in use:
Assume that you want to back up 50 datafiles, each containing 1000 blocks. To set a maximum backup set size for a database backup to 10Mb, you issue the following:
run { allocate channel c1 type 'sbt_tape'; allocate channel c2 type 'sbt_tape'; backup database setsize = 10000; }
Because you did not set filesperset, RMAN performs a calculation to obtain the default value. It compares 64 to 50 / 2 and sets filesperset = 25. RMAN then compares:
Consequently, RMAN attempts to make 5 backup sets, with each backup set containing no more than 25 files and totalling no more than 10Mb in size.
Note that if you set setsize to a value smaller than the size of the largest input file, you receive the RMAN-06183 error:
RMAN-06183: datafile or datafilecopy larger than SETSIZE: file# 1 /oracle/dbs/tbs_01.f
Each backup set contains at least one backup piece. If you do not restrict the backup piece size, Oracle generates a backup set containing only one file. To restrict the size of the physical files in a backup set, use the kbytes option of the set channel limit command for each allocated channel.
For example, you can restrict the backup piece size for a datafile backup to 9Mb as follows:
run { allocate channel c1 type disk; set limit channel c1 kbytes = 9000; backup datafile 1; }
A list backup command reveals that RMAN created 5 backup pieces rather than 1 backup piece to conform to the set channel limit size restriction:
List of Backup Sets Key Recid Stamp LV Set Stamp Set Count Completion Time ------- ---------- ---------- -- ---------- ---------- ---------------------- 295 9 377549368 0 377549334 9 30-SEP-99 List of Backup Pieces Key Pc# Cp# Status Completion Time Piece Name ------- --- --- ----------- ---------------------- ------------------------ 297 1 1 AVAILABLE 30-SEP-99 /oracle/dbs/09b81sgm_1_1 298 2 1 AVAILABLE 30-SEP-99 /oracle/dbs/09b81sgm_2_1 299 3 1 AVAILABLE 30-SEP-99 /oracle/dbs/09b81sgm_3_1 300 4 1 AVAILABLE 30-SEP-99 /oracle/dbs/09b81sgm_4_1 301 5 1 AVAILABLE 30-SEP-99 /oracle/dbs/09b81sgm_5_1 List of Datafiles Included File Name LV Type Ckp SCN Ckp Time ---- ------------------------------------- -- ---- ---------- ------------- 1 /oracle/dbs/tbs_01.f 0 Full 35562 30-SEP-99
Oracle takes the datafile blocks included in the same backup set and multiplexes them, which means that the data blocks from all of the datafiles in the backup set are interspersed with one another. As Figure 1-11 illustrates, RMAN can back up three datafiles into a backup set that contains only one backup piece; this backup piece is constituted by the intermingled block components of the three input files.
Use the filesperset parameter to control the number of datafiles that Oracle backs up concurrently to a backup set. Controlling concurrency is helpful when you want to keep a tape device streaming without saturating a single datafile with too many read requests, since these requests can subsequently degrade online performance. Limit the read rate by using the readrate option of the set limit channel command.
When multiplexing files, you can:
See Also:
RMAN provides an efficient way to produce multiple copies of an archived redo log or datafile backup set. Create up to four identical copies of a backup set by issuing the set duplex command.
You should not confuse multiplexing, which is combining multiple input files into a single backup set, with duplexing, which is the output of two or more identical backup sets. RMAN allows you to multiplex your input files and duplex the output.
|
See Also:
"Duplexing Backup Sets" to learn how to duplex backups, and "set_run_option" for reference material on the set duplex command. |
If you want to create multiple backup sets and allocate multiple channels, then RMAN automatically parallelizes its operation and writes multiple backup sets in parallel. The allocated server sessions divide up the work of backing up the specified files.
RMAN automatically assigns a backup set to a device. You can specify that Oracle should write all backup sets for a backupSpec to a specific channel using the channel parameter, as in the following example:
run { allocate channel ch1 type disk; allocate channel ch2 type disk; allocate channel ch3 type disk; backup (datafile 1,2,3 filesperset = 1 channel ch1) (datafilecopy '/oracle/copy/cf.f' filesperset = 2 channel ch2) (archivelog from logseq 100 until logseq 102 thread 1 filesperset = 3 channel ch3); }
Figure 1-13 show an example of parallelization in which channel 1 backs up datafiles, channel 2 backs up datafile copies, and channel 3 backs up archived redo logs.
|
See Also:
|
RMAN is equipped to handle the two primary types of backup errors: I/O errors and corrupt blocks. Any I/O errors that RMAN encounters when reading files or writing to the backup pieces cause the system to abort the jobs. RMAN needs to rewrite the backup sets that it was writing at the time of the error, but it retains any backup sets that it successfully wrote prior to the abort.
RMAN copies datafile blocks that are already identified as corrupt into the backup. If RMAN encounters datafile blocks that have not already been identified as corrupt, it writes them to the backup with a reformatted header indicating that the block has media corruption (assuming that set maxcorrupt is not equal to 0 for this datafile and the number of corruptions does not exceed the limit). In either case, Oracle records the address of the corrupt block and the type of corruption in the control file. Access these control file records through the V$BACKUP_CORRUPTION view.
Use the set maxcorrupt command to limit the number of previously undetected block corruptions that Oracle allows in a specified datafile or list of datafiles. If a backup or copy command detects more than this number of corruptions, then the command aborts. The default limit is zero, meaning that RMAN does not tolerate corrupt blocks.
|
See Also:
|
Recovery Manager allows you to control the type of backups you produce. RMAN backups can be classified in these ways:
A full backup reads the entire file and copies all blocks into the backup set, skipping only datafile blocks that have never been used. The server session does not skip blocks when backing up archived redo logs or control files.
A full backup has no effect on subsequent incremental backups, which is why it is not considered part of the incremental strategy. In other words, a full backup does not affect which blocks are included in subsequent incremental backups.
Oracle allows you to create and restore full backups of the following:
Note that backup sets containing archived redo logs are always full backups.
An incremental backup reads the entire file and then backs up only those data blocks that have changed since a previous backup. Oracle allows you to create and restore incremental backups of datafiles, tablespaces, or the whole database. Note that RMAN can include a control file in an incremental backup set, but the control file is always included in its entirety--no blocks are skipped.
The primary reasons for making an incremental backup are:
If none of these criteria apply, then full backups are usually preferable because the application of the incremental backup increases recovery time while the cost savings is negligible.
This section contains the following topics:
RMAN allows you to create multi-level incremental backups. Each incremental level is denoted by an integer, for example, 0, 1, 2, etc. A level 0 incremental backup, which is the base for subsequent incremental backups, copies all blocks containing data. When you generate a level n incremental backup in which n is greater than 0, you back up:
The benefit of performing multi-level incremental backups is that you do not back up all of the blocks all of the time. Since RMAN needs to read all of the blocks of the datafile, full backups and incremental backups taking approximately the same amount of time (assuming that the output of the backup is not a bottleneck).
Incremental backups at levels greater than 0 only copy blocks that were modified. The size of the backup file depends solely upon the number of blocks modified and the incremental backup level.
Each data block in a datafile contains an SCN, which is the SCN at which the last change was made to the block. During an incremental backup, RMAN reads the SCN of each data block in the input file and compares it to the checkpoint SCN of the parent incremental backup. RMAN reads the entire file every time whether or not the blocks have been used.
The parent backup is the backup that RMAN uses for comparing the SCNs, so the parent can be a level 0 backup or, depending on the incremental level, a level 1 or level 2 backup. If the SCN in the input data block is greater than the checkpoint SCN of the parent, then RMAN copies the block.
Note that one consequence of this mechanism is that RMAN applies all blocks containing changed data during recovery--even if the change is to an object created with the NOLOGGING option. Hence, making incremental backups functions as a safeguard against the loss of changes made to NOLOGGING tables.
In a differential level n incremental backup, RMAN backs up all blocks that have changed since the most recent backup at level n or lower. For example, in a differential level 2 backup, RMAN determines which level 1 or level 2 backup occurred most recently and backs up all blocks modified since that backup. If no level 1 is available, RMAN copies all blocks changed since the base level 0 backup. Incremental backups are differential by default.
In the example above:
An incremental level 0 backup backs up all blocks that have ever been in use in this database.
A differential incremental level 2 backup backs up all blocks that have changed since the most recent incremental backup at level n or less; in this case, the most recent incremental backup at level 2 or less is the level 0 Sunday backup, so only the blocks changed since Sunday will be backed up.
A differential incremental level 2 backup backs up all blocks that have changed since the most recent incremental backup at level n or less; in this case, the most recent incremental backup at level 2 or less is the level 2 Monday backup, so only the blocks changed since Monday will be backed up.
An incremental level 2 backup backs up all blocks that have changed since the most recent incremental backup at level n or less; in this case, the most recent incremental backup at level 2 or less is the level 2 Tuesday backup, so only the blocks changed since Tuesday will be backed up.
An incremental level 1 backup backs up all blocks that have changed since the most recent incremental backup at level n or less; in this case, the most recent incremental backup at level 1 or less is the level 0 Sunday backup, so only the blocks changed since the Sunday level 0 backup will be backed up.
An incremental level 2 backup backs up all blocks that have changed since the most recent incremental backup at level n or less; in this case, the most recent incremental backup at level 2 or less is the level 1 Thursday backup, so only the blocks changed since the Thursday level 1 backup will be backed up.
An incremental level 2 backup backs up all blocks that have changed since the most recent incremental backup at level n or less; in this case, the most recent incremental backup at level 2 or less is the level 2 Friday backup, so only the blocks changed since the Friday level 2 backup will be backed up.
Oracle provides an option to make cumulative incremental backups at level 1 or greater. In a cumulative level n backup, RMAN backs up all the blocks used since the most recent backup at level n-1 or lower. For example, in a cumulative level 2 backup, RMAN determines which level 1 backup occurred most recently and copies all blocks changed since that backup. If no level 1 backup is available, RMAN copies all blocks changed since the base level 0 backup.
Cumulative incremental backups reduce the work needed for a restore by ensuring that you only need one incremental backup from any particular level. Cumulative backups require more space and time than differential backups, however, because they duplicate the work done by previous backups at the same level.
In the example above:
An incremental level 0 backup backs up all blocks that have ever been in use in this database.
A cumulative incremental level 2 backup backs up all blocks that have changed since the most recent incremental backup at level n-1 or less; in this case, the most recent incremental backup at level 2-1 or less is the level 0 Sunday backup, so only the blocks changed since Sunday will be backed up.
A cumulative incremental level 2 backup occurs. This backs up all blocks that have changed since the most recent incremental backup at level n-1 or less; in this case, the most recent incremental backup at level 2-1 or less is the level 0 Sunday backup, so all the blocks changed since Sunday will be backed up. (This backup includes those blocks that were copied on Monday, since this backup is cumulative and includes the blocks copied at backups taken at the same incremental level as the current backup).
A cumulative incremental level 2 backup backs up all blocks that have changed since the most recent incremental backup at level n-1 or less; in this case, the most recent incremental backup at level 2-1 or less is the level 0 Sunday backup, so all the blocks changed since Sunday will be backed up. (This backup includes those which were copied on Monday and Tuesday, since this backup is cumulative and includes the blocks copied at backups taken at the same incremental level as the current backup).
A cumulative incremental level 1 backup backs up all blocks that have changed since the most recent incremental backup at level n-1 or less; in this case, the most recent incremental backup at level 1-1 or less is the level 0 Sunday backup, so all the blocks changed since Sunday will be backed up.
A cumulative incremental level 2 backup backs up all blocks that have changed since the most recent incremental backup at level n-1 or less; in this case, the most recent incremental backup at level 2-1 or less is the level 1 Thursday backup, so all the blocks changed since Thursday will be backed up.
A cumulative incremental level 2 backup backs up all blocks that have changed since the most recent incremental backup at level n-1 or less; in this case, the most recent incremental backup at level 2-1 or less is the level 1 Thursday backup, so all the blocks changed since Thursday will be backed up.
Choose your backup scheme according to an acceptable MTTR (mean time to recover). For example, you can implement a three-level backup scheme so that a level 0 backup is taken monthly, a cumulative level 1 backup is taken weekly, and a cumulative level 2 is taken daily. In this scheme, you never have to apply more than a day's worth of redo for complete recovery.
When deciding how often to take level 0 backups, a good rule of thumb is to take a new level 0 whenever 50% or more of the data has changed. If the rate of change to your database is predictable, then you can observe the size of your incremental backups to determine when a new level 0 is appropriate. The following query displays the number of blocks written to a backup set for each datafile with at least 50% of its blocks backed up:
SELECT file#, incremental_level, completion_time, blocks, datafile_blocks FROM v$backup_datafile WHERE incremental_level > 0 AND blocks / datafile_blocks > .5 ORDER BY completion_time;
Compare the number of blocks in your differential or cumulative backups to your base level 0 backup. For example, if you only create level 1 cumulative backups, then when the most recent level 1 backup is about half of the size of the base level 0 backup, take a new level 0.
RMAN performs backup operations only when an instance has the database mounted or open. In an Oracle parallel server environment, if the instance where the backup operation is being performed does not have the database open, then the database must not be open by any instance.
RMAN supports tablespace, datafile, archived redo log, and control file backups. It does not back up:
Oracle8i Parallel Server Documentation Set: Oracle8i Parallel Server Concepts; Oracle8i Parallel Server Setup and Configuration Guide; Oracle8i Parallel Server Administration, Deployment, and Performance for more information about backup constraints in a parallel server environment.
See Also:
An image copy contains a single datafile, archived redo log file, or control file that you can use as-is to perform recovery. Use the RMAN copy command or an operating system command such as the UNIX cp command to create image copies.
An image copy produced with the RMAN copy command is similar to an operating system copy of a single file, except that an Oracle server session produces it. The server session performs additional actions like validating the blocks in the file and registering the copy in the control file. An image copy differs from a backup set because it is not multiplexed, nor is there any additional header or footer control information stored in the copy. RMAN only writes image copies to disk.
Use the RMAN copy command to create an image copy. If the original file needs to be replaced, and if the image copy is of a datafile, then you do not need to restore the copy. Instead, Oracle provides a switch command to point the control file at the copy and update the recovery catalog to indicate that the copy has been switched. Issuing the switch command in this case is equivalent to issuing the SQL statement ALTER DATABASE RENAME DATAFILE. You can then perform media recovery to make the copy current.
RMAN can catalog an image copy and read the metadata. This operation is important when the recovery catalog is lost and you must perform disaster recovery. Only image copies and archived logs can be cataloged.
Oracle supports image copies created by mechanisms other than RMAN, also known as O/S copies. For example, a copy of a datafile that you make with the UNIX cp command is an O/S copy. You must catalog such O/S copies with RMAN before using them with the restore or switch commands.
You can create an O/S copy when the database is open or closed. If the database is open and the datafile is not offline normal, then you must place the tablespace in hot backup mode, that is, issue the SQL statement ALTER TABLESPACE BEGIN BACKUP before creating the copy.
|
WARNING: If you do not put a tablespace in hot backup mode before making an online backup, Oracle can generate fractured blocks. See "Detection of Logical Block Corruption". |
Some sites store their datafiles on mirrored disk volumes, which permits the creation of image copies by breaking the mirrors. After you have broken the mirror, you can notify RMAN of the existence of a new O/S copy, thus making it a candidate for use in a restore operation. You must notify RMAN when the copy is no longer available for restore, however, by using the change ... uncatalog command. In this example, if the mirror is resilvered (not including other copies of the broken mirror), then you must use a change ... uncatalog command to update the recovery catalog and indicate that this copy is no longer available.
|
See Also:
"How Do You Catalog an Operating System Backup?" to learn how to catalog copies, and "change" for reference material on the change command. |
You can assign a user-specified character string called a tag to backup sets and image copies (either RMAN-created copies or O/S-created copies). A tag is a symbolic name for a backup set or file copy such as weekly_backup; you can specify the tag rather than the filename when executing the restore or change command. The maximum length of a tag is 30 characters.
Tags do not need to be unique: multiple backup sets or image copies can have the same tag. When a tag is not unique, then with respect to a given datafile, the tag refers to the most current suitable file. By default, Recovery Manager selects the most recent backups to restore unless qualified by a tag or a set until command. The most current suitable backup containing the specified file may not be the most recent backup, as can occur in point-in-time recovery.
For example, if datafile copies are created each Monday evening and are always tagged mondayPMcopy, then the tag refers to the most recent copy. Thus, this command switches datafile 3 to the most recent Monday evening copy:
switch datafile 3 to datafilecopy tag mondayPMcopy;
Tags can indicate the intended purpose or usage of different classes of backups or file copies. For example, datafile copies that are suitable for use in a switch can be tagged differently from file copies that should be used only for restore.
Use the RMAN restore command to restore datafiles, control files, and archived redo logs from backup sets or image copies on disk. Because a backup set is in an Oracle proprietary format, you cannot simply import it; you must use the RMAN restore command to extract it. In contrast, Oracle can use image copies created using RMAN without additional processing.
You can restore:
"Restoring Datafiles, Control Files, and Archived Redo Logs" to learn how to restore backup sets and copies, and "restore" for reference material on the restore command.
See Also:
RMAN automates the procedure for restoring files. You do not need to go into the operating system, locate the backup or copy that you want to use, and manually copy files into the appropriate directories. When you issue a restore command, RMAN directs a server session to restore the correct backups and copies to either:
When RMAN performs a restore, the restore command creates datafile copies and records them in the repository. If you do not specify a set newname command for the restored files, then RMAN restores the backups to the default location and immediately updates the datafile copies created during the restore to status DELETED.
If you do specify set newname commands for the restored files, then you can execute a switch command so that RMAN considers the restored files as the current database files. If you fail to execute a switch command to point the control file to the datafile copies, then the datafile copy records remain in the repository and can confuse RMAN in the future. RMAN considers the un-switched files as valid datafile copies and hence candidates for future restore operations.
RMAN uses the recovery catalog--or target database control file if no recovery catalog is available--to select the best available backup sets or image copies for use in the restore operation. It gives preference to image copies rather than backup sets. When multiple choices are available, RMAN uses the most current backup sets or copies, taking into account whether you specified the untilClause.
All specifications of the restore command must be satisfied before RMAN restores a backup set or file copy. The restore command 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 RMAN returns an error during the compilation phase 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 create a new job specifying channels for devices that are compatible with the existing backup sets or datafile copies.
Note the following constraints on the restore command:
Media recovery is the application of online or archived redo logs or incremental backups to a restored datafile in order to update it to the current time or some other specified time. Use the RMAN recover command to perform media recovery and apply incremental backups automatically. You can only recover current datafiles.
If possible, make the recovery catalog available to perform the media recovery. If it is not available, then RMAN uses information from the target database control file. Note that if control file recovery is required, then you must make the recovery catalog available. RMAN cannot operate when neither the recovery catalog nor the target database control file is available.
The generic steps for media recovery using RMAN are:
Chapter 6, "Restoring and Recovering with Recovery Manager" for detailed restore and recovery procedures.
See Also:
|
See Also:
"Recovering Datafiles" to learn how to recover datafiles, and "recover" for reference material on the recover command. |
If RMAN has a choice between applying an incremental backup or applying redo to the restored datafiles, then it always chooses to use the incremental backup. If over-lapping levels of incremental backup are available, then RMAN automatically chooses the one covering the longest period of time.
If RMAN cannot find an incremental backup, it looks for an archived redo log. Whenever ARCn archives a redo log, Oracle immediately records it in the control file. Recovery Manager propagates this information into the recovery catalog during resynchronization, classifying archived redo logs as image copies. Use the list command to display them.
During recovery, RMAN looks for the appropriate archived redo logs in the default locations specified in the parameter file. If it cannot find them anywhere on disk, it looks in backup sets and restores archived redo logs as needed to perform the media recovery.
By default, RMAN restores the archived redo logs to the current log archive destination specified in the initialization parameter file. Use the set archivelog destination command to specify a different restore location.
RMAN can perform either complete or incomplete recovery. Using the set until command, you can specify a time, SCN, or log sequence number as a limit for incomplete recovery. Typically, you use this command before issuing the restore and recover commands. After performing incomplete recovery, always open the database with the RESETLOGS option and then immediately back up the database.
Recovery Manager automated Tablespace Point-in-Time Recovery (TSPITR) enables you to recover one or more tablespaces to a point-in-time that is different from that of the rest of the database. RMAN TSPITR is most useful in these situations:
Similar to a table export, RMAN TSPITR enables you to recover a consistent data set; however, the data set is the entire tablespace rather than a single object.
|
See Also:
Chapter 8, "Performing Point-in-Time Recovery with Recovery Manager" to learn how to perform TSPITR using RMAN. |
Use the RMAN duplicate command to create a test database on which to practice your backup and recovery procedures. The command takes disk backups of your primary database's files and uses them to create a new database. A test database is especially useful if your production database must be up and running 24 hours per day, 7 days a week.
As part of the duplicating operation, RMAN manages the following:
Note also the following features of RMAN duplication. You can:
The method you use to duplicate your database depends on whether you are creating your duplicate database on the same or a different host and whether the duplicate directory structure is the same as your target database file system. For example, in some cases you can keep the same directory structure and filenames in your duplicate database, while in other cases you must reset the filenames using set newname commands, the DB_FILE_NAME_CONVERT initialization parameter, or both.
|
See Also:
Chapter 7, "Creating a Duplicate Database with Recovery Manager" to learn how to make a duplicate database, and "duplicate" for duplicate command syntax. |
Oracle prohibits any attempts to perform operations that result in unusable backup files or corrupt restored datafiles. Oracle performs integrity checks to:
Because an Oracle server session is performing backup and copy operations, the server session is able to detect many types of corrupt blocks. Each new corrupt block not previously encountered in a backup or copy operation is recorded in the control file and in the alert.log.
RMAN queries corruption information at the completion of a backup and stores it in the recovery catalog and control file. Access this data using the views V$BACKUP_CORRUPTION and V$COPY_CORRUPTION.
If RMAN encounters a datafile block during a backup that has already been identified as corrupt by the database, then the server session copies the corrupt block into the backup and Oracle logs the corruption in the control file as either a logical or media corruption.
If RMAN encounters a datafile block with a corrupt header that has not already been identified as corrupt by the database, then it writes the block to the backup with a reformatted header indicating that the block has media corruption.
RMAN can test data and index blocks that pass physical corruption checks for logical corruption, for example, corruption of a row piece or index entry. If RMAN finds logical corruption, it logs the block in the alert.log and server session trace file.
Provided the sum of physical and logical corruptions detected for a file remain below its maxcorrupt setting, the RMAN command completes and Oracle populates V$BACKUP_CORRUPTION and V$COPY_CORRUPTION with corrupt block ranges. If maxcorrupt is exceeded, then the command terminates without populating the views.
When performing open backups without using Recovery Manager, you must put tablespaces in hot backup mode in case the operating system reads a block for a backup that is currently being written by DBWn, and is thus inconsistent. Thus, the block is a fractured block.
When performing a backup using RMAN, an Oracle server session reads the datafiles, not an operating system utility. The Oracle server session reads whole Oracle blocks and checks to see whether the block is fractured by comparing control information stored in the header and footer of each block. If the session detects a fractured block, then it re-reads the block. For this reason, do not put tablespaces into hot backup mode when using Recovery Manager to back up or copy database files.
|
 Copyright © 1996-2000, Oracle Corporation. All Rights Reserved. |
|