Thông tin tài liệu
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
Ngày đăng: 22/01/2014, 00:20
Xem thêm: Tài liệu ORACLE8i- P15 doc, Tài liệu ORACLE8i- P15 doc, Migrating an Existing 7.1+ Database to Oracle8i