Recovery Manager (RMAN)
Oracle Application Server Tips by Burleson
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.
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
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:
Fix the Problem (replace faulty equipment,
Restore the affected files
Locate (or restore) the archive log files
Start the database
Recover the database
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:
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
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
When restoring files, only restore files
which are damaged of lost. This will reduce the roll forward
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
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.