'; zhtm += ''; zhtm += '

' + pPage + ''; zhtm += '
'; figDoc.write(zhtm); figDoc.close(); popUpWin.focus(); } //--> Using Oracle8 -- Chapter 15 - Using Recovery Manager for Backup and Recovery

Using Oracle8


Chapter 15

Using Recovery Manager for Backup and Recovery


Defining Recovery Manager

The most important responsibility for any computer system manager is maintaining a good, solid backup procedure. Whether you manage a large data center with many systems or just your own PC, you need to be prepared in case of a system failure.

Recovery Manager is the utility provided with the Oracle Server software that's used to perform database backups and restores. Recovery Manager is supported under Oracle8 and later and replaces the Enterprise Backup Utility (EBU) provided with Oracle7. It offers more than traditional cold backups via the operating system-it even offers online backups with the tablespaces in hot backup mode.

Recovery Manager has two user interfaces; this chapter focuses on the command-line interface, which you access through the rman utility. Most of you will use Recovery Manager and the recovery catalog to back up multiple databases, and will want to automate those operations. You can use the Backup Manager if you prefer a GUI-based interface; it comes with the Oracle Enterprise Manager software shown in Figure 15.1 (for those of you running Microsoft Windows on some of your client PCs). The OEM is covered in Chapter 4 "Managing with Oracle Enterprise Manager (OEM)."

Figure 15.1 : Oracle Enterprise Manager is your entry point to the GUI version of Recovery Manager.

Recovery Manager becomes an indispensable tool when used with a recovery catalog. A recovery catalog takes the form of an Oracle schema stored in a database separate from the databases you're backing up; it maintains all information relevant to the structure and backup history of the databases it backs up. What this means is that in case of a system failure, Recovery Manager can handle all tasks relevant to getting the database back up and running.

Recovery Manager can perform backups, store backup and restore scripts that can be executed repeatedly, and offer a wide range of options for backing up your databases.

Recovery Manager will back up and restore Oracle databases that are running Oracle Server version 8.0 and later. You should continue using Oracle Enterprise Backup Utility (EBU) or whatever homegrown backup procedures you have for Oracle7 databases.

Backing Up the Whole Database or Specific Parts

You can back up your database in several different ways via Recovery Manager. By specifying a full backup, Recovery Manager will back up all your data files or all your archive logs, but not both. You can write the backup to disk or tape.

Full backup workaround
There's one quick way around the full backup restriction of not being able to back up the archived logs with the data files: Perform a full backup of the archive logs right after the back-up of the data files within the same backup script.

When performing a full backup, Recovery Manager skips over database blocks that have never been used, thus speeding the backup operation. A full backup doesn't reset the individual database blocks' "backup flag." The next incremental backup will back up all database blocks modified since the previous incremental backup. The full backup has no impact on what's backed up during an incremental backup.

You can perform incremental backups on the data file, tablespace, or database level. During an incremental backup, Recovery Manager backs up all database blocks that have been modified since the last incremental backup. Again, database blocks that have never been used are skipped over.

Backup Sets and Image Copies

Recovery Manager supports two different output formats for backup and restore operations:

Sizing backup sets
Because multiple database files are written into a single backup set, you run the risk of exceeding your particular operating system platform's maximum file size. For example, if you're using Sun Solaris 2.51, you have a 2GB restriction on file size. Recovery Manager allows you to specify how many files to put in a backup set and how large the back-up set file can become. If the back-up set reaches its maximum size, the file is closed and a new backup set file is created. By tweaking Recovery Manager backup parameters a little, you shouldn't have any problems with file-system restrictions.

Stored Scripts

Recovery Manager lets you define backup operations in the form of scripts. Those scripts can be stored in disk files or can be loaded into the recovery catalog in much the same way a PL/SQL script is stored in the Oracle server. By using stored scripts, you reduce the possibility of operators performing backups introducing errors. You must have the recovery catalog installed to use stored scripts. You learn about how to create a stored script later in the "Recovery Manager Scripting Commands" section.

Parallel Operations

Recovery Manager can run backups and restores in parallel. If your system has more than one tape drive, Recovery Manager can use both of them at the same time, cutting the elapsed time required for the backup. This will work for disk-to-disk and disk-to-tape backup operations. How the parallelization is done is automatic, and is set on or off in the backup command you use. One sample backup later in this chapter uses parallelization.

Recovery Manager Reports

