Release 2 (9.2)
Part Number A96566-01
 Home |
 Book List |
 Contents |
 Index |
 Master Index |
 Feedback |
| Oracle9i Recovery Manager User's Guide Release 2 (9.2) Part Number A96566-01 |
|
This chapter describes how to use Recovery Manager to manage backup and copy operations. This chapter contains these topics:
You have the following mutually exclusive options for executing backup and copy jobs:
CONFIGURE command, and then issue BACKUP and COPY commands at the RMAN prompt or within a RUN blockBACKUP and COPY commands within a RUN blockThe easiest way to make backups is to configure automatic channels. For example, so long as you have already configured an sbt device type, you can configure a default sbt channel as follows (note that the PARMS value is vendor-specific):
CONFIGURE DEVICE TYPE sbt PARALLELISM 1; CONFIGURE DEFAULT DEVICE TYPE TO sbt; CONFIGURE CHANNEL DEVICE TYPE sbt PARMS 'ENV=(NSR_SERVER=bksvr1)';
Then, you can back up the database to tape at the RMAN prompt as follows:
BACKUP DATABASE;
RMAN preconfigures a DISK channel for you, so you can make disk backups using automatic channels without performing any configuration whatsoever.
The other method is to allocate channels manually within a run job. For example, this command allocates multiple disk channels and then backs up the database and archived redo logs:
RUN { ALLOCATE CHANNEL ch1 DEVICE TYPE DISK; ALLOCATE CHANNEL ch2 DEVICE TYPE DISK; ALLOCATE CHANNEL ch3 DEVICE TYPE DISK; BACKUP DATABASE PLUS ARCHIVELOG; }
This example manually allocates an sbt channel (with a vendor-specific PARMS value) and backs up a datafile copy:
RUN { ALLOCATE CHANNEL ch1 DEVICE TYPE sbt PARMS 'ENV=(NSR_SERVER=bksvr1)'; BACKUP DATAFILECOPY '/tmp/system01.dbf'; }
For the most part, the procedures in this chapter assume that you have configured automatic channels.
This section contains these topics:
See Also:
|
Run backups of any of the following objects with the RMAN BACKUP command when the database is either mounted or open:
Although the BACKUP command works on datafiles, archived redo log files, control files, and server parameter files, the database depends on other files for production operation. You should back up other important files on the operating system either with a third-party backup product. You should back up files needed for the operating system to run as well as networking files, password files, and files in the Oracle home.
The BACKUP command backs up database files into one or more backup sets on disk or tape. You can set parameters for the BACKUP command to specify the filenames for the backup pieces, the number of files to go in each set, and which channel should operate on each input file.
You can make RMAN backups when the database is open or closed. Closed backups can be consistent or inconsistent, depending on how the database was shut down. RMAN backup are further divided into full and incremental backups. Full backups are nonincremental, that is, every used block is backed up.
If you use Oracle Enterprise Manager, then you can use Backup wizard instead of the command-line interface. You can perform the following RMAN tasks through the Backup Wizard:
Using the Oracle Enterprise Manager's Create Backup Configuration property sheets, you can edit an existing backup configuration or create other backup configurations. A backup configuration is automatically created for each target database by Enterprise Manager. In the backup configuration, you can specify the following options:
See Also:
|
Consistent backups can be restored without recovery. To make a consistent backup, the database:
SHUTDOWN ABORT the last time it was openIf these conditions are not met, then the backup is inconsistent. An inconsistent backup requires media recovery when it is restored, but is otherwise just as valid as a consistent backup.
You can use SQL*Plus or RMAN to start up and shutdown the database. The following example connects to the target database, shuts it down cleanly, and then mounts it in preparation for a backup:
% rman TARGET / RMAN> SHUTDOWN IMMEDIATE # closes database consistently RMAN> STARTUP MOUNT # uses SPFILE
If you can afford to close the primary database, then take closed, consistent backups of the whole database. If you cannot shut down the database, then the only option is to make a backup while the database is open.
| See Also:
Oracle9i Data Guard Concepts and Administration for more information about backing up standby databases |
To make a whole database backup:
BACKUP DATABASE command at the RMAN prompt. This example backs up all the datafiles as well as the control file and server parameter file (if used). It does not specify a FORMAT parameter, so RMAN gives each backup piece a unique name automatically and stores it in the port-specific default location ($ORACLE_HOME/dbs on UNIX):
BACKUP DATABASE; # uses automatic channels to make backup SQL 'ALTER SYSTEM ARCHIVE LOG CURRENT'; # switches logs and archives all logs
Optionally, use the FORMAT parameter to specify a filename for the backup piece. For example, enter:
BACKUP DATABASE FORMAT '/tmp/%U'; # %U generates a unique filename
Optionally, use the TAG parameter to specify a backup tag. For example, enter:
BACKUP DATABASE TAG = 'weekly_backup'; # gives the backup a tag identifier
Note that RMAN assigns a default tag to backups. Refer to the BACKUP ... TAG description in Oracle9i Recovery Manager Reference for the default format.
LIST BACKUP OF DATABASE command to see a listing of backup sets and pieces.Back up tablespaces when the database is either open or closed. Note that all open database backups are always inconsistent. Do not issue ALTER DATABASE BEGIN BACKUP before making an online tablespace backup.
To back up a tablespace:
BACKUP TABLESPACE command at the RMAN prompt. This example backs up three tablespaces, using the FILESPERSET parameter to specify that no more than three datafiles go in each backup set:
BACKUP FILESPERSET = 3 TABLESPACE system, users, tools;
LIST BACKUP OF TABLESPACE command to see a listing of backup sets and pieces. For example:
LIST BACKUP OF system, users, tools;
Back up datafiles and datafile copies when the database is either open or closed. Note that all open database backups are always inconsistent.
Use the BACKUP DATAFILE command to back up individual datafiles. You can specify the datafiles by name or number.
To back up a datafile:
BACKUP DATAFILE command at the RMAN prompt. This example backs up datafiles 1 through 4 as well as an image copy of a datafile:
BACKUP DATAFILE 1,2,3,4 FILESPERSET 3 DATAFILECOPY '/tmp/system01.dbf';
If CONFIGURE CONTROLFILE TO AUTOBACKUP is OFF, then the current control file and server parameter file are automatically included in the datafile backup set. If ON, then RMAN writes these files to a separate autobackup piece.
LIST BACKUP OF DATAFILE command to see a listing of backup sets and pieces. For example:
LIST BACKUP OF DATAFILE 1,2,3,4;
Use the BACKUP DATAFILECOPY command to back up datafile copies. Datafile copies exist on disk only.
To back up a datafile copy:
BACKUP DATAFILECOPY command at the RMAN prompt. This example backs up datafile /tmp/system01.dbf to tape:
BACKUP DATAFILECOPY '/tmp/system01.dbf';
LIST BACKUP OF DATAFILECOPY command to see a listing of backup sets and pieces. For example:
LIST BACKUP OF DATAFILE 1;
You can make backups of the control file when the database is open or closed. RMAN uses a snapshot control file to ensure a read-consistent version.
If CONFIGURE CONTROLFILE AUTOBACKUP is ON (by default it is OFF), then RMAN automatically backs up the control file and the current server parameter file (if used) in the following circumstances:
BACKUP or COPY command issued at the RMAN prompt.BACKUP or COPY command within a RUN block is followed by a command that is neither BACKUP nor COPY.RUN block if the last command in the block was either BACKUP or COPY.CONFIGURE CONTROLFILE AUTOBACKUP FOR DEVICE TYPE DISK to set a nondefault disk location. Note that the autobackup never causes the associated structural change to fail. For example, if you add a datafile, and if the resulting autobackup fails, then the datafile addition is still successful.
The first channel allocated during the backup or copy job creates the autobackup and places it into its own backup set; for post-structural autobackups, the default disk channel makes the backup. RMAN writes the control file and the server parameter file to the same backup piece. After the control file autobackup completes, Oracle writes a message containing the complete path of the backup piece and the device type to the alert log.
As explained by the following table, the RMAN behavior when the BACKUP command includes datafile 1 differs depending on whether CONFIGURE CONTROLFILE AUTOBACKUP is ON or OFF.
Consequently, whenever you back up a file or set of files, RMAN automatically makes a control file backup afterward. This control file backup contains metadata about the previous backup, which is crucial in a disaster recovery situation.
If the autobackup feature is not set, then you must manually back up the control file in one of the following ways:
1, which automatically includes the control file in the backupBACKUP CURRENT CONTROLFILEINCLUDE CURRENT CONTROLFILE option of the BACKUP command
This procedure creates a control file backup by using the BACKUP CURRENT CONTROLFILE command.
To back up the current control file manually:
BACKUP CURRENT CONTROLFILE command at the RMAN prompt. This example backs up the current control file to tape and assign a tag:
BACKUP CURRENT CONTROLFILE TAG = mondaypmbackup;
Note that if the autobackup feature is enabled, then RMAN makes two control file backups in this example: the explicit control file backup (BACKUP CURRENT CONTROLFILE) and the subsequent control file and server parameter file autobackup.
LIST command to display backup sets and pieces. For example:
LIST BACKUP OF CONTROLFILE;
This procedure creates a control file backup by including the control file in the backup of another object.
To include the current control file in another backup:
Specify the INCLUDE CURRENT CONTROLFILE option after specifying the backup object. For example, this command backs up tablespace users and includes the current control file in the backup:
BACKUP TABLESPACE users INCLUDE CURRENT CONTROLFILE;
Note that if the autobackup feature is enabled, then RMAN also generates an autobackup of the control file after the BACKUP TABLESPACE command completes.
This procedure creates a control file backup by using the BACKUP CONTROLFILECOPY command.
To back up a control file copy:
BACKUP CONTROLFILECOPY command at the RMAN prompt. This example creates the control file copy '/tmp/control01.ctl' and then backs it up:
COPY CURRENT CONTROLFILE TO '/tmp/control01.ctl'; BACKUP CONTROLFILECOPY '/tmp/control01.ctl';
LIST BACKUP OF CONTROLFILE command to see a listing of backup sets and pieces. For example:
LIST BACKUP OF CONTROLFILE;
As explained in "Backing Up Control Files with RMAN", RMAN automatically backs up the current server parameter file in certain circumstances. You can also use the BACKUP SPFILE command to back up the server parameter file explicitly. For example:
BACKUP COPIES 2 DEVICE TYPE sbt SPFILE;
Note that the backup is only by the server parameter file currently in use by the instance. If the instance is started with a client-side initialization parameter file, then RMAN does not back up anything.
Archived redo logs are the key to successful media recovery. Back them up regularly. You can back up logs by issuing BACKUP ARCHIVELOG or by backing up datafiles and control files and specifying BACKUP ... PLUS ARCHIVELOG.
Note that when specific conditions are met, RMAN attempts to switch out of and archive the current online redo logs when you back up archived redo logs.
| See Also:
"Automatic Online Redo Log Switches During Backups of Archived Logs" for the conditions under which RMAN attempts to switch out of the current online log |
To back up archived logs, run BACKUP ARCHIVELOG with the desired filtering options. If you archive to multiple locations, RMAN does not put multiple copies of the same log sequence number into the same backup set. The BACKUP ARCHIVELOG ALL command backs up exactly one copy of each distinct log sequence number.
You can specify the DELETE INPUT option in the BACKUP command, which deletes the archived logs after backing them up. Thus, you can back up archived logs to tape and clear disk space of old logs in one step. RMAN only deletes the specific copy of the archived redo log that it backs up, and then deletes only this copy.
If you specify the DELETE ALL INPUT option, then RMAN makes a backup of each specified log sequence number, but deletes logs from all enabled archiving destinations. For example, assume that you archive to /arc_dest1, /arc_dest2, and /arc_dest3, and you run the following command:
BACKUP ARCHIVELOG ALL DELETE ALL INPUT;
RMAN backs up only one copy of each log sequence number that it finds in these directories, and then deletes all copies of all logs that it finds in these directories. If you had specified DELETE INPUT rather than DELETE ALL INPUT, then RMAN would only delete the specific disk copy that it backed up (for example, only the logs in /arc_dest1).
Note that if you issue BACKUP ARCHIVELOG ALL or BACKUP ARCHIVELOG LIKE '...', and if no archived redo logs exist, then RMAN does not signal an error.
See Also:
|
To back up archived redo logs using BACKUP ARCHIVELOG:
BACKUP ARCHIVELOG command at the RMAN prompt. This example uses a configured channel to back up one copy of each log sequence number to tape and delete all the copies on disk:
BACKUP ARCHIVELOG ALL DELETE ALL INPUT;
Note that depending on the conditions (refer to "Automatic Online Redo Log Switches During Backups of Archived Logs"), RMAN attempts to switch out of archive the current redo log as well.
You can also specify a range of archived redo logs by time, SCN, or log sequence number. The following example backs up all logs that could be used to recover from a point 30 days ago to a point 7 days ago:
BACKUP ARCHIVELOG FROM TIME 'SYSDATE-30' UNTIL TIME 'SYSDATE-7';
Note that because you specified UNTIL TIME, RMAN does not automatically switch out of archive the current online redo log.
LIST BACKUP OF ARCHIVELOG ALL command to see a listing of backup sets and pieces. For example:
LIST BACKUP OF ARCHIVELOG ALL;
When backing up objects other than archived logs, you can specify BACKUP ... PLUS ARCHIVELOG to include backups of archived logs. The command performs the following sequential actions:
ALTER SYSTEM ARCHIVE LOG CURRENT command.BACKUP ARCHIVELOG ALL. Note that if backup optimization is enabled (refer to "Backing Up Files Using Backup Optimization"), then RMAN skips logs that it has already backed up to the specified device.BACKUP command.ALTER SYSTEM ARCHIVE LOG CURRENT command.In this way, you guarantee that the datafiles that you are backing up are recoverable to a consistent state.
To back up archived redo logs using BACKUP ... PLUS ARCHIVELOG:
BACKUP command at the RMAN prompt and specify PLUS ARCHIVELOG. This example backs up the database and all archived redo logs:
BACKUP DATABASE PLUS ARCHIVELOG;
LIST BACKUP command to see a listing of backup sets and pieces. For example:
LIST BACKUP OF DATABASE SUMMARY; LIST BACKUP OF ARCHIVELOG SUMMARY;
Backing up archived redo logs in an Oracle Real Application Clusters environment poses special problems. To illustrate, assume that you are not using NFS on UNIX or mapped drives on Windows to mount remote directories, and that you have configured the cluster as follows:
/d1/arc_dest/d2/arc_dest/d3/arc_destNote that if you do not use NFS or mapped drives, then each node must archive to a directory with a different path, or the backup of the logs will fail.
In this example, the control file can have records of archived logs that look something like the following
/d1/arc_dest/log100_1.arc /d1/arc_dest/log101_1.arc /d3/arc_dest/log143_3.arc /d3/arc_dest/log144_3.arc /d2/arc_dest/log55_2.arc /d2/arc_dest/log56_2.arc /d2/arc_dest/log57_2.arc /d3/arc_dest/log145_3.arc /d3/arc_dest/log146_3.arc /d2/arc_dest/log58_2.arc /d1/arc_dest/log102_1.arc /d2/arc_dest/log59_2.arc /d1/arc_dest/log103_1.arc /d1/arc_dest/log104_1.arc
Assume that you start RMAN on node 2 and run the following command:
RUN { ALLOCATE CHANNEL node2 DEVICE TYPE sbt;BACKUPARCHIVELOGALL. }
In this case, the channel can only see the logs in /d2/arc_dest, causing the job to fail because it cannot find the /d1 or /d3 logs.
Refer to Oracle9i Real Application Clusters Administration to learn how to configure your environment to avoid this situation. For example, you can implement a cluster file system (CFS), or you can use NFS or mapped drives to mount directories so that when RMAN connects to any node, it can access the logs generated by all nodes. However, if you do not configure your environment for remote access, then you can solve the problem of backing up logs simply by specifying which channel should back up which logs.
To back up archived redo logs in an Oracle Real Application Clusters configuration:
sbt channels, one for each node:
CONFIGURE DEVICE TYPE sbt PARALLELISM 3; CONFIGURE DEFAULT DEVICE TYPE to sbt; CONFIGURE CHANNEL 1 DEVICE TYPE sbt CONNECT 'SYS/oracle@node1' PARMS 'ENV=(NSR_SERVER=bksvr1)'; # channel 1 is for first node CONFIGURE CHANNEL 2 DEVICE TYPE sbt CONNECT 'SYS/oracle@node2' PARMS 'ENV=(NSR_SERVER=bksvr2)'; # channel 2 is for second node CONFIGURE CHANNEL 3 DEVICE TYPE sbt CONNECT 'SYS/oracle@node3' PARMS 'ENV=(NSR_SERVER=bksvr3)'; # channel 3 is for third node
BACKUP ARCHIVELOG ALL;
See Also:
|
Prudence suggests making multiple copies of backups to protect against disaster, media damage, or human error. RMAN can make up to four copies of a backup set simultaneously, each an exact duplicate of the others. A copy of a backup set is a copy of each backup piece in the backup set, with each copy getting a unique copy number (for example, 0tcm8u2s_1_1 and 0tcm8u2s_1_2).
In most cases, the easiest method is to use BACKUP COPIES or CONFIGURE ... BACKUP COPIES to duplex backups. Note that there is little value in creating multiple copies on the same physical media. For DISK channels, specify multiple values in the FORMAT option to direct the multiple copies to different physical disks. For sbt channels, if you use a media manager that supports Version 2 of the SBT API, then the media manager will automatically put each copy onto a separate medium (for example, a separate tape).
The CONFIGURE ... BACKUP COPIES command specifies the number of identical backups that you want to create on the specified device type. This command applies only to datafiles (which includes current control files as well as control file autobackups) and archived logs. You must have automatic channels configured.
To duplex a backup with CONFIGURE BACKUP COPIES:
CONFIGURE DEVICE TYPE sbt PARALLELISM 1; CONFIGURE DEFAULT DEVICE TYPE TO sbt; CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT '/save1/%U', '/save2/%U'; CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE sbt TO 2; CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE sbt TO 2; CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 2;
BACKUP DATABASE PLUS ARCHIVELOG; # uses default sbt channel
The following command backs up the database to disk, placing one copy in the /save1 directory and the other in the /save2 directory:
BACKUP DEVICE TYPE DISK DATABASE;
LIST BACKUP command to see a listing of backup sets and pieces (the #Copies column shows the degree of duplexing). For example, enter:
LIST BACKUP SUMMARY;
The COPIES option of the BACKUP command overrides every other COPIES or DUPLEX setting.
To duplex a backup with BACKUP COPIES:
COPIES option of the BACKUP command. For example, run the following to make three copies of each backup set in the default DISK directory:
BACKUP COPIES 3 INCREMENTAL LEVEL = 0 DATABASE;
Note that because you specified COPIES on the BACKUP command itself, RMAN makes three copies of each datafile regardless of the CONFIGURE DATAFILE COPIES setting.
LIST BACKUP command to see a listing of backup sets and pieces (the #Copies column shows the degree of duplexing). For example, enter:
LIST BACKUP SUMMARY;
You can make consistent or inconsistent incremental backups of the database or individual tablespaces or datafiles. If the database is in NOARCHIVELOG mode, then you can only make consistent incremental backups, so the database must be closed cleanly. In ARCHIVELOG mode the database can be open or closed.
To make an incremental backup:
BACKUP INCREMENTAL command at the RMAN prompt. This example makes a level 0 backup:
BACKUP INCREMENTAL LEVEL = 0 DATABASE;
This example makes a differential level 1 backup of the SYSTEM tablespace and datafile sales.f; it will only back up those data blocks changed since the most recent level 1 or level 0 backup:
BACKUP INCREMENTAL LEVEL = 1 TABLESPACE SYSTEM DATAFILE '?/oradata/trgt/tools01.dbf';
This example makes a cumulative level 2 backup of the tablespace users; it will only back up those data blocks changed since the most recent level 1 or level 0 backup:
BACKUP INCREMENTAL LEVEL = 2 CUMULATIVE TABLESPACE users;
LIST BACKUP command to see a listing of backup sets and pieces. For example:
LIST BACKUP OF DATABASE;
Many sites keep an backup of the database stored on disk in case a failure occurs on the primary database or an incorrect user action such as a DROP TABLE requires incomplete recovery. A datafile backup on disk simplifies the restore step of recovery, making recovery much quicker and more reliable.
One way of creating an datafile backup on disk is to use disk mirroring. For example, you can use the operating system to maintain three identical copies of each file in the database. In this configuration, you can split off a mirrored copy of the database to use as a backup.
RMAN does not automate the splitting of mirrors, but can make use of split mirrors in backup and recovery operations. For example, RMAN can treat a split mirror of a datafile as a datafile copy, and can also back up this copy to disk or tape.
The following procedure shows how to make a split mirror backup with the optional SUSPEND/RESUME functionality. The SUSPEND/RESUME feature is not required for split mirror backups in most cases, although it is necessary if your system requires the database cache to be free of dirty buffers before the volume can be split.
To make a split mirror backup of a tablespace by using SUSPEND/RESUME:
ALTER TABLESPACE ... BEGIN BACKUP statement. For example, to place tablespace users in backup mode, run the following commands:
% rman TARGET SYS/oracle@trgt CATALOG rman/cat@catdb RMAN> SQL 'ALTER TABLESPACE users BEGIN BACKUP';
RMAN> SQL 'ALTER SYSTEM SUSPEND';
RMAN> SQL 'ALTER SYSTEM RESUME';
RMAN> SQL 'ALTER TABLESPACE users END BACKUP';
CATALOG command. For example, enter:
RMAN> CATALOG DATAFILECOPY '/dk2/oradata/trgt/users01.dbf'; # catalog split mirror
BACKUP DATAFILECOPY command at the prompt:
RMAN> BACKUP DATAFILECOPY '/dk2/oradata/trgt/users01.dbf';
CHANGE ... UNCATALOG command to uncatalog the datafile copies you cataloged in step 6. For example, enter:
RMAN> CHANGE DATAFILECOPY '/dk2/oradata/trgt/users01.dbf' UNCATALOG;
| See Also:
Oracle9i SQL Reference for |
This section contains these topics:
| See Also:
Chapter 13, "Creating a Standby Database with Recovery Manager" for an overview of how RMAN interacts with a standby database |
RMAN can back up the standby database and its associated archived redo logs. Standby backups of datafiles and archived redo logs are fully interchangeable with primary database backups. In other words, you can run the RESTORE command to restore a backup of a standby datafile to the primary database, and you can restore a backup of a primary datafile to the standby database. The standby control file and primary control file, however, are not interchangeable.
Backing up standby files is often better than backing up the production files, for the following reasons:
Both the primary database and standby database should use the same recovery catalog. Even though these databases share the same DBID, RMAN is able to differentiate the standby database from the primary. Note that you do not need to register the standby database in the catalog if the primary is already registered: simply connect to the standby database and run the BACKUP command.
If you activate a standby database using ALTER DATABASE ACTIVATE STANDBY DATABASE, then the standby database becomes the new primary database. Because a RESETLOGS must be performed at standby activation, RMAN creates a new incarnation record for the new primary database. Backups of this new incarnation of the primary database are not different from backups of the primary database after a RESETLOGS operation.
| See Also:
"Opening the Database After Media Recovery" in the chapter "Performing Recovery Using SQL and SQL*Plus" from Oracle9i User-Managed Backup and Recovery Guide to learn about |
Note these restrictions when making backups of a standby database:
DUPLICATE command to create another standby database. To create another standby database, connect to the primary database and run DUPLICATE.TARGET keyword (not the AUXILIARY keyword). Essentially, the standby database is "substituting" for the primary database during the backup.
| See Also:
Oracle9i Data Guard Concepts and Administration for more information about backing up standby databases |
If you are making archived log backups on the standby site, then ensure that all necessary archived logs are available on the primary site in the event of a failure. The situation can be confusing because archived logs can be in any of the following locations:
The recovery catalog view RC_ARCHIVED_LOG indicates when an archived log is located at the primary site and when it is at the standby site. The archived logs information in RC_ARCHIVED_LOG is important because you need to know when you must back up a log or copy it to the primary site from the standby site.
For example, assume that you start SQL*Plus, connect to the recovery catalog database as the recovery catalog schema owner, and then run this query:
SELECT SEQUENCE#, IS_STANDBY FROM RC_ARCHIVED_LOG; SEQUENCE# IS_ ---------- --- 113 YES 114 NO 115 NO 116 YES 116 NO
The IS_STANDBY column indicates whether the log is located at the standby site (YES) or at the primary site (NO). If the same log sequence number has IS_STANDBY set to both YES and NO, then the log is located at both the standby and primary sites. For example, sequence number 116 has both a YES and NO value for IS_STANDBY, so it is at the primary and standby sites.
If you are making all your backups at the standby site, then you must ensure that you have backed up all the archived logs generated by the primary database. You have two methods for determining whether you need to back up a standby database archived log so that RMAN can use it for recovery:
Use the LIST BACKUP OF ARCHIVELOG ALL command to determine which logs RMAN has backed up.
To determine whether a log backup is needed by using the LIST command:
SELECT SEQUENCE#, IS_STANDBY FROM RC_ARCHIVED_LOG; SEQUENCE# IS_ ---------- --- 113 YES 114 NO 115 NO 116 NO
This output indicates that log sequence 113 is at the standby site but not at the primary site, and archived logs 114 through 116 are at the primary site but not the standby site.
LIST BACKUP command in RMAN. For example:
LIST BACKUP OF ARCHIVELOG ALL; List of Backup Sets Key Recid Stamp LV Set Stamp Set Count Completion Time ------- ---------- ---------- -- ---------- ---------- ---------------------- 319 4 394624547 0 394624546 5 11-APR-00 List of Backup Pieces Key Pc# Cp# Status Completion Time Piece Name ------- --- --- ----------- ---------------------- ------------------------ 320 1 1 AVAILABLE 11-APR-00 /vobs/oracle/dbs/05boavh2_1_1 List of Archived Logs Included Thrd Seq Low SCN Next SCN Low Time Next Time ---- ------- ---------- ---------- --------------- --------------- 1 116 95153 95156 07-APR-00 07-APR-00
This output shows that RMAN has backed up archived log 116, but has not backed up archived log 113. Because log 113 exists only at the standby site, you should either back up this log or copy it to the primary site.
You can query the recovery catalog to determine which logs RMAN has backed up.
To determine whether a log backup is needed by querying the catalog:
RC_ARCHIVED_LOG recovery catalog view to determine whether all archived logs necessary for recovery are on disk. For example, issue the following query, where first_log_needed_for_recovery is the sequence number of the log that begins recovery and expected_num_of_logs is the number of logs that should be applied during complete recovery:
SELECT 1 FROM RC_ARCHIVED_LOG WHERE SEQUENCE# >= first_log_needed_for_recovery AND IS_STANDBY='NO' AND STATUS='A' HAVING COUNT(*) = expected_num_of_logs;
If the query returns no rows, then you do not have all logs necessary for complete recovery on disk. If the query does return rows, then you do have the necessary logs for complete recovery on disk.
RC_BACKUP_REDOLOG view to determine whether you have backups of the logs necessary for complete recovery. For example, issue the following query, where first_log_needed_for_recovery is the sequence number of the log that begins recovery and expected_num_of_logs is the number of logs that should be applied during complete recovery:
SELECT 1 FROM RC_BACKUP_REDOLOG WHERE SEQUENCE# >= first_log_needed_for_recovery AND STATUS='A' HAVING COUNT(DISTINCT SEQUENCE#) = expected_num_of_logs;
If the query returns no rows, then you do not have backups of all logs necessary for complete recovery. If the query does return rows, then you do have backups of all logs necessary for complete recovery.
Use the RMAN BACKUP command to back up the standby database. A backup of the standby database is exactly the same as a backup of the primary database, except that the backup takes place on the standby site. The primary database has no influence on the backup of the standby database. Note that when you connect to the standby database to perform the backup, you connect using the TARGET keyword and not the AUXILIARY keyword.
As the following table shows, whether the standby database backup is consistent or inconsistent depends on the state of the standby database when the backup is made. Only a consistent backup can be restored without performing media recovery.
To make a whole database backup of a standby database:
sqlplus SYS/oracle@sbdb1 <<EOF SHUTDOWN IMMEDIATE STARTUP NOMMOUNT PFILE=initSTANDBY.ora ALTER DATABASE MOUNT STANDBY DATABASE; EOF
You can back up the standby database when it is in any other mode, but the backups will be inconsistent.
TARGET keyword (not the AUXILIARY keyword) and the recovery catalog database. You must be connected to the recovery catalog. For example, enter:
% rman TARGET SYS/oracle@sbdb1 CATALOG rman/cat@catdb
DISK or sbt. Note that you are connected to the standby host, so the backups are made by server sessions on the standby (not the primary) host.
This example backs up all the standby datafiles as well as the control file and archived logs by using automatic channels:
BACKUP DATABASE PLUS ARCHIVELOG;
You can use the FORMAT parameter to specify a filename for the backup piece. For example, enter:
BACKUP DATABASE FORMAT '/tmp/standby_%U'; # %U generates a unique filename
You can specify TAG to give a tag to the backup. For example, enter:
BACKUP DATABASE TAG = 'weekly_standby_backup'; # gives the standby backup a tag
RMAN assigns a default tag to backups. Refer to the BACKUP ... TAG description in Oracle9i Recovery Manager Reference for the default format.
LIST command to see a listing of backup sets and pieces.Use the BACKUP BACKUPSET command to back up backup sets rather than database files. This command is especially useful in the following scenarios:
To back up backup sets from disk to tape:
sbt channel, issue the BACKUP BACKUPSET command at the RMAN prompt. This example allocates the default disk channel and the configured sbt channel to back up all backup sets to tape:
BACKUP DEVICE DEVICE TYPE sbt BACKUPSET ALL;
This example backs up all disk backup sets to tape and then deletes the input disk backups:
BACKUP DEVICE TYPE sbt BACKUPSET ALL DELETE INPUT;
LIST command to see a listing of backup sets and pieces.RMAN supports two distinct features by which it can back up only those files that require backups: restartable backups and backup optimization.
With the restartable backup feature, RMAN backs up only those files that were not backed up after a specified date. For example, by specifying the NOT BACKED UP SINCE TIME clause, you can direct RMAN to back up only those files that were not backed up within the last day.
With backup optimization, the BACKUP command skips the backup of a file if the identical file has already been backed up to the allocated device type. To override this behavior and back up all files whether or not they have changed, specify the FORCE option on the BACKUP command. To enable or disable backup optimization, specify ON or OFF on the CONFIGURE BACKUP OPTIMIZATION command.
Additionally, a third feature can archive unarchived online logs as well as back up archived logs (refer to "Backing Up Logs Using BACKUP ... PLUS ARCHIVELOG").
| See Also:
"Backup Optimization" for a conceptual overview of optimization, and "Restartable Backups" for a conceptual overview of restartable backups |
For backup optimization to be enabled, you must CONFIGURE BACKUP OPTIMIZATION to ON. Backup optimization is OFF by default.
To optimize a backup:
CONFIGURE OPTIMIZATION command. For example, enter:
CONFIGURE OPTIMIZATION ON;
BACKUP DEVICE TYPE DISK COPIES 2 DATABASE PLUS ARCHIVELOG;
The following example backs up logs to an sbt device:
BACKUP DEVICE TYPE sbt ARCHIVELOG ALL;
Depending on the retention policy and backup duplexing settings, RMAN backs up only those files that changed after the last backup. RMAN does not signal an error when it skips a file, even if it skips all files.
| See Also:
"Backup Optimization" for a conceptual overview of optimization and backup retention policies |
Use the SINCE TIME parameter of the BACKUP command to specify a date after which a new backup is required. If you do not specify the SINCE parameter, then RMAN only backs up files that have never been backed up.
To only back up files that were not backed up after a specified date:
Specify a valid date in the SINCE TIME parameter. For example, this command uses the default configured channel to back up all database files and archived redo logs that have not been backed up in the last two weeks:
BACKUP NOT BACKED UP SINCE TIME 'SYSDATE-14' DATABASE PLUS ARCHIVELOG;
You can use the VALIDATE keyword of the BACKUP command to do the following:
RMAN does not actually produce backup sets, but rather scans the specified files to determine whether they can be backed up and are not corrupted. In this sense, the BACKUP VALIDATE command is similar to the RESTORE VALIDATE command, except for backups rather than restore jobs. If the backup validation discovers corrupt blocks, then RMAN updates the V$DATABASE_BLOCK_CORRUPTION view with rows describing the corruptions. After a corrupt block is repaired, the row identifying this block is deleted from the view.
For example, you can validate that all database files and archived redo logs can be backed up by running a command as follows:
BACKUP VALIDATE DATABASE ARCHIVELOG ALL;
RMAN displays the same output that it would if it were really backing up the files. If RMAN cannot validate the backup of one or more of the files, then it displays an error message. For example, RMAN may show output similar to the following:
RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =========================================================== RMAN-03002: failure of backup command at 08/29/2001 14:33:47 ORA-19625: error identifying file /oracle/oradata/trgt/arch/archive1_6.dbf ORA-27037: unable to obtain file status SVR4 Error: 2: No such file or directory Additional information: 3
You cannot use the MAXCORRUPT or PROXY parameters with the VALIDATE option.
See Also:
|
In many cases, making a copy is better than making a backup, because copies are not in an RMAN-specific format and hence are suitable for use without any additional processing. In contrast, you must process a backup set with 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 a single backup piece.
|
Note: You cannot make incremental copies, although you can use the |
Use the COPY command to create image copies. RMAN always writes the output file to disk. You can copy the following types of files:
There is no COPY DATABASE command to correspond to the BACKUP DATABASE command, so you must copy the datafiles individually. Run the REPORT SCHEMA command to determine the filenames of the datafiles.
To make consistent copies of all database files:
SHUTDOWN IMMEDIATE STARTUP MOUNT
If the database is open, or if it is mounted but not closed cleanly when last opened, then the backup will be inconsistent.
REPORT SCHEMA; Report of database schema File K-bytes Tablespace RB segs Datafile Name ---- ---------- -------------------- ------- ------------------- 1 307200 SYSTEM *** /oracle/oradata/trgt/system01.dbf 2 20480 UNDOTBS *** /oracle/oradata/trgt/undotbs01.dbf 3 10240 CWMLITE *** /oracle/oradata/trgt/cwmlite01.dbf 4 10240 DRSYS *** /oracle/oradata/trgt/drsys01.dbf 5 10240 EXAMPLE *** /oracle/oradata/trgt/example01.dbf 6 10240 INDX *** /oracle/oradata/trgt/indx01.dbf 7 10240 TOOLS *** /oracle/oradata/trgt/tools01.dbf 8 10240 USERS *** /oracle/oradata/trgt/users01.dbf
COPY command at the RMAN prompt. Copy all of the datafiles and include the current control file. For example, enter the following at the RMAN prompt:
COPY DATAFILE 1 TO '/tmp/system01.dbf', DATAFILE 2 TO '/tmp/undotbs01.dbf', DATAFILE 3 TO '/tmp/cwmlite01.dbf', DATAFILE 4 TO '/tmp/drsys01.dbf', DATAFILE 5 TO '/tmp/example01.dbf', DATAFILE 6 TO '/tmp/indx01.dbf', DATAFILE 7 TO '/tmp/tools01.dbf', DATAFILE 8 TO '/tmp/users01.dbf', CURRENT CONTROLFILE TO '/tmp/control01.ctl';
LIST COPY OF DATABASE command to see a listing of image copies. For example:
LIST COPY OF DATABASE;
Besides copying datafiles and control files, you can copy other copies and archived redo logs (and archived redo log copies).
To copy datafiles, archived redo logs, and control files:
SHUTDOWN IMMEDIATE STARTUP MOUNT
If the database is open, or if it is mounted but not closed cleanly when last opened, then the backup will be inconsistent.
COPY command at the RMAN prompt. Copy the desired datafiles, archived redo logs, and control files. For example, enter:
COPY DATAFILECOPY '/tmp/system01.dbf' TO '/save/system01.dbf', DATAFILECOPY TAG = 'weekly_df8_copy' TO '/tmp/users01.dbf', # copy archived redo logs ARCHIVELOG '?/oradata/trgt/arch/archive1_1.dbf' TO '/tmp/archive1_1.dbf', ARCHIVELOG '?/oradata/trgt/arch/archive1_2.dbf' TO '/tmp/archive1_2.dbf'', # copy a control file copy CONTROLFILECOPY '/tmp/control01.ctl' TO '/save/control01.ctl';
LIST COPY command to see a listing of image copies.As explained in "Control File and Server Parameter File Autobackups", if the autobackup feature is enabled then RMAN automatically backs up the control file after BACKUP or COPY commands.
The section "Configuring the Control File Autobackup Format" describes the default format for the control file autobackup. You can also use the CONFIGURE command to change the default autobackup format to a new value.
Note that you must include the %F format in the string, or RMAN signals an error. This format change is persistent across all RMAN sessions. For example, you can change the default as follows:
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE sbt TO 'c_%F'; CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '?/oradata/%F.bck';
You can override the configured location for the control file backup in an RMAN session by using the SET command to specify the directory and possibly a prefix and suffix. For example, you can set the following:
SET CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE sbt TO 'controlfile_%F'; RUN { SET CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '/tmp/%F.bck'; }
The order of precedence of control file autobackup format commands is:
SET CONTROLFILE AUTOBACKUP FORMAT within RUNSET CONTROLFILE AUTOBACKUP FORMAT at the RMAN promptCONFIGURE CONTROLFILE AUTOBACKUP FORMAT
See Also:
|
This section contains these topics:
Assume that you configure an automatic sbt channel as follows:
CONFIGURE DEVICE TYPE sbt PARALLELISM 1; # configure device CONFIGURE CHANNEL DEVICE TYPE sbt PARMS='...'; # configure options for channels CONFIGURE DEFAULT DEVICE TYPE to sbt; # set default device type
Assume that you want to back up the database to disk and use the default configured DISK channel. You can specify that the BACKUP command should use a DISK channel as follows:
BACKUP DEVICE TYPE DISK DATABASE;
To back up the database to the sbt device run this command:
BACKUP DATABASE;
The following example assumes that the database is running in ARCHIVELOG mode and that you have an automatic sbt channel configured as follows:
CONFIGURE DEVICE TYPE sbt PARALLELISM 1; CONFIGURE DEFAULT DEVICE TYPE TO sbt; CONFIGURE CHANNEL DEVICE TYPE sbt PARMS='ENV=(NSR_DATA_VOLUME_POOL=BackupPool)';
To back up the database while skipping offline and read-only tablespaces, you can run the following command:
BACKUP DATABASE SKIP READONLY SKIP OFFLINE;
You need to back up a read-only tablespace only once after it has been made read-only. You can use the SKIP READONLY option to skip read-only datafiles. If you use the SKIP OFFLINE option, then the BACKUP command does not attempt to access offline datafiles. Use this option if the offline datafiles are not available.
Another way to persistently skip tablespaces across RMAN sessions is to issue the CONFIGURE EXCLUDE command for each tablespace that you always want to skip. For example, you may always want to skip the example tablespace, which has been made read-only. You can then issue:
CONFIGURE EXCLUDE FOR TABLESPACE example;
Then, whenever you run BACKUP DATABASE, RMAN skips this tablespace. You do not have to specify a SKIP clause on the BACKUP command. You can override this behavior and include the earnings tablespace as follows:
BACKUP DATABASE NOEXCLUDE;
Assume that you back up the database and archived logs every night to tape by running this command:
BACKUP FILESPERSET 2 DATABASE PLUS ARCHIVELOG;
This command limits each backup set to two datafiles, so it produces multiple backup sets. Assume that the media management device fails halfway through the backup and is then restarted. The next day you discover that only half the backup sets completed. In this case, you can run this command in the evening:
BACKUP # Note that the NOT BACKED UP SINCE clause should be placed immediately after the BACKUP # keyword or after each individual backupSpec clause NOT BACKED UP SINCE TIME 'SYSDATE-1' FILESPERSET 2 DATABASE PLUS ARCHIVELOG;
RMAN backs up only files that were not backed up during in the previous 24 hours. When RMAN finds out that particular file is already backed up it displays output similar to the following:
RMAN-06501: skipping datafile 1; already backed up on MAY 02 2001 18:10:00 RMAN-06501: skipping datafile 2; already backed up on MAY 02 2001 18:09:45 RMAN-06501: skipping datafile 3; already backed up on MAY 02 2001 18:09:45
Typically, you do not need to specify a format when backing up to tape because the default %U variable generates a unique filename for tape backups. When backing up to disk, however, you can specify a format if you need to spread the backup across several drives for improved performance. In this case, allocate one DISK channel for each disk drive and specify the format string on the ALLOCATE CHANNEL command so that the filenames are on different disks. For example, issue:
RUN { ALLOCATE CHANNEL disk1 DEVICE TYPE DISK FORMAT '/disk1/%d_backups/%U'; ALLOCATE CHANNEL disk2 DEVICE TYPE DISK FORMAT '/disk2/%d_backups/%U'; ALLOCATE CHANNEL disk3 DEVICE TYPE DISK FORMAT '/disk3/%d_backups/%U'; BACKUP DATABASE; }
You can accomplish the same result by configuring automatic channels as follows:
CONFIGURE DEVICE TYPE DISK PARALLELISM 3; CONFIGURE DEFAULT DEVICE TYPE TO DISK; CONFIGURE CHANNEL 1 DEVICE TYPE DISK FORMAT '/disk1/%d_backups/%U'; # configure 1st ch CONFIGURE CHANNEL 2 DEVICE TYPE DISK FORMAT '/disk2/%d_backups/%U'; # configure 2nd ch CONFIGURE CHANNEL 3 DEVICE TYPE DISK FORMAT '/disk3/%d_backups/%U'; # configure 3rd ch BACKUP DATABASE;
If you specify a nonexistent directory, RMAN displays output such as the following:
RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =========================================================== RMAN-03009: failure of backup command on ORA_DISK_1 channel at 08/29/2001 14:36:04 ORA-19504: failed to create file "foo/0cd2momi_1_1" ORA-27040: skgfrcre: create error, unable to create file SVR4 Error: 2: No such file or directory
In this scenario, you have a 40 GB database that you want to back up to disk. Because RMAN can only write one backup piece on a raw disk device, you decide to spread the backup across file systems. You decide to back up to four file systems and make each backup set roughly the same size: 10 GB. You want each backup piece to be no more than 2 GB so that each backup set contains five backup pieces.
You decide to use the FORMAT parameter of the CONFIGURE CHANNEL command so that each channel will write to a different file system. You use conversion variables to guarantee unique names for the backup pieces. For example, the following commands configure channels across four file systems (/fs1, /fs2, /fs3, /fs4) and group the datafiles so that each backup set is about the same size.
CONFIGURE DEVICE TYPE DISK PARALLELISM 4; # first, configure the device for parallelism 4 CONFIGURE CHANNEL 1 DEVICE TYPE DISK FORMAT='/fs1/%u.%p' MAXPIECESIZE 2G; CONFIGURE CHANNEL 2 DEVICE TYPE DISK FORMAT='/fs2/%u.%p' MAXPIECESIZE 2G; CONFIGURE CHANNEL 3 DEVICE TYPE DISK FORMAT='/fs3/%u.%p' MAXPIECESIZE 2G; CONFIGURE CHANNEL 4 DEVICE TYPE DISK FORMAT='/fs4/%u.%p' MAXPIECESIZE 2G; CONFIGURE DEFAULT DEVICE TYPE TO DISK;
Then, you can run this command every night to generate four backup sets, each in a different directory and each approximately the same size:
BACKUP DATABASE;
You can also back up the backup sets from disk to four different tapes from a tape pool by setting PARALLELISM=4 for the sbt device (and specifying the appropriate vendor-specific PARMS for the sbt channel), as in the following example:
CONFIGURE DEVICE TYPE sbt PARALLELISM 4; CONFIGURE CHANNEL DEVICE TYPE sbt PARMS='...'; BACKUP DEVICE TYPE sbt BACKUPSET ALL DELETE INPUT;
When making backups, RMAN divides the total number of files requiring backups by the number of allocated channels to calculate the number of files to place in each backup set. Use the FILESPERSET and MAXSETSIZE parameters to override this calculation and specify how many files should go in each backup set.
When you specify the FILESPERSET parameter, RMAN compares the FILESPERSET value to the automatically calculated value (number of files for each allocated channel) and takes the lower of the two values, thereby ensuring that all channels are used. For example, if you are backing up twelve datafiles with three channels, and set FILESPERSET=2, RMAN puts two datafiles into each backup rather than four.
If the number of files specified or implied by the combined backupSpec clauses is greater than FILESPERSET, for example, if eight total files need backing up when FILESPERSET=4, then RMAN creates multiple backup sets to maintain the correct ratio of files for each backup set.
If you do not specify FILESPERSET, then RMAN compares the calculated value (number of files divided by number of allocated channels) to the default value of 64 and takes the lower of the two values, again ensuring that all channels are used. The default value of 64 is high for most applications: specify a lower value or use the MAXSETSIZE parameter to limit the size of a backup set.
RMAN always attempts to create enough backup sets so that all allocated channels have work to do. An exception to the rule occurs when there are more channels than files to back up. For example, if RMAN backs up one datafile when three channels are allocated, then two channels are idle.
This example configures disk parallelism to 4:
CONFIGURE DEVICE TYPE DISK PARALLELISM 4;
This script runs a backup specifying that no more than 3 datafiles go in any one backup set, and no more than 16 archived logs in any one backup set:
BACKUP { DATABASE FILESPERSET = 3 ARCHIVELOG ALL FILESPERSET = 16; }
The MAXSETSIZE parameter specifies a maximum size for a backup set in units of bytes (default), kilobytes, megabytes, or gigabytes. Thus, to limit a backup set to 305 MB, specify MAXSETSIZE=305M. RMAN attempts to limit all sets to this size.
You can use MAXSETSIZE to limit the size of backup sets so that the database is divided among more than one backup set. Otherwise, if the backup fails partway through, then you must start the database backup from scratch. If you configure MAXSETSIZE so that you generate multiple backup sets, however, then if the backup fails partway through, you can use the restartable backup feature to back up only those files that were not backed up during the previous attempt.
The MAXSETSIZE parameter is easier to use than FILESPERSET when you make backups of archived redo logs. This example configures a tape device, then backs up archived redo logs to tape, limiting the size to 100 MB so that if the backup fails partway through, it can be restarted:
CONFIGURE DEVICE TYPE sbt PARALLELISM 1; CONFIGURE DEFAULT DEVICE TYPE TO sbt; BACKUP MAXSETSIZE = 100M ARCHIVELOG ALL;
This example accomplishes the same result with CONFIGURE MAXSETSIZE:
CONFIGURE DEFAULT DEVICE TYPE TO sbt; CONFIGURE MAXSETSIZE = 100M; BACKUP ARCHIVELOG ALL;
Note that if you specify a MAXSETSIZE value that is smaller that the smallest file that you are backing up, then RMAN displays an error stack such as the following:
RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =========================================================== RMAN-03002: failure of backup command at 08/29/2001 14:40:33 RMAN-06182: archive log larger than SETSIZE: thread 1 seq 1 /oracle/oradata/trgt/arch/archive1_1.dbf
Backup piece size is an issue in those situations where it exceeds the maximum file size of the file system or media management software. Use the MAXPIECESIZE parameter of the CONFIGURE CHANNEL or ALLOCATE CHANNEL command to limit the size of backup pieces.
For example, to limit the backup file size to 2000 MB or less, you can configure the automatic DISK channel as follows and then run BACKUP DATABASE:
CONFIGURE CHANNEL DEVICE TYPE DISK MAXPIECESIZE 2000M; # max file size for backup pieces BACKUP DATABASE;
Note that in version 2.0 of the media management API, media vendors can specify the maximum size of a backup piece, causing RMAN to comply with this restriction automatically.
Assume you need to back up a database called trgt. The following conditions exist in the database environment:
You do not want a large number of backup sets, so you set FILESPERSET=64. However, you do not want to multiplex more than four files because this value is sufficient to keep the tape drive streaming. So, you set MAXOPENFILES=4.
Assume that you have configured three sbt channels as follows (using the PARMS setting appropriate required by each media management device):
CONFIGURE DEVICE TYPE sbt PARALLELISM 3; # parallelize to 3 tape drives CONFIGURE DEFAULT DEVICE TYPE TO sbt; CONFIGURE CHANNEL 1 DEVICE TYPE sbt MAXOPENFILES 4 PARMS='...'; CONFIGURE CHANNEL 2 DEVICE TYPE sbt MAXOPENFILES 4 PARMS='...'; CONFIGURE CHANNEL 3 DEVICE TYPE sbt MAXOPENFILES 4 PARMS='...';
Then, you can create the following backup script:
CREATE SCRIPT TRGT_FULL { BACKUP FILESPERSET 4 DATABASE FORMAT 'TRGT.FULL.%d.%s.%p'; }
Alternatively, you can create a script that allocates channels manually:
CREATE SCRIPT TRGT_FULL { ALLOCATE CHANNEL t1 DEVICE TYPE sbt MAXOPENFILES 4 PARMS='...'; ALLOCATE CHANNEL t2 DEVICE TYPE sbt MAXOPENFILES 4 PARMS='...'; ALLOCATE CHANNEL t3 DEVICE TYPE sbt MAXOPENFILES 4 PARMS='...'; BACKUP FILESPERSET 64 DATABASE FORMAT 'TRGT.FULL.%d.%s.%p'; }
You can then run the script as follows:
RUN { EXECUTE SCRIPT TRGT_FULL; }
This script backs up the whole database, including all datafiles and the control file. Because there are 1001 files to be backed up (1000 datafiles and a control file) and a maximum of four files for each backup set, Oracle creates 16 backup sets. Because MAXOPENFILES is 4, each channel reads from 4 datafiles simultaneously. The backup piece filenames have the following format, where db_name is the database name, set_num is the backup set number, and piece_num is the piece number:
TRGT.FULL.db_name.set_num.piece_num
For example, a backup piece could have the following filename:
TRGT.FULL.trgt.3.1
If no backup sets have been recorded in the recovery catalog before this job, then set_num will range from one through seven and piece_num will be one or more.
Assume that you set your initialization parameters so that you archive to the following local destinations:
LOG_ARCHIVE_DEST_1 = 'LOCATION=/disk1/arch/' LOG_ARCHIVE_DEST_2 = 'LOCATION=/disk2/arch/' LOG_ARCHIVE_DEST_3 = 'LOCATION=/disk3/arch/'
Each directory contains the same set of logs, starting with log sequence 1 and ending at log sequence 400. Unknown to you, a user inadvertently deletes logs 300 through 400 from /disk1/arch and logs 350 through 400 from /disk2/arch. You run this backup command:
BACKUP ARCHIVELOG FROM SEQUENCE 288 UNTIL SEQUENCE 388 THREAD 1 DELETE INPUT;
RMAN begins backing up logs starting with log sequence 288. If the copy of log 300 that was deleted from /disk1/arch is the one that RMAN attempts to back up, then RMAN checks the repository to determine whether other copies of this log sequence exist, and backs up the log in either /disk2/arch or /disk3/arch. Hence, because a copy of each log in sequence 288 through 388 is located in at least one of the three directories, RMAN can back up all the specified logs.
Assume that you back up database trgt while it is open. You want to back up only those archived redo logs required to recover this online backup. How do you determine which logs to back up?
To determine the archived logs needed for recovery of an online backup:
ALTER SYSTEM ARCHIVE LOG CURRENT;
V$LOG to determine the log sequence number of the current redo log, as in the following example (which includes output):
SELECT SEQUENCE# FROM V$LOG WHERE STATUS = 'CURRENT'; SEQUENCE# ---------- 9100
BACKUP DATABASE;
SQL 'ALTER SYSTEM ARCHIVE LOG CURRENT';
V$LOG to determine the log sequence number of the current redo log:
SELECT SEQUENCE# FROM V$LOG WHERE STATUS = 'CURRENT'; SEQUENCE# ---------- 9112
For example, issue the following to back up the necessary archived logs:
BACKUP ARCHIVELOG FROM SEQUENCE 9100 UNTIL SEQUENCE 9111;
In this scenario, you set initialization parameters so that you automatically archive redo logs to two directories: ?/oradata/trgt/arch/dest_1 and ?/oradata/trgt/arch/dest_2. Therefore, you have two identical copies of the archived redo log for each log sequence number. You decide to back up each copy of the archived redo logs and then delete the originals.
The easiest solution in this case is to use the DELETE ALL INPUT option means that RMAN deletes all logs that match the ARCHIVELOG criteria. Hence, it can remove all logs from both ?/oradata/trgt/arch/dest_1 and ?/oradata/trgt/arch/dest_2.
For example, run the following command to back up all logs that could be used to recover from a point 10 days ago, and then delete all logs within the specified time range from disk:
BACKUP DEVICE TYPE sbt ARCHIVELOG ALL FROM TIME 'SYSDATE-10' DELETE ALL INPUT;
A differential incremental backup contains only blocks that have been changed since the most recent backup at the same level or lower. The first incremental backup must be a level 0 backup that contains all used blocks. The following is a level 0 base backup:
BACKUP INCREMENTAL LEVEL 0 DATABASE;
An incremental backup at level 1 or higher will contain all blocks changed since the most recent level 1 backup. If no previous level 1 backup is available, then RMAN copies all blocks changed since the base level 0 backup. The following is a level 1 backup of the database:
BACKUP INCREMENTAL LEVEL 1 DATABASE;
If you add a new datafile or tablespace to the database, then make a level 0 backup before making another incremental backup. Otherwise, the incremental backup of the tablespace or the database fails because RMAN does not find a parent backup for the new datafiles. The following is a level 0 backup of a single tablespace:
BACKUP INCREMENTAL LEVEL 0 TABLESPACE users2;
Note that you can perform incremental backups in NOARCHIVELOG mode, but the backups must be consistent. Hence, you cannot take online incremental backups.
A cumulative incremental backup at level n contains only blocks that have been changed since the most recent backup at level n - 1 or lower. Cumulative backups require more storage space than differential backups, but they are preferable during a restore operation because only one backup for a given level is needed. Note that the first incremental backup must be a level 0 backup that contains all used blocks.
A cumulative backup at level 2 will contain all blocks changed since the most recent level 1 backup, copying all blocks changed since the base level 0 backup only if a previous level 1 is unavailable. In contrast to a cumulative backup, a differential backup at level 2 will determine which level 1 or level 2 backup occurred most recently and copy all blocks changed since that backup.
BACKUP INCREMENTAL LEVEL 2 CUMULATIVE DATABASE; # blocks changed since level 0 or level 1
When you create multiple backup sets and allocate multiple channels, RMAN automatically writes multiple backup sets in parallel. The allocated server sessions share the work of backing up the specified datafiles, control files, and archived redo logs. Note that you cannot stripe a single backup set across multiple channels.
RMAN automatically assigns a backup set to a device. You can use the CHANNEL parameter so that RMAN writes all backup sets for a backupSpec to a specific channel.
For example, this example parallelizes the backup operation by specifying which channels RMAN should back up to disk and which to sbt:
RUN { ALLOCATE CHANNEL ch1 DEVICE TYPE DISK FORMAT = '/backup/df/%U'; ALLOCATE CHANNEL ch2 DEVICE TYPE DISK FORMAT = '/backup/cf/%U'; ALLOCATE CHANNEL ch3 DEVICE TYPE sbt; BACKUP # channel ch1 backs up datafiles to /backup/df directory DATAFILE 1,2,3,4 CHANNEL ch1 # channel ch2 backs up control file copy to /backup/cf directory CONTROLFILECOPY '/tmp/control01.ctl' CHANNEL ch2 # channel ch3 backs up archived redo logs to tape ARCHIVELOG FROM TIME 'SYSDATE-14' CHANNEL ch3; }
Note that you cannot back up to DISK and sbt at the same time using automatic channels: you must manually allocate them.
This script puts the database into the correct mode for a consistent, whole database backup and then backs up the database. Note that the script performs a shutdown, startup, shutdown, and then startup again before creating multiple copies of the backup:
# Shut down the database cleanly using immediate priority. This type of shutdown lets
# current calls to the database complete, but prevents further logons or calls.
# If the database is not up now, you will get a message saying so but RMAN will not
# treat this situation as an error.
SHUTDOWN IMMEDIATE;
# Start up the database in case it suffered instance failure or was closed with SHUTDOWN
# ABORT before starting this script. The scripts performs crash recovery if it is needed.
# Oracle uses the default init.ora file. Alternatively, use this form: STARTUP FORCE DBA
# pfile=filename. Use the DBA option because you are going to shut down again right
# away and do not want to let users in during the short interval. Use the FORCE
# option because it cannot hurt and might help in certain situations.
STARTUP FORCE DBA;
SHUTDOWN IMMEDIATE;
# The database is cleanly closed and is now ready for a consistent backup. RMAN requires
# that the database be started and mounted to perform a backup.
STARTUP MOUNT;
# this example uses automatic channels to make the backup
BACKUP COPIES 2 INCREMENTAL LEVEL 0 FILESPERSET 5 DATABASE;
# Now that the backup is complete, open the database.
ALTER DATABASE OPEN;
Note that you can skip tablespaces, but any skipped tablespace that has not been offline or read-only since its last backup will be lost if the database has to be restored from a backup. When backing up to disk, make sure that the destination (file system or raw device) has enough free space.
Assume that /node1 is a local directory accessible by node 1 of an Oracle Real Application Clusters configuration and /node2 is a local directory accessible by node 2. The automatic channel configuration is as follows:
CONFIGURE DEVICE TYPE sbt PARALLELISM 2; CONFIGURE DEFAULT DEVICE TYPE TO sbt; # the different CONNECT strings in the channels cause RMAN to enable # the autlocation feature CONFIGURE CHANNEL 1 DEVICE TYPE sbt CONNECT 'SYS/oracle@node_1'; CONFIGURE CHANNEL 2 DEVICE TYPE sbt CONNECT 'SYS/oracle@node_2';
Because in this scenario node 1 is more powerful than node 2, you want node 1 to back up the largest tablespaces. The following script distributes datafile and archived redo log backups across the two nodes:
BACKUP FILESPERSET 1 (TABLESPACE system, tools, users, undotbs CHANNEL ORA_SBT_TAPE_1) (TABLESPACE cwmlite, drsys, example, indx CHANNEL ORA_SBT_TAPE_2); BACKUP FILESPERSET 20 ARCHIVELOG ALL;
Because of the autolocation feature, the channel connected to node 1 backs up only the archived logs readable on node 1, and the channel connected to node 2 backs up only the archived logs readable on node2.
| See Also:
Oracle9i Real Application Clusters Administration for information about Oracle Real Application Clusters backups |
You can use operating system utilities to make datafile copies and then catalog them in the recovery catalog. Note that you can only catalog disk copies. Because the format of backup pieces is proprietary, operating system utilities cannot write backups readable by RMAN.
You must make the datafile copies by means of user-managed methods. If the database is open and the datafile is online, then issue ALTER TABLESPACE ... BEGIN BACKUP. For example, the resulting image copy can be cataloged:
CATALOG DATAFILECOPY '/tmp/users01.dbf';
Note that if you try to catalog a datafile copy from a database other than the connected target database, then RMAN issues an error such as the following:
RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =========================================================== RMAN-03009: failure of catalog command on default channel at 08/29/2001 14:44:34 ORA-19563: datafile copy header validation failed for file /tmp/tools01.dbf
If you configure a retention policy, then you may want to exclude specified backups from this policy. For example, you may want to archive a consistent backup of the database once a year to serve as a historical record. This long-term backups does not function as a backup that you may perform recovery on, but an archived snapshot of data at a particular time.
To exempt a backup from the retention policy, specify the KEEP option on the BACKUP command. You can also specify LOGS or NOLOGS to indicate whether RMAN should save archived logs for possible recovery of this backup. If you specify NOLOGS, then the backup must be consistent.
This example keeps the backup of the database indefinitely and does not save archived logs needed to recover it:
SHUTDOWN IMMEDIATE; STARTUP MOUNT; # put database in consistent state BACKUP DATABASE KEEP FOREVER NOLOGS TAG 'db_archive_1'; # make long-term consistent backup # mark backup as unavailable in the repository so that RMAN does not attempt to restore it # unless explicitly specified on the RESTORE command CHANGE BACKUP TAG 'db_archive_1' UNAVAILABLE; SQL 'ALTER DATABASE OPEN';
Run the CONFIGURE BACKUP OPTIMIZATION command to enable backup optimization. When specific conditions are met (described in "Backup Optimization Algorithm"), RMAN skips backups of files that are identical to files that are already backed up.
Assume that you configure optimization and a retention policy as follows:
CONFIGURE DEFAULT DEVICE TYPE TO sbt; CONFIGURE BACKUP OPTIMIZATION ON; CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 4 DAYS;
Then, you run this command every night to back up the database to tape:
BACKUP DATABASE;
Because backup optimization is configured, RMAN skips backups of offline and read-only datafiles only if the most recent backups were made on or after the earliest point in the recovery window. RMAN does not skip backups when the most recent backups are older than the window. For example, optimization ensures you do not end up with a new backup of the read-only datafile ?/oradata/trgt/history01.dbf every night, so long as one backup set containing this file exists within the recovery window.
For example, if the most recent backup of the datafiles was on Sunday, and the point of recoverability (that is, the earliest date in the recovery window) is on Saturday, then RMAN skips the datafiles when you run the Wednesday backup. On Friday, the point of recoverability is now Monday, so the Sunday backup is now outside the window. Hence, the Friday backup does not skip the datafiles.
Assume that you want to back up all the archived logs every night. However, you do not want to have multiple copies of each log sequence number. So, you configure backup optimization to ON, then run this command in a script every night at 1 a.m.:
BACKUP DEVICE TYPE sbt ARCHIVELOG ALL;
RMAN skips all logs except those produced in the last 24 hours. In this way, you keep only one copy of each archived log on tape.
In this example, you back up logs that are not already on tape to one tape pool, then back up the same logs to a second tape pool. Finally, you delete old logs.
For the first step, perform the one-time configuration:
# configure backup optimization CONFIGURE BACKUP OPTIMIZATION ON; CONFIGURE DEFAULT DEVICE TYPE TO sbt;
Then, run the following script at the same time every night to back up the logs generated during the previous day to two separate tape pools:
# The following command will back up just the archived logs that are not on tape. The # first copies are saved to the tapes from the pool "archivelog_pool_1" RUN { ALLOCATE CHANNEL c1 DEVICE TYPE sbt PARMS='NSR_DATA_VOLUME_POOL=ARCHIVELOG_POOL_1'; BACKUP CHANNEL 'ORA_SBT_TAPE_1' ARCHIVELOG ALL; } # Make one more copy of the archived logs and save them to tapes from a different pool RUN { ALLOCATE CHANNEL c2 DEVICE TYPE sbt PARMS='NSR_DATA_VOLUME_POOL=ARCHIVELOG_POOL_2'; BACKUP CHANNEL 'ORA_SBT_TAPE_2' ARCHIVELOG FROM TIME 'SYSDATE-1' UNTIL TIME 'SYSDATE'; # specify UNTIL so that RMAN does not archive current log } # Delete old logs - for example, delete logs created within the last week. DELETE ARCHIVELOG ALL COMPLETED AFTER 'SYSDATE-7';
Assume a more sophisticated scenario in which your goal is to back up the archived logs to tape every day. However, you are worried about tape failure, so you want to ensure that you have more than copy of each log sequence number on an separate tape before you perform your weekly deletion of logs from disk.
First, perform a one-time configuration:
# configure backup optimization CONFIGURE BACKUP OPTIMIZATION ON; CONFIGURE DEVICE TYPE sbt PARALLELISM 1; CONFIGURE DEFUALT DEVICE TYPE TO sbt; # configure a default channel that sends the backups to the tape pool called "first_copy" CONFIGURE CHANNEL DEVICE TYPE sbt PARMS='ENV=(NSR_DATA_VOLUME_POOL=first_copy);
Because you have optimization enabled, you can run the following command every evening to back up all archived logs to the "first_copy" pool that have not already been backed up:
BACKUP ARCHIVELOG ALL;
Every Friday evening you create an additional backup of all archived logs in a different tape pool. Also, at the end of the backup, you want to delete all archived logs that already have at least two copies on tape. So you run the following script:
BACKUP ARCHIVELOG ALL; # backs up logs not already on tape to pool "first_copy" RUN { # manually allocate a channel so that you bypass backup optimization for this job. # specify that the backup run by this channel should go to the pool "second_copy." ALLOCATE CHANNEL c1 DEVICE TYPE sbt PARMS='ENV=(NSR_DATA_VOLUME_POOL=second_copy)'; BACKUP ARCHIVELOG UNTIL TIME 'SYSDATE' # use UNTIL clause so RMAN does not switch logs NOT BACKED UP 2 TIMES # back up only logs without 2 backups on tape TAG SECOND_COPY; # specify TAG for convenience } # now delete from disk all logs that have been backed up to tape at least twice DELETE ARCHIVELOG ALL BACKED UP 2 TIMES TO DEVICE TYPE sbt;
The Friday script creates a second copy of all archived logs in the "second_copy" tape pool. After the backup, you can send the tape from the pool "second_copy" to the vault or lock it in your desk. You should use this tape backup only if the primary tape from pool "first_copy" is damaged. Because the secondary tape is in a secure place, you do not want RMAN to use it for recovery, so you can mark the backup as unavailable:
CHANGE BACKUP OF ARCHIVELOG TAG SECOND_COPY UNAVAILABLE;
By default a checksum is calculated for every block read from a datafile and stored in the backup or image copy. If you use the NOCHECKSUM option, then checksums are not calculated. If the block already contains a checksum, however, then the checksum is validated and stored in the backup. If the validation fails, then the block is marked corrupt in the backup.
The SET MAXCORRUPT FOR DATAFILE command sets how many corrupt blocks in a datafile that BACKUP or COPY will tolerate. If a datafile has more corrupt blocks than specified by the MAXCORRUPT parameter, the command terminates. If you specify the CHECK LOGICAL option, RMAN checks for logical and physical corruption.
By default, the BACKUP command terminates when it cannot access a datafile. You can specify parameters to prevent termination, as listed in the following table.
The following example uses an automatic channel to back up the database, and sets the corruption level for the datafile in the SYSTEM tablespace:
RUN { SET MAXCORRUPT FOR DATAFILE 1 TO 0; BACKUP DATABASE SKIP INACCESSIBLE SKIP READONLY SKIP OFFLINE; }
|
 Copyright © 1996, 2002 Oracle Corporation. All Rights Reserved. |
|