Tài liệu ORACLE8i- P15 doc

Listing 13.2: RMAN Database Recovery Script RUN{ALLOCATE CHANNEL d1 TYPE DISK; RESTORE DATABASE; RECOVER DATABASE; RELEASE CHANNEL d1; }EXIT;... The RESTORE CommandThe purpose of the RES

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 archivedredo 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 notsupport 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 anRMAN 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 aspoint-in-time recovery (which we will discuss later in this chapter) A typical recoveryscript, 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;

The RESTORE Command

The purpose of the RESTORE command is to restore database datafiles, archived redologs, or control files from RMAN backups in preparation for recovering from somesort 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 beused (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 mand are valid No actual restore is performed

com-CHECK LOGICAL Checks the database and index blocks for any logical corruption

(RMAN automatically checks for physical corruption.) RMAN logsany logical corruption found to the V$BACKUP_CORRUPTION orV$COPY_CORRUPTION data dictionary views, unless the valuefor MAXCORRUPT is exceeded The corrupt blocks are alsologged in the alert log and a process trace file

CHECK READONLY Causes RMAN to check and restore any read-only database

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 pathname 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 thecontrolfile command for that operation) Offline and read-onlydatafiles are not restored unless the CHECK READONLY option isselected 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 pathname) 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 torecover a database You can recover the entire database, one or more tablespaces, ordatafiles You can perform point-in-time recovery (which we will discuss later in thischapter) with the RECOVER command as well Table 13.9 summarizes the parametersfor 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 thecontrol 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

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 databasesusing incremental backups

The UNTIL Clause

Both the RESTORE and RECOVER commands offer the use of the UNTIL clause Thisclause allows you to specify which backup sets are recovered, based on time, SCN, orlog sequence number This is particularly useful for point-in-time recovery The valuesyou use with the UNTIL clause are high-limit values All values less than the valuelisted will be recovered; any value equal to or greater than the value listed will not berecovered Table 13.10 lists the parameters for this clause

TABLE 13.10: THE UNTIL CLAUSE PARAMETERS

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 nous, we do not include the output from the commands in this chapter’s examples It

volumi-is worthwhile, however, to review some of the output that RMAN gives Lvolumi-isting 13.3provides an example of a successful RMAN backup operation

Oracle Database Administration

P A R T

II

Listing 13.3: Output from a Successful RMAN Operation

D:\ORACLE\admin\ORA817\archive>rmantarget=’sys/robert@ora817 as sysdba’ nocatalogRecovery Manager: Release 8.1.7.0.0 - ProductionRMAN-06005: connected to target database: ORA817 (DBID=1598904557)RMAN-06009: using target database controlfile instead of recovery catalogRMAN> RUN

2> {3> ALLOCATE CHANNEL d1 TYPE DISK;

4> BACKUP FULL (DATABASE5> FORMAT “d:\oracle\admin\ora817\backup\ora817.full.%u”);

6> BACKUP CURRENT CONTROLFILE;

7> RELEASE CHANNEL d1;

8> }

RMAN-03022: compiling command: allocateRMAN-03023: executing command: allocateRMAN-08030: allocated channel: d1RMAN-08500: channel d1: sid=8 devtype=DISK

RMAN-03022: compiling command: backupRMAN-03023: executing command: backupRMAN-08008: channel d1: starting full datafile backupsetRMAN-08502: set_count=5 set_stamp=433943941 creation_time=01-JUL-01RMAN-08010: channel d1: specifying datafile(s) in backupset

RMAN-08522: input datafile fno=00001name=D:\ORACLE\ORADATA\ORA817\SYSTEM01.DBFRMAN-08011: including current controlfile in backupsetRMAN-08522: input datafile fno=00002

name=D:\ORACLE\ORADATA\ORA817\RBS01.DBFRMAN-08522: input datafile fno=00003name=D:\ORACLE\ORADATA\ORA817\USERS01.DBFRMAN-08522: input datafile fno=00004name=D:\ORACLE\ORADATA\ORA817\TEMP01.DBFRMAN-08522: input datafile fno=00006name=D:\ORACLE\ORADATA\ORA817\INDX01.DBFRMAN-08522: input datafile fno=00005name=D:\ORACLE\ORADATA\ORA817\TOOLS01.DBFRMAN-08013: channel d1: piece 1 created