You use two commands with Recovery Manager to generate reports about the backups you've done and the database objects that need to be backed up: REPORT and LIST. They can give you information on the following:

You learn how to generate reports from Recovery Manager later in the chapter.

Corruption Detection

The Oracle Server process doing the backup will detect corrupt database blocks during the backup operation and records any corruption in the control file and the alert log. Recovery Manager reads this information after the backup operation completes and stores it in the recovery catalog. Not all types of corruption are detectable at this time, though.

System Performance

With the previous mention of parallelization, you might be thinking, "If I let Recovery Manager operate in this mode, how will I keep it from using all the system's resources?" You can throttle Recovery Manager with the use of the channel control commands. You use the channel control commands to specify limits on disk I/O during backup operations, determine how many threads will be executing concurrently during a parallel operation, and specify the maximum size for the backup pieces you're creating. By using the channel control commands effectively, you can have your backup operations running quickly and efficiently, without affecting the interactive users that may be using the system during your backup.

Setting Up the Recovery Catalog

Using a recovery catalog with Recovery Manager is optional. Recovery Manager becomes much more powerful when a recovery catalog is implemented, which makes database backups and restores much easier.

Recovery Manager flexibility
Recovery Manager gives you a great many options for implementing your database backup strategy. In this chapter you learn about all the software's capabilities, although in some installations you wouldn't use all of Recovery Manager's capabilities.

As mentioned earlier, the recovery catalog takes the form of an Oracle user schema. We will divide the tasks for creating the catalog into two sections. The first section covers the creation of the database schema that will contain the catalog. The second section will handle the steps necessary to create the recovery catalog within the schema.

Creating a Database Schema for the Recovery Catalog

Let's start by making a few quick decisions regarding the catalog and the database schema that we're creating. In this chapter, let's assume that you have many databases to back up, and that your systems must be up 24 hours a day, 7 days a week. Let's also assume that when a system does go down, it needs to be brought back online as quickly as possible.

Recovery catalog default tablespace
The recovery catalog database schema should have its own table-space; it should not have its objects stored in the default user table-space.

For the examples in this chapter, the recovery catalog will be created in a separate database whose SID is rcover. The schema that the catalog will reside in will be called recman, and the database that we will be backing up has a SID of jdbase. (Of course, you can and will want to use your own names for these objects.)

Create the Default Tablespace for the Recovery Catalog Schema

Before you can create an Oracle user schema with its own default tablespace, you first need to have the tablespace created. Oracle recommends that the typical recovery catalog require 100MB of storage for one year.

That 100MB value is what we will use to create the tablespace that will contain our catalog. You create the tablespace from within SQL*Plus by using the command CREATE TABLESPACE. The following code shows how the RECOVER tablespace was created on my test system:

Keep the catalog and target database separate
The database that contains the recovery catalog should never be on the same logical disk drive as the database you're backing up, including RAID and mirrored disk drives. The optimal location for the database containing the recovery catalog is a completely separate system.

SQL*Plus: Release 8.0.4.0.0 - Production on Thu Apr 23
19:44:49 1998

(c) Copyright 1997 Oracle Corporation.  All rights reserved.

Connected to:
Oracle8 Enterprise Edition Release 8.0.4.0.0 - Production
PL/SQL Release 8.0.4.0.0 - Production

SQL> create tablespace recover
  2  datafile '/ora02/oradata/rcover/recover01.dbf'
  3  default storage (initial 1m next 1m pctincrease 0)
  4  size 100m;

Tablespace created.

Now, just to double-check that the table is there and created correctly, use a SELECT command to query the DBA_TABLESPACES view and look up the new tablespace:

SQL> select tablespace_name, status, contents, logging
  2  from dba_tablespaces
  3  where tablespace_name='RECOVER';

TABLESPACE_NAME                STATUS    CONTENTS  LOGGING
------------------------------ --------- --------- --------
RECOVER                        ONLINE    PERMANENT LOGGING

With the new recover tablespace created and online, you're now ready to create the schema account that will store the recovery catalog.

Picking an authentication method
A good rule of thumb for deciding whether to use passwords or external authentication for schema accounts is to use passwords for any accounts being accessed from anywhere other than the local system. For data-bases that will be accessed from the local system itself, you can feel safe in allowing external authentication.

Create the Database Schema

