Recovery Manager (RMAN) Oracle Application Server Tips by Burleson Consulting

A server managed backup and recovery strategy uses a tool called Recovery Manager (RMAN) to handle both the backup and recovery.  RMAN will create the backup, execute the restore and perform the recovery.  One significant advantage of using RMAN is that it normally works at the data block level rather than the file level.    RMAN backs up the data blocks to a remote locations and if needed used the data in those blocks to rebuild and recover block in the database.  RMAN uses a catalog (created in a separate database) to maintain backup information such as what backups are available and where they are located.  You can configure RMAN to maintain your backup strategy and RMAN will create the backups, and purge old backups automatically.  When you need to restore a file, RMAN will use the catalogue to locate the backup, restore the file (or data blocks) and recover the database.  RMAN is intelligent enough to determine what needs to be restored and recovered and execute the appropriate actions.  RMAN excels in environments with multiple Oracle databases and can maintain backup and recovery for both you Metadata Repository databases and you back-end databases.  For additional information on Recovery Manager, refer to the Oracle Database Documentation or a good Oracle Database book like the ones mentioned earlier in this chapter.

Database Recovery

Hopefully, you should never have to recover you database.  The Oracle9i database will automatically recover itself from most common problems.  If an instance fails or the operator issues a shutdown abort command, the database will recover itself on startup with out intervention.  However, the Oracle 9i database has all the required mechanisms to allow user recovery from serious failures. 

Note:  I recommend that you only attempt to recover a database once before contacting Oracle Support.  If the first attempt fails, repeated attempts might cause additional damage and leave the database in a state where only partial recovery is possible.  When in doubt, contact Oracle Support.

The first step is determining if and what needs recovery.  If the Metadata Repository does not open on startup, it will manifest itself in the failure of other components starting.  If you can start middle tier components, such as the OC4J instances, check the infrastructure tier to insure the OID is running.  If OID will not start then look to the Metadata Repository database.  If you find that the database is the problem, the first place to check is the database alert log.  The alert log is located in the infrastructure?s $ORACLE_HOME/admin/asdb/bdump directory and is called alertasdb.log.  Substitute your SID is you did not install the database with the SID set to asdb.  This log file will tell you why the database did not open.  If may also lead you to other trace files with more detailed information.

Because of how the Oracle9i database stores changes in the transaction logs, recovery is a two step process, roll the database forward until all changes are applied, then roll back any uncommitted (open) transactions.  At the end of this two-step operation, the database is recovered to a consistent state with no data loss. 

The Oracle9i database has two main types of recovery; complete and incomplete.  A complete recovery uses the transaction logs to recover all committed data.  An incomplete recover uses what ever logs are available to recover as much data as possible and then stops.  There is always some type of data loss in an incomplete recovery.  Incomplete recovery is required if the database is not in ARCHIVELOG mode or needed archive log files are no longer available.   The steps to execute a recovery are:

1. Fix the Problem (replace faulty equipment, drives etc).

2. Restore the affected files

3. Locate (or restore) the archive log files

4. Start the database

5. Recover the database

6. Open the database.

If a disk crash caused the problem, you must replace the drive or place the restored file in another location. Restore the most recent backup of the damaged files.  The older the backup, the longer it will take to roll the file forward.  Locate or restore the archive log files that cover transactions back to the data of the backup.  If restored to the archive log directory, the Oracle database will know where to find them.  If you restore the logs to another location, the database will ask you where they are.  Now start the database.  If the database can automatically recover then the database will end up in an open, ready to use state.  If not the database will startup to the mount point and issue an error stating that the data file needs recovery.  Issue the command:

SQL> RECOVER DATABASE;

Oracle will tell you the name of the first archive log file needed for the recovery.  If you place all the archive logs in the original directory press enter to apply that log.  Enter AUTO to have Oracle automatically apply all necessary log without asking.  Finally if you did not replace the log files in the original directory, enter the new location where Oracle can find the files.  Upon completion Oracle will respond:

Media Recovery Complete

Open the database and check the alert log for any other problems. 

Complete Database Recovery

A complete database recovery is required when you are recovering an Infrastructure instance from backup and are restoring all of the file in the $ORACLE_HOME/oradata directory to include all control files.  If you restored all files to include the archive log files for that backup, the database should self recover on startup.  If the backup was created using a Hot (open) backup, media recovery may be required.  Insure that you restore the archive log files that were copied with the hot backup.

Database Recovery Issues

This section discussed basic file recovery on a database that is not open.  For additional information refer to the references already mentioned.  There are entire books written covering only backup and recovery.  If in doubt, get help, call Oracle Support.  Below are some points to remember when faced with a database recovery.

• Use the current Control File.  The Control File contains the information that defines the current status of each file. If one of the Control Files needs to be restored, copy it over from one of the other current control files.  Never use a restored copy of a Control File unless all copies of the current control file are lost. 

• Any time you open the database with the RESETLOGS clause there is data loss.  Always contact Oracle Support before using RESETLOGS.  Once used, it can not be undone.

• When restoring files, only restore files which are damaged of lost.  This will reduce the roll forward time.

At this point we have covered the basics of backing up and recovering both the application server and the Oracle9i database that holds the Metadata Repository.  How that you have an basic understand of the mechanisms involved, we will introduce you to a tool that will automate most of these tasks.

Oracle Application Server Backup and Recovery Tool

The Oracle Application Server Backup and Recovery Tool is a perl script that will not only handle your backup needs, but will automatically handle a restore.  This tool handles the instance configuration files to include the Metadata Repository database data files (Group 3 file described above).  Since these are the files that change often, you can build you backup strategy around this tool.  You can now take a full backup of the instance?s $ORACLE_HOME and then use the Backup and Recovery Tool to backup on the Group3 files nightly.  To restore the instance follow the same steps as above except after restoring the $ORACLE_HOME directory, run the Backup and Recovery Tool to restore the latest configuration files.   

The Backup and Recovery Tool is located on the OracleAS RepCA and Utilities CDROM in the utilities/backup directory.  The file name is backup_restore.tar  You must install and run the Tool on each server.  Once the tool is installed and configured, it will copy all the instance configuration files to the user defined backup directory.  If run against an Infrastructure instance, the script will also use RMAN to create a backup of the Metadata Repository database.  If the user application maintains local files, the Backup and Recovery Tool can be configured to also backup those files.

For additional information on the Oracle Application Server Backup and Recovery Tool refer to the Oracle Application Server 10g Administrator's Guide 10g (9.0.4) Chapter 12.

This is an excerpt from "Oracle 10g Application Server Administration Handbook" by Don Burleson and John Garmany.