RMAN-08503: piecehandle=D:\ORACLE\ADMIN\ORA817\BACKUP\ORA817.FULL.05CTQTC5comment=NONE

RMAN-08525: backup set complete, elapsed time: 00:01:18RMAN-03022: compiling command: backup

RMAN-03023: executing command: backupRMAN-08008: channel d1: starting full datafile backupsetRMAN-08502: set_count=6 set_stamp=433944019 creation_time=01-JUL-01RMAN-08010: channel d1: specifying datafile(s) in backupset

RMAN-08011: including current controlfile in backupsetRMAN-08013: channel d1: piece 1 created

RMAN-08503: piecehandle=D:\ORACLE\ORA816\DATABASE\06CTQTEJ_1_1 comment=NONERMAN-08525: backup set complete, elapsed time: 00:00:10RMAN-03022: compiling command: release

RMAN-03023: executing command: releaseRMAN-08031: released channel: d1RMAN> exit;

Recovery Manager complete

Notice that RMAN goes through a compile phase before the backup ever begins Thecompile 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 compilephase 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-01The SET_COUNT value indicates the backup set identifier number (your first RMANbackup will have a SET_COUNT of 1, then 2, and so on) The SET_STAMP value is thecurrent SCN The CREATION_TIME value shows the date of the backup creation Alsonotice 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: afull backup and a backup of the current control file Because there are two differentbackup operations, there will be two backup sets created: the actual full backup of thedatabase 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: piecehandle=D:\ORACLE\ADMIN\ORA817\BACKUP\ORA817.FULL.05CTQTC5comment=NONE

Oracle Database Administration

P A R T

II

RMAN-08503: piecehandle=D:\ORACLE\ORA816\DATABASE\06CTQTEJ_1_1comment=NONE

The example defines a location other than the default for the first backup set piece (aswell as the name of that piece) For the second piece, it takes the default name anddirectory 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 parameterfrom the RMAN command line, as shown here:

D:\ORACLE\admin\ORA817\archive>RMAN TARGET=’sys/robert@ora817 assysdba’ 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 variousmethods that can be used to back up databases with RMAN First, we will review thebackup types We will then look at performing the various types of backups Next, wewill cover backing up archived redo logs, making datafile copies, and creating duplexbackups

TI P 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 toconsider 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 harddisks, 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 somespecific backup types: full backups, whole backups, incremental backups, hot (open)

backups, and cold (closed) backups Let’s quickly review each of these types in a bitmore 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 changedsince 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 duringthe week into one backup image (allowing the weekly tapes to be reused) Here is anexample of an incremental backup strategy for a four-week period:

*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 Tuesdaythrough Sunday, we perform differential backups On the following Monday, we per-form a cumulative backup The cumulative backup saves all of the changes that werebacked 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 neededfor recovery, so we can reuse those tapes to perform this week’s worth of differentialbackups On the following Monday, we perform a base incremental backup again,restarting the cycle

Incremental backups have the benefit of shortening the backup window andreducing the overall amount of backup storage requirements If your network isalready 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 togrow, because more data needs to be read during the recovery operation

Oracle Database Administration

P A R T

II

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, theentire database, and archived redo logs Be aware that a full backup cannot be used asthe base of an incremental backup Any subsequent base incremental backup wouldstill 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 wholebackup 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 therecovered 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 itrequires 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 colddatabase 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 theDBA with a limited number of backup and recovery solutions Quite limited in thecase 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 ious recoveries that are possible with a database in ARCHIVELOG mode

var-Writing the Backup Script

Although the BACKUP command can be run from the RMAN command line, it is ally a much better idea to create the script in an operating system file that you cansimply instruct RMAN to execute The examples in this chapter take this approach

usu-Fire up your favorite text editor, open a text file, and give it a name that conforms toyour database naming conventions (d:\oracle\admin\ora817\recover_script\

rman_cold_backup.rman, in this example) Create the RUN script that will perform aRMAN cold backup, shown in Listing 13.4, and save the file