You can also create the new user schema for the recovery catalog from within SQL*Plus. Let's create the new account with a password for security reasons. Remember to set the default tablespace to be our RECOVER tablespace. Don't forget to grant the RECOVERY_CATALOG_OWNER role to the schema account, as specified in the Oracle documentation.

The SQL*Plus CREATE USER command used to create our schema is as follows:

SQL> create user recman identified by recman
  2  default tablespace recover
  3  temporary tablespace temp;

User created.

SQL> grant recovery_catalog_owner to recman;

Grant succeeded.

Again, you'll want to query the DBA tables to make sure that the account was successfully created. The following code verifies that the default tablespace is correctly set and that the account has a password:

SQL>  select username,password,default_tablespace
  2  from dba_users
  3  where username = 'RECMAN';

USERNAME         PASSWORD            DEFAULT_TABLESPACE
---------------- ------------------- -------------------
RECMAN           37234A26A0BB0E9F    RECOVER

With your database schema created, you can now move on to the next section and create the recovery catalog in the recman schema.

Creating the Recovery Catalog

The creation of the actual catalog is fairly simple after you create the catalog tablespace and schema account. All you need to do is run the catrman script, which is located in the rdbms/admin directory (subdirectory of ORACLE_HOME).

Use the right schema
You must execute catrman from within the RECMAN database schema. Don't execute it from the SYS schema or your own personal schema; otherwise, you'll see errors when performing Recovery Manager operations.

You install the catalog by connecting to the database with the RECMANschema and executing the script:

ash$ sqlplus

SQL*Plus: Release 8.0.4.0.0 - Production on Sat Apr 25
18:37:57 1998

(c) Copyright 1997 Oracle Corporation.  All rights reserved.

Enter user-name: recman
Enter password:

Connected to:
Oracle8 Enterprise Edition Release 8.0.4.0.0 - Production
PL/SQL Release 8.0.4.0.0 - Production

SQL> @?/rdbms/admin/catrman

The script takes a few minutes. When it's done, you should select the table names from the DBA_TABLES view to verify that they are there, in the correct schema:

SQL> select table_name from user_tables;

TABLE_NAME
------------------------------
AL
BCB
BCF
BDF
BP
BRL
BS
CCB
CCF
CDF
CKP

TABLE_NAME
------------------------------
DB
DBINC
DF
DFATT
OFFR
ORL
RCVER
RLH
RR
RT
SCR

TABLE_NAME
------------------------------
SCRL
TS
TSATT

25 rows selected.

Implementing Your Backup Strategy

Recovery Manager provides many different options for backing up and restoring database files. It can perform full and incremental backups, and can use disks and tapes as backup devices. If you have multiple tape drives on your system, Recovery Manager can take advantage of that and run multiple backups concurrently.

Recovery Manager Backup Features

When you read about the creation of the recovery catalog earlier in this chapter, it was mentioned that the catalog is an optional feature and that Recovery Manager can run without it. Let's take a deeper look at this, and the effect that running without a recovery catalog has on the restorability of your database files.

Using the Recovery Catalog with Recovery Manager

As you already know, all information regarding the structure, files, and condition of the database is stored in the database's control file. Recovery Manager reads this information out of the control file and updates the recovery catalog. The maintenance of the information in the recovery catalog isn't dynamic. You update the data in the recovery catalog with the rman command RESYNC CATALOG.

How often you need to perform the resync depends on how active your database is. If your database is in ARCHIVELOG mode and is being updated regularly, you'll want to resync the catalog every few minutes or hours. If your database is static, a greater elapsed time period would probably be sufficient. As an absolute minimum, your resync should be more often than the CONTROL_FILE_RECORD_KEEP_TIME setting in the target database.

Catalog sync frequency
You want to err on the side of syncing the control file and recovery catalog too often. If the recovery catalog isn't current at the time of the system failure, you have to catalog all backups and changes between the last resync and the system failure to bring the database back up.

When the recovery catalog is fully in sync with the control file, a database restoration after a system failure is very straightforward.

Not Using the Recovery Catalog

Because all the critical data regarding a database's files and structure are stored in the control file, you don't necessarily need to use the recovery catalog when using Recovery Manager. You can simply do your backups and restores the way you always have, and protect the control file to ensure a successful restore.

Do both if it's possible…
Use a catalog with Recovery Manager and continue to maintain your redundant copies of the control file. It's cheap insurance against a prolonged down-time.

