Tài liệu ORACLE8i- P15 doc

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.
CHAPTER 13 • ORACLE8i RECOVERY MANAGER
566
After mounting the database, the script allocates a channel called d1. This particu-
lar backup will be going to disk. It then executes the backup by using the BACKUP
FULL command, for a full database backup using the default parameters. Next, the
script releases the channel. This is not necessary, since the channel will be released
automatically after the RUN command is complete, but it is good practice to do it
explicitly. The final lines reopen the database for user access and then exit RMAN.
Performing the Backup

To perform the backup, start the RMAN interface. To run the script, you can use
the CMDFILE parameter of the RMAN executable to define the script to execute, as
shown here:
c:\>d:
d:\>CD \oracle\admin\ora817\recover_script
d:\oracle\admin\ora817\recover_script> rman TARGET=’sys/robert@ora817
as sysdba’
CMDFILE=rman_cold_backup.rman NOCATALOG
Or you can use the command-line parameter @ to indicate that you want to run a
specific file, as shown here:
C:\> RMAN TARGET=’sys/robert as sysdba@ora817’ 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> @d:\oracle\admin\ora817\recover_script\rman_cold_backup.rman
NOTE 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 in Oracle9i.
Backups in ARCHIVELOG Mode
Putting your database in ARCHIVELOG mode offers a much wider range of database
backup possibilities. The commands for each backup type are slightly different, but
the basic format stays the same. In this section, we will review the differences in the
C
opyright ©2002 SYBEX, Inc., Alameda, CA
www.sybex.com
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
567
scripts that are used to perform full database backups, tablespace backups, datafile
backups, and incremental backups. We will introduce some additional backup
options as well, such as formatting the backup piece names and changing the default

locations for the backup pieces.
Once you have the backup scripts written, you can run the scripts as described in
the previous section.
TIP The recovery catalog, which we will discuss later in this chapter, allows you to store
RMAN scripts within an Oracle database for later use. Consider this as one reason to create
a recovery catalog.
Full Database Backups
Listing 13.5 provides an example of a script that performs a full database backup of a
database in ARCHIVELOG mode. You can create this script in your favorite editor and
name and store it appropriately. In this example, we call it back_full_database.rman
and save it in the \oracle\admin\ora817\recover_script directory.
Listing 13.5: Full Database Backup Script
RUN
{
ALLOCATE CHANNEL d1 TYPE DISK;
BACKUP FULL (DATABASE
FORMAT “d:\oracle\admin\ora817\backup\ora817.full.%u”);
SQL “ALTER SYSTEM ARCHIVE LOG CURRENT”;
BACKUP CURRENT CONTROLFILE
FORMAT “d:\oracle\admin\ora817\backup\ora817.crtl.%u”;
BACKUP ARCHIVELOG ALL
DELETE INPUT
FORMAT “d:\oracle\admin\ora817\backup\ora817.arch.%u”;
RELEASE CHANNEL d1;
}
EXIT;
WARNING If you use the ALTER SYSTEM ARCHIVE LOG CURRENT command in the
BACKUP command, and no archived redo logs are present, the backup will fail.
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
568
Notice that this script does not shut down the database and then mount it. Since
the database is in ARCHIVELOG mode, you do not need to do this. We have again
allocated a channel to disk for the purposes of this backup. We then issue the
BACKUP FULL command, just as in the full backup in NOARCHIVELOG mode shown
in Listing 13.4. The BACKUP FULL simply indicates the type of backup, not what is
getting backed up. The keyword DATABASE indicates the scope of the backup and
what is getting backed up.
The BACKUP command in this example also contains the FORMAT keyword. Ear-
lier, we mentioned that the FORMAT command’s purpose is to format the naming
convention of the backup pieces, as well as to cause them to be created in a location
other than the default location. In this example, all of the backup pieces will be put
in the d:\oracle\admin\ora817\backup directory. The naming convention for these
backup pieces is also established here. Each backup piece will start with the name
ora817.full. The %u format string code represents an eight-character name made up
of compressed representations of the backup set number and the time the backup set
was created (Table 13.4 earlier in this chapter defines all the format codes).
Next, the script includes the BACKUP CURRENT CONTROLFILE command to back
up the control file after the database backup has been completed. This is useful if you
are using an RMAN recovery catalog. This control file backup will reflect the last
backup of the database that was taken. When recovery time comes around, you will
have the most current information on backups possible. If you were to restore the