NOTE The default location for backup pieces is operating-system dependent On NTsystems, the location is $ORACLE_HOME\database On Unix systems, the default location

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 necessaryfor performing a cold backup (allowing access to the database control file) Note thatyou can use the PFILE= parameter with the STARTUP command if the init.ora fileisn’t in the default location

WARN I NG 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.orafile Failure to do this may cause RMAN to fail toconnect to the database

Oracle Database Administration

P A R T

II

After mounting the database, the script allocates a channel called d1 This lar backup will be going to disk It then executes the backup by using the BACKUPFULL command, for a full database backup using the default parameters Next, thescript releases the channel This is not necessary, since the channel will be releasedautomatically after the RUN command is complete, but it is good practice to do itexplicitly The final lines reopen the database for user access and then exit RMAN.

particu-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, asshown here:

c:\>d:

d:\>CD \oracle\admin\ora817\recover_scriptd:\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 aspecific 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

N OTE Some RMAN documentation and some error messages indicate that certainRMAN failures are restartable, and even suggest there is a restart command This is not thecase; 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 databasebackup possibilities The commands for each backup type are slightly different, butthe basic format stays the same In this section, we will review the differences in the

scripts that are used to perform full database backups, tablespace backups, datafilebackups, and incremental backups We will introduce some additional backupoptions as well, such as formatting the backup piece names and changing the defaultlocations for the backup pieces.

Once you have the backup scripts written, you can run the scripts as described inthe previous section

TIP The recovery catalog, which we will discuss later in this chapter, allows you to storeRMAN 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 adatabase in ARCHIVELOG mode You can create this script in your favorite editor andname and store it appropriately In this example, we call it back_full_database.rmanand 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 (DATABASEFORMAT “d:\oracle\admin\ora817\backup\ora817.full.%u”);

SQL “ALTER SYSTEM ARCHIVE LOG CURRENT”;

BACKUP CURRENT CONTROLFILEFORMAT “d:\oracle\admin\ora817\backup\ora817.crtl.%u”;

BACKUP ARCHIVELOG ALLDELETE INPUT

FORMAT “d:\oracle\admin\ora817\backup\ora817.arch.%u”;

RELEASE CHANNEL d1;

}EXIT;

WARN I NG If you use the ALTER SYSTEM ARCHIVE LOG CURRENT command in theBACKUP command, and no archived redo logs are present, the backup will fail

Oracle Database Administration

P A R T

II

Notice that this script does not shut down the database and then mount it Sincethe database is in ARCHIVELOG mode, you do not need to do this We have againallocated a channel to disk for the purposes of this backup We then issue theBACKUP 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 isgetting backed up The keyword DATABASE indicates the scope of the backup andwhat is getting backed up

The BACKUP command in this example also contains the FORMAT keyword lier, we mentioned that the FORMAT command’s purpose is to format the namingconvention of the backup pieces, as well as to cause them to be created in a locationother than the default location In this example, all of the backup pieces will be put

Ear-in the d:\oracle\admEar-in\ora817\backup directory The namEar-ing convention for thesebackup pieces is also established here Each backup piece will start with the nameora817.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 setwas 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 youare using an RMAN recovery catalog This control file backup will reflect the lastbackup of the database that was taken When recovery time comes around, you willhave the most current information on backups possible If you were to restore thecontrol 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 thecontrol 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 BACKUPARCHIVELOG ALL command This is a really important step, and when and how it isdone can be critical to recovering your database in certain recovery situations (such astime-based recovery) Again, these backups use the FORMAT command to format thename of this backup set as well (Recall that database datafiles and archived redo logsmust be in separate backup sets.)