Without a recovery catalog, however, the following Recovery Manager features will be unavailable to you:

Also, if you decide not to use a recovery catalog, you have to protect the control file the same way you had to under Oracle7-using multiple copies, frequently performing backups, and keeping a reliable record system of when those backups were done.

Recovery Manager Scripting Commands

Before you can perform any backups with Recovery Manager, you first need to look at how to script the backups. The command-line interface to Recovery Manager is called rman, and all functions relating to database backups and restores are executed through this utility.

You can perform backup and restore operations when you're running rman and are connected to the recovery catalog and the target database. You use rman in very much the same way you use SQL*Plus-you can execute commands from a script file, from a stored script, or by entering it interactively.

Look at Listing 15.1. It's a short script that will add a full backup of a database-to-disk script to the recovery catalog.


Listing 15.1  FULLBACK.RCV-Recovery Manager script to create a full backup stored script

     01:     replace script fullback {
     02:     #
     03:     # full backup of database files, excluding archived logs
     04:     #
     05:        allocate channel d1 type disk;
     06:        backup
     07:            incremental level 0
     08:            tag fullback
     09:            filesperset 50
     10:            format '/ora03/backup/%d/%d__t%t_s%s_p%p'
     11:            (database);
     12:     }

This simple script performs a full backup of database files, excluding archived logs. You can perform this backup interactively if you replace the statement replace script fullback on line 1 with the command run. The following code shows this script's output. It doesn't execute the backup-it simply stores the script in the recovery catalog as a stored backup script.

$  rman target jduer/baseball rcvcat recman/recman@rcover
        cmdfile fullback.rcv

Recovery Manager: Release 8.0.4.0.0 - Production

RMAN-06005: connected to target database: JDBASE
RMAN-06008: connected to recovery catalog database

RMAN> replace script fullback {
2> #
3> # full backup of database files, excluding archived logs
4> #
5>      allocate channel d1 type disk;
6>      backup
7>              incremental level 0
8>              tag fullback
9>              filesperset 50
10>             format '/ora03/backup/%d/%d__t%t_s%s_p%p'
11>             (database);
12> }
13>
RMAN-03022: compiling command: replace script
RMAN-03023: executing command: replace script
RMAN-08086: replaced script fullback

Recovery Manager complete.

Executing a Backup Script

With the sample backup script successfully stored in the recovery catalog, it's time to perform your first backup with Recovery Manager. To execute a stored Recovery Manager script, you first use the rman utility to connect to the recovery catalog and the target database. When connected, you execute the stored script via the rman run command, as follows:

ash$  rman rcvcat recman/recman@rcover

Recovery Manager: Release 8.0.4.0.0 - Production

RMAN-06008: connected to recovery catalog database

RMAN-03022: compiling command: allocate
RMAN-03023: executing command: allocate
RMAN-08030: allocated channel: d1
RMAN-08500: channel d1: sid=11 devtype=DISK

RMAN-03022: compiling command: backup
RMAN-03023: executing command: backup
RMAN-08008: channel d1: starting datafile backupset
RMAN-08502: set_count=3 set_stamp=331940454
RMAN-08010: channel d1: including datafile 1 in backupset
RMAN-08011: channel d1: including current controlfile in
backupset
RMAN-08010: channel d1: including datafile 5 in backupset
RMAN-08010: channel d1: including datafile 3 in backupset
RMAN-08010: channel d1: including datafile 2 in backupset
RMAN-08010: channel d1: including datafile 4 in backupset
RMAN-08013: channel d1: piece 1 created
RMAN-08503: piece handle=
/ora03/backup/JDBASE/JDBASE__t331940454_s3_p1 comment=NONE
RMAN-03023: executing command: partial resync
RMAN-08003: starting partial resync of recovery catalog
RMAN-08005: partial resync complete
RMAN-08031: released channel: d1
Connects to the database you're going to back up
EXECUTE command is encapsulated inside the RUN command; it doesn't work on its own

rman Commands

In this part of the chapter, you take a look at the syntax of the main rman commands for backup operations-you look at the channel control commands ALLOCATE CHANNEL and RELEASE CHANNEL. The section follows up with details on the two commands for executing backups: backup and copy.

The ALLOCATE CHANNEL Command

The ALLOCATE CHANNEL command establishes a link between Recovery Manager and the target database. The easiest way to visualize an rman channel is to think of it as a thread. You can use multiple channels within your backup script, and Recovery Manager will try to use as many of those channels concurrently as possible.