control file backup taken at the time of the backup, that control file would not con-
tain any information about the backup that it was associated with. This is because the
control file is backed up first during a full backup.
Next, the script forces a log switch with the ALTER SYSTEM ARCHIVE LOG
CURRENT command, and then backs up the archived redo logs using the BACKUP
ARCHIVELOG ALL command. This is a really important step, and when and how it is
done can be critical to recovering your database in certain recovery situations (such as
time-based 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.)
NOTE 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 recov-
ery situations (recovering changes that occurred during the backup, for example), you will
not be able to recover your backup unless you switched the log file and backed it up.
C
opyright ©2002 SYBEX, Inc., Alameda, CA
www.sybex.com
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
569
Notice the DELETE INPUT keywords the script uses when backing up the archived
redo logs. This causes RMAN to delete the archived redo logs after they are backed up.
Finally, we release the channel and exit RMAN.
NOTE If you prefer to manually remove archived redo logs rather than allow RMAN to
do so, you will need to issue a CHANGE ARCHIVELOG ALL VALIDATE command. Failure to do
so may lead to occurrences of RMAN 6089 errors, and the archived redo log backup will fail.
Tablespace Backups
When backing up databases in ARCHIVELOG mode, you can opt to back up only
specific tablespaces rather than the whole database. When you back up a tablespace,
you are really backing up all of the database datafiles associated with that tablespace.
Oracle provides the tablespace backup option just to make the process a little easier

for you. Listing 13.6 provides an example of a script that is used to back up multiple
tablespaces of a database.
Listing 13.6: Tablespace Backup Script
RUN
{
ALLOCATE CHANNEL d1 TYPE DISK;
BACKUP FULL TABLESPACE rbs, users, tools
FORMAT “d:\oracle\admin\ora817\backup\ora817.tbs.%u”;
RELEASE CHANNEL d1;
}
EXIT;
In this example, we have simply changed the BACKUP command. Instead of using
the keyword DATABASE, we use the keyword TABLESPACE, followed by the names
of the tablespaces we wish to back up. We also changed the format of the backup set
piece naming conventions to indicate that this was a tablespace backup rather than a
database backup, but this is an optional step.
Datafile Backups
The most granular backup possible in RMAN is the datafile backup, although in real-
ity, all backups in RMAN are really just datafile backups. Even though RMAN provides
you with the ability to do database or tablespace backups, RMAN is still resolving the
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

570
objects to datafiles and backing up those datafiles. Listing 13.7 shows an example of a
script to back up two datafiles in a database.
Listing 13.7: Datafile Backup Script
RUN
{
ALLOCATE CHANNEL d1 TYPE DISK;
BACKUP FULL (DATAFILE 1, 2, 4
FORMAT “d:\oracle\admin\ora817\backup\ora817.dat.%u”)
(ARCHIVELOG ALL
FORMAT “d:\oracle\admin\ora817\backup\ora817.arch.%u”);
BACKUP CURRENT CONTROLFILE
FORMAT “d:\oracle\admin\ora817\backup\ora817.crtl.%u”;
RELEASE CHANNEL d1;
}
EXIT;
Notice that this example uses the datafile numbers, rather than the fully qualified
names. This just makes the DBA’s job a little easier. We could just have easily written
the command like this:
BACKUP FULL (DATAFILE ‘d:\oracle\oradata\ora817\system01.dbf’,
‘d:\oracle\oradata\ora817\rbs01.dbf’,
‘d:\oracle\oradata\ora817\temp01.dbf’,
FORMAT “d:\oracle\admin\ora817\backup\ora817.dat.%u”);
Incremental Backups
Incremental backups give you the option of backing up only that part of a database
that has been changed since the last incremental backup. For this type of backup, pre-
pare three scripts to perform each type of incremental backup: the full base incremen-
tal backup, the differential backup, and the cumulative backup.
Listing 13.8 shows the RMAN script to perform the base incremental backup.
Listing 13.8: Base Incremental Backup Script