N OTE Oracle’s documentation seems to suggest that you don’t need to force a logswitch (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 willnot be able to recover your backup unless you switched the log file and backed it up

Notice the DELETE INPUT keywords the script uses when backing up the archivedredo 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 easierfor you Listing 13.6 provides an example of a script that is used to back up multipletablespaces of a database

Listing 13.6: Tablespace Backup Script

RUN{ALLOCATE CHANNEL d1 TYPE DISK;

BACKUP FULL TABLESPACE rbs, users, toolsFORMAT “d:\oracle\admin\ora817\backup\ora817.tbs.%u”;

RELEASE CHANNEL d1;

}EXIT;

In this example, we have simply changed the BACKUP command Instead of usingthe 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 setpiece naming conventions to indicate that this was a tablespace backup rather than adatabase backup, but this is an optional step

Datafile Backups

The most granular backup possible in RMAN is the datafile backup, although in ity, all backups in RMAN are really just datafile backups Even though RMAN providesyou with the ability to do database or tablespace backups, RMAN is still resolving the

real-Oracle Database Administration

P A R T

II

objects to datafiles and backing up those datafiles Listing 13.7 shows an example of ascript 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, 4FORMAT “d:\oracle\admin\ora817\backup\ora817.dat.%u”)(ARCHIVELOG ALL

Notice that this example uses the datafile numbers, rather than the fully qualifiednames This just makes the DBA’s job a little easier We could just have easily writtenthe 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 databasethat 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”)

ARCHIVELOG ALLFORMAT “d:\oracle\admin\ora817\backup\ora817.arch.%u”;

BACKUP CURRENT CONTROLFILEFORMAT “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 Eachchannel will establish a new session with the Oracle server and make it available forRMAN to use RMAN will discover this is the case and try to take advantage of bothchannels 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 thatthis is an incremental backup rather than a full backup Next, we specify the level ofthe backup Level 0 becomes the base incremental backup This means that all theused 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 ofbackup pieces that will be allowed to be created for a given backup piece The SETSIZEparameter allows you to set the maximum size of any backup piece You might usethis 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 SETSIZEparameters can be used for either incremental or full backups

To perform the differential backup, you simply change the level of the backupfrom a 0 to a 2 (or 3 or 4, depending on our backup scheme) This is shown in thescript 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

RELEASE CHANNEL d1;

RELEASE CHANNEL d2;

}The main point here is that the level for the differential backups (which are thebackups you will make every day) needs to be higher than the once-every-two-weeksbase incremental (which is level 0) In addition, the level for this backup needs to behigher than the once-a-week cumulative backup, which is a level 1 backup in ourstrategy, 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 severalSET COMMAND ID TO lines This allows you to track the progress of the backup byquerying 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

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 providessuch a script

Listing 13.11: Archived Redo Log Backup Script

RUN{ALLOCATE CHANNEL d1 TYPE DISK;

SQL “ALTER SYSTEM ARCHIVE LOG CURRENT”;

BACKUP (ARCHIVELOG ALLDELETE 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 fromreturning 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 arejust copied elsewhere and given an RMAN naming convention Datafile copies canonly be made to disk; copies to tape are not supported

To make a datafile copy, use the COPY command Datafile, archived redo logs, andcontrol files can be backed up using the COPY command Note that image copies areexact 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

Oracle Database Administration

P A R T

II

The input file parameter defines the type of input file The following parametersare 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 theinput 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 trol file

con-• 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 willrequire 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;

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 notwish to move the datafile copy first

NOTE Consistency rules apply to datafile copies The database must not be open whenyou make a datafile copy or the tablespace must be in hot backup mode

Duplexing Backups

When you duplex a backup, you make two copies of that backup at the same time tofurther protect the backups from some failure or disaster You can duplex a backup byusing 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 ALLDELETE 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 Eachbackup 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 optionswith a NOARCHIVELOG mode database recovery are limited The following sectionsdescribe how to recover in both modes, including point-in-time or point-of-failurerecovery in ARCHIVELOG mode You will also learn how to recover archived redologs, control files, and datafiles to another location

NOARCHIVELOG Mode Backup Recovery

With a NOARCHIVELOG mode database recovery, you do not have the option ofpoint-in-time recovery or recovery to the point of failure All you can do is recoverthe datafiles from the last good backup and restart the database

To recover a database in NOARCHIVELOG mode, the database must be mountedbut 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

Oracle Database Administration

P A R T

II