There are some restrictions, though. A single channel can work on only one image file copy or backup set at a time. If you break your backup into two backup sets, however, and create two channels (one pointing to each tape drive), the parallelization of Recovery Manager kicks in and the software will create both backup sets concurrently.

For disk-to-disk backups, you can create as many channels as you want. For system performance's sake, however, you'll want to spread the backup set destinations over several different disk drives. This way you don't create I/O contention by having the channels compete for system resources. (We will discuss an example of how to use the parallelization of Recovery Manager later in the section "The COPY Command.")

Only one operand is specified with the ALLOCATE CHANNEL command-a name for the channel, such as D1, for the first disk channel. This name comes into play when using the RELEASE CHANNEL command-you use the name to specify which allocated channel to release. Here is a summary of the command parameters the ALLOCATE CHANNEL command accepts:

Requirements for name parameter
The name parameter is only for sequential I/O devices, such as tape drives. You don't use this parameter when opening a channel to disk.

The following sample code shows how to allocate a disk channel named d1:

allocate channel d1 type disk;

RELEASE CHANNEL

This command is used to deallocate a channel you created with the ALLOCATE CHANNEL command. This command takes only one operand-the name of the channel to release-which you specified during the ALLOCATE CHANNEL command. The following code line shows a DEALLOCATE command's syntax:

deallocate channel d1;
Freeing system devices
You'll want to use this command if your operating system platform actually allocates resources on the system level during the ALLOCATE CHANNEL command. This way you'll have the system device allocated to you during the time that you need it; you can release this device for others to use during times when other devices are being used.

SETLIMIT CHANNEL

You use the SETLIMIT CHANNEL command to throttle the use of system resources for a particular channel. This way you can restrict throughput on a per-channel basis. This command takes one parameter, the channel name, and uses any or all of the following three parameters:

Controlling file access
If you don't specify the maxopenfiles parameter and don't use the set limit channel command at all, a default of 32 maximum open files is used.

The following sample command shows how you would set the channel d1 to open only 48 files at any time, and restrict the read I/O rate to 256:

setlimit channel d1 maxopenfiles 48 readrate 256;

BACKUP

As discussed earlier, there are essentially two types of backups: full and incremental. The default, a full backup, selects all database files with the exception of archived logs. In an incremental backup, only database blocks that have been modified since the last backup are written to the backup set. Database blocks that have never been used aren't written out to the backup set, regardless of whether the backup is full or incremental.

Backup Object List

In your BACKUP command, you use a backup object list to specify which database components you want written into the backup set. There are eight possible values for this backup command operand:

Understanding backup levels
Incremental backups are multilevel, with incremental level 0 a backup of all database blocks. Incremental level 0 is essentially the same as a full backup, except a full backup doesn't affect subsequent incremental backups. This means that if you want to perform a complete backup followed by a series of incremental backups, you'll want to perform an incremental backup level 0 for your complete (full) backup and use incremental level 1 for your nightly incremental backups.

You can specify three other objects when declaring your backup object list:

current controlfileUse this to back up the current database control file.
Backup controlfileUse this to include the backup control file.
BackupsetUse this to specify that you're backing up a backup set. The backup set must be disk resident and is specified by its primary key.

BACKUP Command Operands

Each operand can be used multiple times within a BACKUP command within your backup script-as long as each one corresponds to a different backup specification:

Creating output filenames
You use the format operand to define the backup objects' output filenames. It's similar to the way you define archived log filenames in your database init.ora file.

Table 15.1  Substitution variables for the format operand
Variable-
Description
%d
The database name is put in the file spec
%p
The number of the backup piece within the backup set
%s
The number of the backup set
%n
The database name (padded)
%t
A timestamp
%u
An eight-character value composed of the backup set number and the time it was created

The following code lines show the BACKUP command's syntax:

backup
    incremental level 0
    tag fullback
    filesperset 50
    format '/ora03/backup/%d/%d__t%t_s%s_p%p'
    (database);

The COPY Command

You use the COPYcommand to make an image backup on an individual database file. The actual file can be a database data file, a copy of a data file, a current or backup control file, or an archived log file. You can't use the COPY command to write files to tape; they must be to disk.

COPY and BACKUP similarities
Because the COPY command does essentially the same thing as the BACKUP command, the use of the COPY command is almost identical to that of the BACKUP command. You don't create backup sets with the COPY command, however.