RUN
{
ALLOCATE CHANNEL d1 TYPE DISK;
ALLOCATE CHANNEL d2 TYPE DISK;
BACKUP INCREMENTAL LEVEL 0 FILESPERSET 2 SETSIZE 70000
(DATABASE
FORMAT “d:\oracle\admin\ora817\backup\ora817.inc.%u”)
C
opyright ©2002 SYBEX, Inc., Alameda, CA
www.sybex.com
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
571
ARCHIVELOG ALL
FORMAT “d:\oracle\admin\ora817\backup\ora817.arch.%u”;
BACKUP CURRENT CONTROLFILE
FORMAT “d:\oracle\admin\ora817\backup\ora817.crtl.%u”;
RELEASE CHANNEL d1;
RELEASE CHANNEL d2;
}
First, notice that we have opened two different channels in this example. Each
channel will establish a new session with the Oracle server and make it available for
RMAN to use. RMAN will discover this is the case and try to take advantage of both
channels during the backup process. The allocation of multiple channels allows you
to parallelize the backup operation.
In the BACKUP command, we use the INCREMENTAL keyword to indicate that
this is an incremental backup rather than a full backup. Next, we specify the level of
the backup. Level 0 becomes the base incremental backup. This means that all the
used blocks of the database will be backed up. We have also added a couple new param-
eters in this example. The FILESPERSET parameter defines the maximum number of
backup pieces that will be allowed to be created for a given backup piece. The SETSIZE

parameter allows you to set the maximum size of any backup piece. You might use
this particular command if your operating system limits the size of an individual file,
for example. In this example, the 70000 indicates that a single backup piece will be
no larger than 70MB (since the values are in kilobytes). The FILESPERSET and SETSIZE
parameters can be used for either incremental or full backups.
To perform the differential backup, you simply change the level of the backup
from a 0 to a 2 (or 3 or 4, depending on our backup scheme). This is shown in the
script in Listing 13.9.
Listing 13.9: Differential Incremental Backup Script
RUN
{
ALLOCATE CHANNEL d1 TYPE DISK;
ALLOCATE CHANNEL d2 TYPE DISK;
BACKUP INCREMENTAL LEVEL 2 FILESPERSET 2 SETSIZE 70000
(DATABASE
FORMAT “d:\oracle\admin\ora817\backup\ora817.inc.%u”)
(ARCHIVELOG ALL
FORMAT “d:\oracle\admin\ora817\backup\ora817.arch.%u”);
BACKUP CURRENT CONTROLFILE
FORMAT “d:\oracle\admin\ora817\backup\ora817.crtl.%u”;
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

572
RELEASE CHANNEL d1;
RELEASE CHANNEL d2;
}
The main point here is that the level for the differential backups (which are the
backups you will make every day) needs to be higher than the once-every-two-weeks
base incremental (which is level 0). In addition, the level for this backup needs to be
higher than the once-a-week cumulative backup, which is a level 1 backup in our
strategy, as shown in Listing 13.10.
Listing 13.10: Cumulative Incremental Backup Script
RUN
{
SET COMMAND ID TO ‘RMAN IS ALLOCATING CHANNELS’;
ALLOCATE CHANNEL d1 TYPE DISK;
ALLOCATE CHANNEL d2 TYPE DISK;
SET COMMAND ID TO ‘RMAN IS BACKING UP’;
BACKUP INCREMENTAL LEVEL 1 FILESPERSET 2 SETSIZE 70000
(DATABASE
FORMAT “d:\oracle\admin\ora817\backup\ora817.inc.%u”)
(ARCHIVELOG ALL
FORMAT “d:\oracle\admin\ora817\backup\ora817.arch.%u”);
SET COMMAND ID TO ‘RMAN IS BACKING UP THE CONTROL FILE’;
BACKUP CURRENT CONTROLFILE;
SET COMMAND ID TO ‘RMAN IS DEALLOCATING CHANNELS’;
RELEASE CHANNEL d1;
RELEASE CHANNEL d2;
}
EXIT;
Notice that besides changing the level of the backup, we have also added several
SET COMMAND ID TO lines. This allows you to track the progress of the backup by

querying the CLIENT_INFO column of the V$SESSION view, as in this example:
SQL> SELECT sid, serial#, username, client_info
2 FROM v$session
3 WHERE client_info IS NOT NULL;
SID SERIAL# USERNAME CLIENT_INFO

