As with the example scripts that Oracle includes in $ORACLE_HOME/rdbms/demo, it is not meant for any of these case studies (scripts) to be run within a single RMAN session. Rather, these case studies were meant to serve as a basis for developing your own backup, maintenance, restore, and recovery scripts. You should use the various sections in this article as a reference in building individual RMAN scripts which can be run to configure, backup, restore, and recover your database.

The following assumptions should be made throughout each of the case studies:

• All case studies will be tested and performed on a Sun Solaris platform - (Solaris 9).
• The target database will be an Oracle9i (9.2.0.5.0) database named TARGDB.
• The DBID for the TARGDB database is: 2528050866.
• Some cases will use a Recovery Catalog and others will not.
• A user was created in the target database named backup_admin with a password of backup_admin. This database user was granted SYSDBA privileges and will be the one used to login to the target database for performing all RMAN related operations.

NOTE: Other examples within the RMAN Case Study Series will include instructions for handling read-only and excluded tablespaces.

This case study is divided into the following sections:

1. Create an RMAN script for configuring RMAN parameters.

2. Backup the target database.

3. Validate the Database:
   • Command to verify database is restorable.

   • Command to verify tablespace is restorable.

4. Run several Recovery Catalog maintenance against the target database's control file.

5. Remove the TARGDB database to simulate and setup a disaster recovery situation.

6. Restore and Recovery the TARGDB database.

% ORACLE_SID=TARGDB
% export ORACLE_SID

% rman target backup_admin/backup_admin

Recovery Manager: Release 9.2.0.5.0 - Production

Copyright (c) 1995, 2002, Oracle Corporation.  All rights reserved.

connected to target database: TARGDB (DBID=2528050866)

RMAN>

For the purpose of this case study, I will be setting the following parameters:

Script: configure_database.rcv

run { CONFIGURE RETENTION POLICY TO REDUNDANCY 2; CONFIGURE DEFAULT DEVICE TYPE TO DISK; CONFIGURE CONTROLFILE AUTOBACKUP ON; CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '/orabackup1/rman/TARGDB/%F'; CONFIGURE DEVICE TYPE DISK PARALLELISM 2; CONFIGURE CHANNEL 1 DEVICE TYPE DISK FORMAT '/orabackup1/rman/TARGDB/backup_db_%d_S_%s_P_%p_T_%t' MAXPIECESIZE 1024m; CONFIGURE CHANNEL 2 DEVICE TYPE DISK FORMAT '/orabackup2/rman/TARGDB/backup_db_%d_S_%s_P_%p_T_%t' MAXPIECESIZE 1024m; }

NOTE: All configuration settings are stored persistently, and will be used by RMAN for all subsequent backup, restore, recovery, and maintenance operations.

NOTE: It is important that you save the database id (DBID) displayed in the RMAN output if you are taking RMAN backups in NOCATALOG mode or if the database name is ambigious in the Recovery Catalog. The DBID is required during disaster recovery! You will see the DBID in RMAN output when connecting to the target database as in the following output: % rman target backup_admin/backup_admin connected to target database: TARGDB (DBID=2528050866)

• Whole database backups when the database is cleanly closed and the instance is mounted.
• Tablespace backups of tablespaces that are offline clean or read only.

Script: backup_cold.rcv

run { # ----------------------------------------------------------- # The following RMAN commands are run each day. # The steps are: # - Re-start the database to perform crash recovery, in # case the database is not currently open, and was not # shut down consistently. The database is started in DBA # mode so that normal users cannot connect. # - Shut down with the IMMEDIATE option to close the # database consistently. # - Startup and mount the database. # - Backup database. # - Open database for normal operation. # ----------------------------------------------------------- startup force dba; shutdown immediate; startup mount; backup database; alter database open; } exit

Use the following to verify that a the entire database can be restored using the existing backups:

run {
  restore database validate;
}

You can also check on the ability to restore an individual tablespace:

run {
  restore tablespace read_only_tbs validate;
}

Script: maintenance_commands.rcv

run { # ----------------------------------------------------------- # Verify that all backups on the backup media are intact # ----------------------------------------------------------- CROSSCHECK BACKUP OF DATABASE; # ----------------------------------------------------------- # Display a list of files that need to be backed up based on # the retention policy. For this case study, files that don't # have at least 2 backups will be reported. # ----------------------------------------------------------- REPORT NEED BACKUP; # ----------------------------------------------------------- # Delete any un-necessary backups. This command deletes backups # based on the retention policy you configured. For this case study, all # backups older than the 2 most recent backups of each # datafile will be deleted. # ----------------------------------------------------------- DELETE OBSOLETE; # ----------------------------------------------------------- # Get a complete summary list of existing backups. # ----------------------------------------------------------- LIST BACKUP SUMMARY; }

% rm /u03/app/oradata/TARGDB/*
% rm /u04/app/oradata/TARGDB/*
% rm /u05/app/oradata/TARGDB/*
% rm /u06/app/oradata/TARGDB/*

% sqlplus "/ as sysdba"

SQL> shutdown abort

SQL> exit

NOTE: Because redo logs are not archived, only full and incremental backups (if you were taking incremental backups) are available for restore and recovery.

It is assumed that you have all the configuration files like:

• Server parameter file (spfile - equivalent of init.ora in 9i)
• tnsnames.ora
• listener.ora
• sqlnet.ora (optional)

are all in their appropriate places. It is also assumed that you can startup the Oracle instance in NOMOUNT MODE and connect from RMAN to the target instance.

The steps are:

1. If not using a recovery catalog, or if the database name is ambiguous in, you need to start RMAN and set the DBID before restoring the controlfile from autobackup.
2. Startup database in NOMOUNT mode. (You should have restored the initialization file for database, and listener files [only if connecting over SQLNET].)
3. Restore controlfile.
4. Mount the database.
5. Restore all database files.
6. Apply all incrementals. (In this example, we are not taking incremental backups, so this step is not required.)
7. Open database with RESETLOGS mode to re-create the online log files.
8. You will need to manually add any tempfiles back to the database after recovering the database.

Script: recover_cold.rcv

set dbid 2528050866; connect target backup_admin/backup_admin; startup nomount; run { # ----------------------------------------------------------- # Uncomment the SET UNTIL command to restore database to the # incremental backup taken two days ago. # SET UNTIL TIME 'SYSDATE-2'; # ----------------------------------------------------------- set controlfile autobackup format for device type disk to '/orabackup1/rman/TARGDB/%F'; restore controlfile from autobackup; alter database mount; restore database; recover database noredo; alter database open resetlogs; sql "alter tablespace temp add tempfile ''/u06/app/oradata/TARGDB/temp01.dbf'' size 500m autoextend on next 500m maxsize 1500m"; } exit

NOTE: Tempfiles are automatically excluded from RMAN backups. This requires them to be re-added at recovery time. There is an enhancement, 1641989, requesting RMAN take care of these tempfiles in the future.