The real value of the COPY command is in its capability to multiplex. You can get a large number of files copied in a very short period of time if you list the files to back up individually and create enough channels.

The following sample scripts illustrate the COPY command and the parallelization that it can do. When the COPY command is used as it is in Listing 15.2, Recovery Manager copies the files as five separate operations performed sequentially (lines 7-11). It changes things quite a bit if you use only one COPY command and separate the filenames with commas, as lines 7-11 in Listing 15.3 show.


Listing 15.2  COPSAMP1.RCV-Using the COPY command with a single thread

01: run {
02:  allocate channel d1 type disk;
03:  allocate channel d2 type disk;
04:  allocate channel d3 type disk;
05:  allocate channel d4 type disk;
06:  allocate channel d5 type disk;
07:  copy datafile 10 to '/ora01/backup/JDBASE/jdbase10.dbf';
08:  copy datafile 11 to '/ora02/backup/JDBASE/jdbase11.dbf';
09:  copy datafile 12 to '/ora03/backup/JDBASE/jdbase12.dbf';
10:  copy datafile 13 to '/ora04/backup/JDBASE/jdbase13.dbf';
11:  copy datafile 14 to '/ora05/backup/JDBASE/jdbase14.dbf';
12: }


Listing 15.3  COPSAMP2.RCV-Image COPY command with parallelization

01: run {
02:  allocate channel d1 type disk;
03:  allocate channel d2 type disk;
04:  allocate channel d3 type disk;
05:  allocate channel d4 type disk;
06:  allocate channel d5 type disk;
07:  copy datafile 10 to '/ora01/backup/JDBASE/jdbase10.dbf',
08:   datafile 11 to '/ora02/backup/JDBASE/jdbase11.dbf',
09:   datafile 12 to '/ora03/backup/JDBASE/jdbase12.dbf',
10:   datafile 13 to '/ora04/backup/JDBASE/jdbase13.dbf',
11:   datafile 14 to '/ora05/backup/JDBASE/jdbase14.dbf';
12: }

By specifying the COPY command as a single operation (Listing 15.3), Recovery Manager will use the five disk channels you allocated all at the same time and back up the five files concurrently. There's a great performance gain in this particular case because the output files are all being written to different disks, and will complete far faster than in the example shown in Listing 15.2.

Restores

There's no point in performing backups if there's no way to return the information to the system in case of a system failure. Recovery Manager provides the RESTORE command to restore the backup sets you created with the BACKUP command, and it's just as easy to use as the BACKUP command. Now it's time to restore the full backup that you performed earlier in the "Recovery Manager Scripting Commands" section.

Restoring the Full Backup

Begin by assuming that some system failure caused corruption or deletion of the database files you backed up earlier. Restoring the files and recovering the database can all be done in a single operation.

First, use Server Manager to start your database instance (not mounted, of course):

ash$ svrmgrl

Oracle Server Manager Release 3.0.4.0.0 - Production

(c) Copyright 1997, Oracle Corporation. All Rights Reserved.

Oracle8 Enterprise Edition Release 8.0.4.0.0 - Production
PL/SQL Release 8.0.4.0.0 - Production

Total System Global Area       4749504 bytes
Fixed Size                       47296 bytes
Variable Size                  4218880 bytes
Database Buffers                409600 bytes
Redo Buffers                     73728 bytes
SVRMGR> exit
Server Manager complete.
Starts the instance nomount; it's mounted by the restore script