9 83 SYS id=RMAN is backing up,ch=d2
12 43 SYS id=RMAN is backing up,ch=d1
13 16 SYS id=RMAN is backing up
C
opyright ©2002 SYBEX, Inc., Alameda, CA
www.sybex.com
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
573
Archived Redo Log Backups
The previous listings include backing up archived redo logs, but we thought it would
be nice to provide a simple RMAN script that does just that. Listing 13.11 provides
such a script.
Listing 13.11: Archived Redo Log Backup Script
RUN
{
ALLOCATE CHANNEL d1 TYPE DISK;
SQL “ALTER SYSTEM ARCHIVE LOG CURRENT”;
BACKUP (ARCHIVELOG ALL
DELETE INPUT
FORMAT “d:\oracle\admin\ora817\backup\ora817.arch.%u”);
RELEASE CHANNEL d1;
}
EXIT;
NOTE The log file switch in this example is not required, but it does prevent RMAN from

returning an error if no log files are available to back up.
Datafile Copies
Datafile copies, also called image copies, are exact copies of database datafiles that are
just copied elsewhere and given an RMAN naming convention. Datafile copies can
only be made to disk; copies to tape are not supported.
To make a datafile copy, use the COPY command. Datafile, archived redo logs, and
control files can be backed up using the COPY command. Note that image copies are
exact copies of the physical files, and they are not part of any RMAN backup set.
The optional parameters for the COPY command include the following:
• TAG {tag name} associates a tag name to the backup that can be used as an alias
to the backup.
• LEVEL{n} includes the copy in the incremental backup strategy.
• NOCHECKSUM disables block checksum calculations.
• CHECK LOGICAL enables data and index logical block checking.
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
574
The input file parameter defines the type of input file. The following parameters
are valid:
• DATAFILE {datafileSpec} lists the datafile names or absolute file numbers to
back up.
• DATAFILECOPY lists one or more datafiles copies that should be used as the

input. This datafile cannot be listed in the database as a current datafile.
• ARCHIVELOG ‘filename’ defines the filename of an archived redo log to copy.
• CURRENT CONTROLFILE specifies that the copy should be of the current con-
trol file.
• CONTROLFILECOPY ‘filename’ defines the filename of the control file(s) to
copy. This control file copy will be marked as a backup control file, so its use will
require database recovery, just as a backup control file would.
Finally, the TO ‘filename’ parameter defines where the copy is to be made and what
its name should be.
An example of this command is shown in Listing 13.12.
Listing 13.12: Datafile Copying
RUN
{
ALLOCATE CHANNEL ch1 TYPE DISK;
COPY datafile 1 TO
‘c:\oracle\mydb\backup\070101\system_backup_01.dbf’;
current controlfile TO ‘c:\oracle\mydb\backup\070101\control.ctl’;
}
The LIST COPY command can be used to inventory the datafile copies that RMAN
has performed. To recover datafile copies, simply use the operating system copy com-
mand to move them back into place (there is no special RMAN command to perform
this function). You can also use the RMAN SWITCH command and the SET {newname}
command to cause the database to switch to using the datafile copy, if you do not
wish to move the datafile copy first.
NOTE Consistency rules apply to datafile copies. The database must not be open when
you make a datafile copy or the tablespace must be in hot backup mode.
C
opyright ©2002 SYBEX, Inc., Alameda, CA
www.sybex.com
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.

575
Duplexing Backups
When you duplex a backup, you make two copies of that backup at the same time to
further protect the backups from some failure or disaster. You can duplex a backup by
using the SET DUPLEX command, as shown in Listing 13.13.
Listing 13.13: Duplexing a Backup
RUN
{
SET DUPLEX=2;
ALLOCATE CHANNEL d1 TYPE ‘SBT_TAPE‘;
SQL “ALTER SYSTEM ARCHIVE LOG CURRENT”;
BACKUP (ARCHIVELOG ALL
DELETE INPUT
FORMAT “d:\oracle\admin\ora817\backup\ora817.arch.%u”);
RELEASE CHANNEL d1;
}
EXIT;
This example creates two separate backups to tape of the archived redo logs. Each
backup will be to a different backup set name; thus, the backups remain unique.
Performing RMAN Recovery Operations
Your options for recovering your RMAN backups depend on whether your database is
in NOARCHIVELOG mode or ARCHIVELOG mode. As you’ve learned, your options
with a NOARCHIVELOG mode database recovery are limited. The following sections
describe how to recover in both modes, including point-in-time or point-of-failure
recovery in ARCHIVELOG mode. You will also learn how to recover archived redo
logs, control files, and datafiles to another location.
NOARCHIVELOG Mode Backup Recovery
With a NOARCHIVELOG mode database recovery, you do not have the option of
point-in-time recovery or recovery to the point of failure. All you can do is recover
the datafiles from the last good backup and restart the database.

