CHAPTER 13 • ORACLE8i RECOVERY MANAGER 556 TABLE 13.6: THE BACKUPSPEC LIST SPECIFICATION CLAUSES Clause and Parameters Description CHANNEL {channel_id} Specifies the name of a specific channel to use when cre- ating the backup sets. SETSIZE = {n} Defines the maximum size for a backup set in units of 1KB. TAG = ‘tag_name’ Associates a given tag with the backup set being created. DELETE INPUT Causes all source input files to be removed after being backed up. This clause is normally used with archived redo log backups to remove the source files after a suc- cessful backup operation. SKIP Causes the RMAN backup to skip any datafiles that are OFFLINE, READONLY, or INACCESSIBLE. POOL = {n} Defines the media pool in which the backup should be stored. Your media management software may or may not support this parameter. INCLUDE CURRENT CONTROLFILE Includes a snapshot of the current control file in the backup set being created by the backup. Recovery Commands There are two principal commands that are used in the recovery of a database from an RMAN database backup: RESTORE and RECOVER. Just as with backups, these com- mands are used in within the confines of a RUN block, along with ALLOCATE CHAN- NEL and other commands that help facilitate special types of recoveries, such as point-in-time recovery (which we will discuss later in this chapter). A typical recovery script, without any frills, looks something like the one shown in Listing 13.2. Listing 13.2: RMAN Database Recovery Script RUN { ALLOCATE CHANNEL d1 TYPE DISK; RESTORE DATABASE; RECOVER DATABASE; RELEASE CHANNEL d1; } EXIT; C opyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 557 The RESTORE Command The purpose of the RESTORE command is to restore database datafiles, archived redo logs, or control files from RMAN backups in preparation for recovering from some sort of database failure. RMAN can recover the entire set of database datafiles, datafiles associated with a given set of tablespaces, or individual datafiles, as required. With the RESTORE command, you can restore these files to their original locations, or if these locations are not available (due to disk failure, perhaps), to alternate locations. Table 13.7 summarizes the RESTORE command options. TABLE 13.7: THE RESTORE COMMAND OPTIONS Parameter Description restoreObject Specifies the type of object to be restored. Valid values for this parameter are listed in Table 13.8. restoreSpecOperand Allows you to override the RESTORE command level parameter for each individually restored object. This operand takes three parameters: CHANNEL {channel_id} indicates that you wish to use a different channel for this restore (if not used, the restore will use any channel that is available), FROM TAG {tag_name} causes the backup or file copy with the associated name to be used (if more than one backup set has the same tag, the most recent is used), and PARMS {channel_parms} passes operating- system specific information during each restore. VALIDATE Causes RMAN to validate that the backup sets, datafile copies, and archived logs that would be restored by the RESTORE com- mand are valid. No actual restore is performed. CHECK LOGICAL Checks the database and index blocks for any logical corruption. (RMAN automatically checks for physical corruption.) RMAN logs any logical corruption found to the V$BACKUP_CORRUPTION or V$COPY_CORRUPTION data dictionary views, unless the value for MAXCORRUPT is exceeded. The corrupt blocks are also logged in the alert log and a process trace file. CHECK READONLY Causes RMAN to check and restore any read-only database datafiles. The restoreObject parameter of the RESTORE command can be any of the values listed in Table 13.8. RUNNING RMAN Oracle Database Administration PART II C opyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. CHAPTER 13 • ORACLE8i RECOVERY MANAGER 558 TABLE 13.8: RESTORE OBJECT SPECIFICATION OBJECTS Parameter Type of Object Restored CONTROLFILE Causes the control file to be restored and written to all current control file locations. Optionally, you can specify a different path name and RMAN will restore the control file to that location only. DATABASE Causes all datafiles associated with the database to be recovered. The control file backup is not restored by this command (use the controlfile command for that operation). Offline and read-only datafiles are not restored unless the CHECK READONLY option is selected with the RESTORE command. DATAFILE {datafileSpec} Restores the database datafiles included in the datafileSpec param- eter. You can refer to the datafiles by filename (include the path name) or by datafile number. TABLESPACE Causes all database datafiles associated with the tablespaces {tablespace_name} listed in the tablespace_name parameter to be recovered. The RECOVER Command The RECOVER command is similar to the RECOVER command used in Oracle to recover a database. You can recover the entire database, one or more tablespaces, or datafiles. You can perform point-in-time recovery (which we will discuss later in this chapter) with the RECOVER command as well. Table 13.9 summarizes the parameters for this command. TABLE 13.9: THE RECOVER COMMAND PARAMETERS Parameter Description DATABASE Indicates that the entire database should be recovered. TABLESPACE Indicates that the datafiles associated with the listed tablespaces {tablespace_name} should be recovered. DATAFILE {datafileSpec} Indicates that the datafiles listed should be recovered. The datafiles can be specified as fully pathed names, as listed in the control file or the recovery catalog, or absolute datafile numbers. SKIP [FOREVER] Causes specific tablespace datafiles not to be recovered. TABLESPACE Commonly used to postpone recovery of specific tablespaces. The {tablespace_name} datafiles for these tablespaces will be marked offline during the recovery operations. C opyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 559 TABLE 13.9: THE RECOVER COMMAND PARAMETERS (CONTINUED) Parameter Description DELETE ARCHIVELOG Causes RMAN to remove archived redo logs after they are applied and no longer needed. CHECK READONLY Ensures that read-only files do not require recovery. The default is to not recover read-only tablespaces and datafiles. NOREDO Stops the application of redo logs during the recovery process and is used during the recovery of NOARCHIVELOG databases using incremental backups. The UNTIL Clause Both the RESTORE and RECOVER commands offer the use of the UNTIL clause. This clause allows you to specify which backup sets are recovered, based on time, SCN, or log sequence number. This is particularly useful for point-in-time recovery. The values you use with the UNTIL clause are high-limit values. All values less than the value listed will be recovered; any value equal to or greater than the value listed will not be recovered. Table 13.10 lists the parameters for this clause. TABLE 13.10: THE UNTIL CLAUSE PARAMETERS Parameter Description UNTIL TIME Specifies the end date for a series of archived redo log files. Date {‘NLS date string’} must be in NLS format and can include SYSDATE. UNTIL SCN {n} Defines the ending SCN for a sequence of archived redo logs. The default is to use the lowest SCN available. UNTIL LOGSEQ {n} Causes all archived redo logs to be recovered until the log sequence number specified. Reviewing RMAN Output RMAN creates a great deal of output during its operation. Because it can be so volumi- nous, we do not include the output from the commands in this chapter’s examples. It is worthwhile, however, to review some of the output that RMAN gives. Listing 13.3 provides an example of a successful RMAN backup operation. RUNNING RMAN Oracle Database Administration PART II C opyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. CHAPTER 13 • ORACLE8i RECOVERY MANAGER 560 Listing 13.3: Output from a Successful RMAN Operation D:\ORACLE\admin\ORA817\archive>rman target=’sys/robert@ora817 as sysdba’ nocatalog Recovery Manager: Release 8.1.7.0.0 - Production RMAN-06005: connected to target database: ORA817 (DBID=1598904557) RMAN-06009: using target database controlfile instead of recovery catalog RMAN> RUN 2> { 3> ALLOCATE CHANNEL d1 TYPE DISK; 4> BACKUP FULL (DATABASE 5> FORMAT “d:\oracle\admin\ora817\backup\ora817.full.%u”); 6> BACKUP CURRENT CONTROLFILE; 7> RELEASE CHANNEL d1; 8> } RMAN-03022: compiling command: allocate RMAN-03023: executing command: allocate RMAN-08030: allocated channel: d1 RMAN-08500: channel d1: sid=8 devtype=DISK RMAN-03022: compiling command: backup RMAN-03023: executing command: backup RMAN-08008: channel d1: starting full datafile backupset RMAN-08502: set_count=5 set_stamp=433943941 creation_time=01-JUL-01 RMAN-08010: channel d1: specifying datafile(s) in backupset RMAN-08522: input datafile fno=00001 name=D:\ORACLE\ORADATA\ORA817\SYSTEM01.DBF RMAN-08011: including current controlfile in backupset RMAN-08522: input datafile fno=00002 name=D:\ORACLE\ORADATA\ORA817\RBS01.DBF RMAN-08522: input datafile fno=00003 name=D:\ORACLE\ORADATA\ORA817\USERS01.DBF RMAN-08522: input datafile fno=00004 name=D:\ORACLE\ORADATA\ORA817\TEMP01.DBF RMAN-08522: input datafile fno=00006 name=D:\ORACLE\ORADATA\ORA817\INDX01.DBF RMAN-08522: input datafile fno=00005 name=D:\ORACLE\ORADATA\ORA817\TOOLS01.DBF RMAN-08013: channel d1: piece 1 created C opyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 561 RMAN-08503: piece handle=D:\ORACLE\ADMIN\ORA817\BACKUP\ORA817.FULL.05CTQTC5 comment=NONE RMAN-08525: backup set complete, elapsed time: 00:01:18 RMAN-03022: compiling command: backup RMAN-03023: executing command: backup RMAN-08008: channel d1: starting full datafile backupset RMAN-08502: set_count=6 set_stamp=433944019 creation_time=01-JUL-01 RMAN-08010: channel d1: specifying datafile(s) in backupset RMAN-08011: including current controlfile in backupset RMAN-08013: channel d1: piece 1 created RMAN-08503: piece handle=D:\ORACLE\ORA816\DATABASE\06CTQTEJ_1_1 comment=NONE RMAN-08525: backup set complete, elapsed time: 00:00:10 RMAN-03022: compiling command: release RMAN-03023: executing command: release RMAN-08031: released channel: d1 RMAN> exit; Recovery Manager complete. Notice that RMAN goes through a compile phase before the backup ever begins. The compile phase is where the syntax of the commands that are sent to RMAN are checked to make sure that they follow the command syntax conventions. Once the compile phase is complete, RMAN proceeds to execute the backup or recovery operation. In this output, the following line includes information about the backup operation: RMAN-08502: set_count=5 set_stamp=433943941 creation_time=01-JUL-01 The SET_COUNT value indicates the backup set identifier number (your first RMAN backup will have a SET_COUNT of 1, then 2, and so on). The SET_STAMP value is the current SCN. The CREATION_TIME value shows the date of the backup creation. Also notice in Listing 13.3 that the name of each database datafile that is to be backed up is logged, as is its location. The backup in Listing 13.3 actually consists of two different backup commands: a full backup and a backup of the current control file. Because there are two different backup operations, there will be two backup sets created: the actual full backup of the database and a separate backup set of the control file backup. The location and name of each piece of the backup sets are identified in the following lines: RMAN-08503: piece handle=D:\ORACLE\ADMIN\ORA817\BACKUP\ORA817.FULL.05CTQTC5 comment=NONE RUNNING RMAN Oracle Database Administration PART II C opyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. CHAPTER 13 • ORACLE8i RECOVERY MANAGER 562 RMAN-08503: piece handle=D:\ORACLE\ORA816\DATABASE\06CTQTEJ_1_1 comment=NONE The example defines a location other than the default for the first backup set piece (as well as the name of that piece). For the second piece, it takes the default name and directory location. Also notice that the elapsed time of each backup set is reported. This information is helpful to have when you want to schedule many different backups and you need to know how long the backups are taking. You can log the output from RMAN to a log file by using the MSGLOG parameter from the RMAN command line, as shown here: D:\ORACLE\admin\ORA817\archive>RMAN TARGET=’sys/robert@ora817 as sysdba’ nocatalog MSGLOG=d:\oracle\rman\output.log When this command is used, no output from RMAN will be generated to the console. Performing RMAN Backups Now that we have reviewed the basic RMAN commands, let’s look at the various methods that can be used to back up databases with RMAN. First, we will review the backup types. We will then look at performing the various types of backups. Next, we will cover backing up archived redo logs, making datafile copies, and creating duplex backups. TIP Through the media management layer, you can back up your databases on tape. However, disks tend to be much faster than tape when it comes to recovering your data- bases. For mission-critical databases, if you can afford the disk space, you might want to consider backing up to disk when building your backup and recovery strategies. Also, if you do not have a media management layer available, you can back up your databases to hard disks, and then have an operating system utility copy these backups to disk at a later time. Backup Types Associated with RMAN (and in some cases, backup and recovery in general) are some specific backup types: full backups, whole backups, incremental backups, hot (open) C opyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 563 backups, and cold (closed) backups. Let’s quickly review each of these types in a bit more detail. Incremental Backups Incremental backups allow you to back up just the changed blocks of a database. Incre- mental backups start with a level 0 backup, which is essentially a backup of the entire database. This is your base incremental backup. You then can proceed to perform a level 2 incremental backup, which will back up all changes since the last level 2 or lower backup. This is known as a differential backup. Once a week, you might opt to perform a level 1 incremental, which would back up all changes since the last level 0 backup. This is known as a cumulative backup. During the following week, you would continue with the level 2 differential backups, which would then back up only blocks changed since the level 1 cumulative backup. Thus, the level 1 cumulative backup serves to “wrap up” all of the changes reflected in the level 2 differential backups taken during the week into one backup image (allowing the weekly tapes to be reused). Here is an example of an incremental backup strategy for a four-week period: Mon. Tue. Wed. Thurs. Fri. Sat. Sun. Week 1 Base Diff. Diff. Diff. Diff. Diff. Diff. Week 2 Cum.* Diff. Diff. Diff. Diff. Diff. Diff. Week 3 Base** Diff. Diff. Diff. Diff. Diff. Diff. Week 4 Cum.* Diff. Diff. Diff. Diff. Diff. Diff. *Previous differential backups no longer required. **Previous base incremental and cumulative backups no longer required. In this example, we take a base incremental backup on Monday. On Tuesday through Sunday, we perform differential backups. On the following Monday, we per- form a cumulative backup. The cumulative backup saves all of the changes that were backed up by the differential backups taken over the week. As a result of the accumu- lation of the backups in one backup set, the differential backups are no longer needed for recovery, so we can reuse those tapes to perform this week’s worth of differential backups. On the following Monday, we perform a base incremental backup again, restarting the cycle. Incremental backups have the benefit of shortening the backup window and reducing the overall amount of backup storage requirements. If your network is already having bandwidth problems, incremental backups can help. Also, incremen- tal backups enable the recovery of data in objects affected by UNRECOVERABLE oper- ations. On the downside, incremental backups can cause the recovery window to grow, because more data needs to be read during the recovery operation. PERFORMING RMAN BACKUPS Oracle Database Administration PART II C opyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. CHAPTER 13 • ORACLE8i RECOVERY MANAGER 564 Full and Whole Backups A full backup of a database is a backup of the entire database. Oracle supports full backups of the Oracle database datafiles, image copies, tablespaces, control files, the entire database, and archived redo logs. Be aware that a full backup cannot be used as the base of an incremental backup. Any subsequent base incremental backup would still back up all of the blocks of the database, ignoring the full backup just taken. A whole backup includes all of the files of a database (full or incremental) and the control file. Thus, a full backup does not include the control file, whereas a whole backup does back up the control file. Hot (Open) and Cold (Closed) Backups An RMAN hot, or open, backup of a database is taken with the database up and run- ning. This type of backup is supported only if the database is in ARCHIVELOG mode. By its nature, a hot database backup is considered to be an inconsistent backup—that is, all the data in the database is not consistent to the same point in time. Therefore, recovery will require the application of archived and online redo logs to make the recovered objects consistent. An RMAN cold, or closed, backup is taken with the database mounted but not open. RMAN requires the database be mounted before it can perform a backup because it requires access to several of the V$ views that provide control file information. This type of backup is supported if the database is in ARCHIVELOG or NOARCHIVELOG mode (although most backups of a database in ARCHIVELOG mode are hot backups). A cold database backup is said to be consistent—that is, all the data in the database is consis- tent to the same point in time—if the database was shut down cleanly (with a SHUT- DOWN, SHUTDOWN IMMEDIATE, or SHUTDOWN TRANSACTIONAL command). Cold Backups in NOARCHIVELOG Mode As explained in Chapter 10, databases running in NOARCHIVELOG mode provide the DBA with a limited number of backup and recovery solutions. Quite limited in the case of physical backups—cold backups are the only option. NOTE Of course, you can perform a cold backup of a database in ARCHIVELOG mode as well. Just be sure to back up the related archived redo logs so you can perform the var- ious recoveries that are possible with a database in ARCHIVELOG mode. C opyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 565 Writing the Backup Script Although the BACKUP command can be run from the RMAN command line, it is usu- ally a much better idea to create the script in an operating system file that you can simply instruct RMAN to execute. The examples in this chapter take this approach. Fire up your favorite text editor, open a text file, and give it a name that conforms to your database naming conventions (d:\oracle\admin\ora817\recover_script\ rman_cold_backup.rman, in this example). Create the RUN script that will perform a RMAN cold backup, shown in Listing 13.4, and save the file. NOTE The default location for backup pieces is operating-system dependent. On NT systems, the location is $ORACLE_HOME\database. On Unix systems, the default location is $ORACLE_HOME/dbs. Listing 13.4: RMAN Cold Backup Script RUN { SHUTDOWN IMMEDIATE; STARTUP MOUNT; ALLOCATE CHANNEL d1 TYPE DISK; BACKUP FULL (DATABASE); RELEASE CHANNEL d1; ALTER DATABASE OPEN; } EXIT; This script shuts down the database and then mounts the database, as necessary for performing a cold backup (allowing access to the database control file). Note that you can use the PFILE= parameter with the STARTUP command if the init.ora file isn’t in the default location. WARNING If you wish to use RMAN to shut down and restart an Oracle database, you cannot use Oracle’s auto listener registration feature. Instead, you must manually con- figure the instance in the listener.ora file. Failure to do this may cause RMAN to fail to connect to the database. PERFORMING RMAN BACKUPS Oracle Database Administration PART II C opyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. [...]... feat, use the Oracle package DBMS_BACKUP_RESTORE, which RMAN uses to facilitate its own backup and recovery operations NOTE Unfortunately, the DBMS_BACKUP_RESTORE package is not documented anywhere (at least in the Oracle 8.1.7 documentation) Still, you can use its functions and procedures to recover a control file, as described in this section PA R T RMAN> LIST BACKUP OF CONTROLFILE; RMAN-03022: compiling... recovery) Again, these backups use the FORMAT command to format the name of this backup set as well (Recall that database datafiles and archived redo logs must be in separate backup sets.) N OTE Oracle’s documentation seems to suggest that you don’t need to force a log switch (at least most of their examples don’t include this) In reality, in some specific recovery situations (recovering changes that occurred... to target database: ORA817 (DBID=1598904557) RMAN-06009: using target database controlfile instead of recovery catalog RMAN> @d:\oracle\admin\ora817\recover_script\rman_cold_backup.rman N OTE Some RMAN documentation and some error messages indicate that certain RMAN failures are restartable, and even suggest there is a restart command This is not the case; however, this functionality may be made available . @d:oracleadminora817 ecover_script man_cold_backup.rman NOTE Some RMAN documentation and some error messages indicate that certain RMAN failures are. datafiles and archived redo logs must be in separate backup sets.) NOTE Oracle’s documentation seems to suggest that you don’t need to force a log switch (at