With the database started as NOMOUNT, all you have to do is tell Recovery Manager to restore the entire database. Listing 15.4 shows the Recovery Manager script we will use to perform the restore. (I didn't create a stored script because I wanted you to see how to execute an rman script stored on disk.)


Listing 15.4  FULLREST.RCV-Full database restore script using Recovery Manager

01: # fullrest.rcv
02: # This recovery manager script will restore the entire
03: # database as backed up
04: # with the fullback script
05: #
06: run {
07:     allocate channel d1 type disk;
08:     restore database;
09:     sql "alter database mount";
10:     recover database;
11:     sql "alter database open";
12:     release channel d1;
13: }

That's all it will take to complete the restore and recovery of the database. Notice that you don't even have to specify a location where the backup can be found-this is all handled by Recovery Manager. The following code is a little long but shows all the steps that Recovery Manager took to restore the database and even open it for the users:

ash$ rman target jduer/baseball rcvcat recman/recman@rcover
cmdfile fullrest.rcv

Recovery Manager: Release 8.0.4.0.0 - Production

RMAN-06006: connected to target database: jdbase
(not mounted)
RMAN-06008: connected to recovery catalog database

RMAN> # fullrest.rcv
2> # This recovery manager script will restore the entire
database as backed up
3> # with the fullback script
4> #
5> run {
6>      allocate channel d1 type disk;
7>      restore database;
8>      sql "alter database mount";
9>      recover database;
10>     sql "alter database open";
11>     release channel d1;
12> }
13>
RMAN-03022: compiling command: allocate
RMAN-03023: executing command: allocate

RMAN-08019: channel d1: restoring datafile 1
RMAN-08509: destination for restore of datafile 1:
/ora01/oradata/jdbase/system01.dbf
RMAN-08019: channel d1: restoring datafile 2
RMAN-08509: destination for restore of datafile 2:
/ora01/oradata/jdbase/rbs01.dbf
RMAN-08019: channel d1: restoring datafile 3
RMAN-08509: destination for restore of datafile 3:
/ora01/oradata/jdbase/temp01.dbf
RMAN-08019: channel d1: restoring datafile 4
RMAN-08509: destination for restore of datafile 4:
/ora01/oradata/jdbase/tools01.dbf
RMAN-08019: channel d1: restoring datafile 5
RMAN-08509: destination for restore of datafile 5:
/ora01/oradata/jdbase/users01.dbf
RMAN-08023: channel d1: restored backup piece 1
RMAN-08511: piece handle=
/ora03/backup/JDBASE/JDBASE__t331940454_s3_p1 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(4)

RMAN-03022: compiling command: sql
RMAN-06162: sql statement: alter database open
RMAN-03023: executing command: sql

RMAN-03022: compiling command: release
RMAN-03023: executing command: release
RMAN-08031: released channel: d1

Recovery Manager complete.
Disk channel d1 is created and allocated
RESTORE DATABASE command is executing
Newly restored database
Database data files are recovered, completing the restoration

More on Restores

The restore script in Listing 15.4 uses the sql command to mount the database and then to later open it. This very powerful Recovery Manager feature allows for incredible flexibility and programmability of many backup and restore scenarios. For example, if you wanted to recover a tablespace while the database was open, the meat of your restore script would be only three lines:

Sql "alter tablespace JDDATA offline";
Recover tablespace JDDATA;
Sql "alter tablespace JDDATA online";

The rest of the database would remain available while the restoration was proceeding, and the tablespace in question would be made available again before Recovery Manager exited.

Another note on restores is Recovery Manager's capability to perform point-in-time recovery. This is done by using the SET UNTIL TIME command in your restore script. Suppose that today was May 1, 1998, and there was a database problem at 2:01 p.m. that required recovery of one of the database objects. Your restore script would essentially be the same, except for the addition of this command:

Set until time '1-MAY-1998 14:00:00'
Point-in-time recovery
Oracle documentation dedicates an entire chapter to point-in-time recovery, and there are many pre-requisites to performing this operation. Consult the documentation and call Oracle Support for more information; a full discussion is beyond the scope of this book.

Executing this script would restore the database object to the condition it was in at 2:00 p.m. that day.

Using the REPORT and LIST Commands

You use the REPORT command to dump information out of the recovery catalog. This command can tell you which database objects need to be backed up, which backup sets are obsolete, and so on.

The LISTcommand is used to report on the status of backup sets and the like. For example, you use the rman command LIST BACKUPSET OF DATABASE to list information on the full backup script and when it was performed:

RMAN> list backupset of database;

RMAN-03022: compiling command: list
RMAN-06230: List of Datafile Backups
Key   File Type         LV Completion_Ckp SCN   Ckp Time
----- ---- ------------ -- -------------- ----- ---------
27    1    Incremental  0  29-APR-98      17900 29-APR-98
27    2    Incremental  0  29-APR-98      17900 29-APR-98
27    3    Incremental  0  29-APR-98      17900 29-APR-98
27    4    Incremental  0  29-APR-98      17900 29-APR-98
27    5    Incremental  0  29-APR-98      17900 29-APR-98

The REPORT and LIST commands' full syntax is spelled out on the Oracle documentation CD-ROM.


© Copyright, Macmillan Computer Publishing. All rights reserved.