To recover a database in NOARCHIVELOG mode, the database must be mounted
but not open. This assumes that you have the control file available. If the control
file has been lost and you are not using a recovery catalog, then you should have
PERFORMING RMAN RECOVERY OPERATIONS
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
576
implemented a plan to back up the control file. You will need to recover this control
file before you can perform a recovery. The control file should be either a copy of the
database control file that was taken after the backup of the database (with the data-
base still down) or a backup control file (the result of an ALTER DATABASE BACKUP
CONTROL FILE TO ‘filename’ command).
What are the ramifications of not having a control file backup that is current? The
biggest problem is that you will not be able to recover the database backups that
RMAN has taken without a lot of grief. However, if you are using an RMAN recovery
catalog, recovering after the loss of a control file is much easier. Using a recovery cata-
log is described later in this chapter, in the “Using the Recovery Catalog” section.
Preparing for the Recovery
Listing 13.14 shows a script with the commands to prepare for and start the
NOARCHIVELOG mode recovery. You can create this script and save it in an appropri-
ately named file (this example is named recover_db.rman). It assumes that there is a
current backup of the database and that the control file has been recovered.
Listing 13.14: RMAN Database Recovery Script

RUN
{
SHUTDOWN ABORT;
STARTUP MOUNT;
ALLOCATE CHANNEL d1 TYPE DISK;
RESTORE DATABASE;
RECOVER DATABASE;
RELEASE CHANNEL d1;
ALTER DATABASE OPEN;
}
EXIT;
This script shuts down the database (assuming it is still up) and then mounts it. It
then allocates a channel to disk to facilitate the restore process, restores the database
datafiles with the RESTORE command, and performs the database recovery with the
RECOVER command. Finally, it releases the channel, opens the database for use, and
exits RMAN.
Performing the Recovery
To perform the recovery in this example, we decided to just cut and paste the RUN
command at the RMAN prompt and let it do its thing, as shown in Listing 13.15. We
C
opyright ©2002 SYBEX, Inc., Alameda, CA
www.sybex.com
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
577
will break with the typical format of this chapter and show you the output from this
recovery run.
Listing 13.15: RMAN Database Recovery Execution
C:\>SET ORACLE_SID=ora817
C:\>RMAN TARGET=sys/robert 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> SHUTDOWN ABORT;
4> STARTUP MOUNT;
5> ALLOCATE CHANNEL d1 TYPE DISK;
6> RESTORE DATABASE;
7> RECOVER DATABASE;
8> RELEASE CHANNEL d1;
9> ALTER DATABASE OPEN;
10> }
RMAN-03022: compiling command: shutdown
RMAN-06402: Oracle instance shut down
RMAN-03022: compiling command: startup
RMAN-06193: connected to target database (not started)
RMAN-06196: Oracle instance started
RMAN-06199: database mounted
Total System Global Area 7665692 bytes
Fixed Size 75804 bytes
Variable Size 6463488 bytes
Database Buffers 1048576 bytes
Redo Buffers 77824 bytes
RMAN-03022: compiling command: allocate
RMAN-03023: executing command: allocate
PERFORMING RMAN RECOVERY OPERATIONS
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
578
RMAN-08030: allocated channel: d1
RMAN-08500: channel d1: sid=10 devtype=DISK
RMAN-03022: compiling command: restore
RMAN-03022: compiling command: IRESTORE
RMAN-03023: executing command: IRESTORE
RMAN-08016: channel d1: starting datafile backupset restore
RMAN-08502: set_count=39 set_stamp=434068604 creation_time=02-JUL-01
RMAN-08089: channel d1: specifying datafile(s) to restore from backup set
RMAN-08523: restoring datafile 00001 to
D:\ORACLE\ORADATA\ORA817\SYSTEM01.DBF
RMAN-08523: restoring datafile 00002
to D:\ORACLE\ORADATA\ORA817\RBS01.DBF
RMAN-08523: restoring datafile 00003 to
D:\ORACLE\ORADATA\ORA817\USERS01.DBF
RMAN-08523: restoring datafile 00004 to
D:\ORACLE\ORADATA\ORA817\TEMP01.DBF
RMAN-08523: restoring datafile 00005 to
D:\ORACLE\ORADATA\ORA817\TOOLS01.DBF
RMAN-08523: restoring datafile 00006 to
D:\ORACLE\ORADATA\ORA817\INDX01.DBF
RMAN-08023: channel d1: restored backup piece 1
RMAN-08511: piece handle=D:\ORACLE\ORA816\DATABASE\17CTUN3S_1_1
tag=null params=NULL
RMAN-08024: channel d1: restore complete

RMAN-03022: compiling command: recover
RMAN-03022: compiling command: recover(1)
RMAN-03022: compiling command: recover(2)
RMAN-03022: compiling command: recover(3)
RMAN-03023: executing command: recover(3)
RMAN-08054: starting media recovery
RMAN-08055: media recovery complete
RMAN-03022: compiling command: recover(4)
RMAN-03022: compiling command: release
RMAN-03023: executing command: release
RMAN-08031: released channel: d1
RMAN-03022: compiling command: alter db
RMAN-06400: database opened
C
opyright ©2002 SYBEX, Inc., Alameda, CA
www.sybex.com
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
579
RMAN> EXIT;
Recovery Manager complete.
In this example, we accessed the database directly by setting the SID and using
sys/robert as the connect string. In previous examples, we used a Net8 connect string
(like sys/robert@ora817). Either way is valid, although you may find that there are
times that connecting to a target database through Net8 doesn’t work very well. Also,
connecting to the target through Net8 adds overhead to the recovery process.
NOTE If you are using automated instance registration with your listener, you may find
that Net8 connections don’t always work if you shut down the database and then try to
start it up again. Sometimes, the listener will release the service and not recognize it when
RMAN tries to attach again. If you wish to perform RMAN startup and shutdown operations
through Net8, you will need to manually register the database service in the

listener
.ora file.
Notice in the listing that RMAN automatically selected the most recent backup to
recover from. We just told it to restore the most recent datafiles and recover the data-
base. RMAN took care of the rest; heck, it even opened our database for us!
ARCHIVELOG Mode Complete Recovery
RMAN, by default, will recover the database to the point of failure during a restore
operation for a database that is in ARCHIVELOG mode. You can also do point-in-time
recoveries (which is probably why you put the database in ARCHIVELOG mode and
bought that extra disk space for those archived redo logs anyway), which we will dis-
cuss in the “Incomplete Recovery in ARCHIVELOG Mode” section later in this chapter.
RMAN allows you to recover the entire database, a tablespace or a number of table-
spaces, or a database datafile or a number of database datafiles. RMAN also allows you
to take a tablespace or datafile offline and bring it back online again; both of these
operations may be required or desired during a recovery.
The recovery methods do not change, regardless if you have performed full or
incremental backups. RMAN is smart enough to determine which backups need to be
recovered and which will cause the recovery to happen the fastest.
The following sections show recovery scripts for the entire database, for specific
tablespace recoveries, and for individual database datafiles. You will find all three
scripts are similar, with only a few changes to the RESTORE command and some addi-
tional statements to take tablespaces or datafiles offline. You can save these scripts in
PERFORMING RMAN RECOVERY OPERATIONS
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
580
a RMAN command file and run them, or cut and paste them at the RMAN prompt. If
you have a recovery catalog, a third alternative is to store the scripts there. We will
discuss this possibility in more detail later in this chapter.
Full Database Recovery
The recovery process is pretty straightforward here—you simply issue the RESTORE
and RECOVERY commands. RMAN will take care of the rest automatically. It will find
the most current backups, apply them, and then recover the database applying the
archived redo logs (including restoring them if required) to make the database cur-
rent. The script for a full database recovery is shown in Listing 13.16.
Listing 13.16: RMAN Full Database Recovery Script
RUN
{
SHUTDOWN IMMEDIATE
STARTUP MOUNT
ALLOCATE CHANNEL d1 TYPE DISK;
RESTORE DATABASE;
RECOVER DATABASE;
RELEASE CHANNEL d1;
ALTER DATABASE OPEN;
}
EXIT;
Note that you may not need the SHUTDOWN command if the database has
already shut itself down (and indeed RMAN will generate an error if this is the case).
NOTE If you have lost your online redo logs, this procedure will not work. Refer to the
section on incomplete recovery for information on how to deal with this situation.
Tablespace Recovery
The script for recovering a tablespace, shown in Listing 13.17, is only slightly differ-

ent than one for recovering the entire database. In this script, we assume that the
INDX tablespace has gone AWOL and we need to recover it. We also assume that the
tablespace is offline.
C
opyright ©2002 SYBEX, Inc., Alameda, CA
www.sybex.com
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.