Recovering the Application
Oracle Application Server Tips by Burleson
Recovery of the application server is
required if the server will not restart. If the application
server instance fails but will restart, recovery is not required.
The first step in the recovery will be to rebuild the server.
If you have a recent full backup, if may be no more that a full
restore and restart. If you can use a backup to restore the
server, then use the recent instance backup to overwrite the $ORACLE_HOME
files with valid files, that may be all you need to recover the
instance to the last backup. If you must reinstall the OS or
move the instance to a new server, you take the following steps to
insure a successful restore of the application server instance.
Restoring A Middle Tier Instance
If you lose a middle tier instance that
belongs to a cluster, you may just want to rebuild the server (or
use a new server), reinstall the middle tier instance using the
Oracle Universal Installer and then join the original cluster.
This will reconfigure the new instance to the configuration of the
cluster. Do not forget to add the new instance to the load
balancing Web Cache.
If you must reinstall the server OS, insure
that you reinstall the same OS (versions and patches) and follow the
OS setup requirements. Follow the steps below to restore the
application server instance.
Insure that the /etc/hosts file matches
the original file from the failed installation.
Create the same user and groups to own the
Restore the oraInst.loc and oratab files
to the appropriate directories (depending on your OS).
Create the instance $ORACLE_HOME directory
(empty) using the same mount point and path (insure it is owned by
the user that owns the Oracle files).
Create and restore the oraInventory
directory from the backup.
Restore the $ORACLE_HOME directory from
backup. You need a full restore of the $ORACLE_HOME.
Insure that you execute the restore as the user that owns the
Set the file permissions by running $ORACLE_HOME/root.sh
as the root user.
If the new host server has a different
hostname and/or IP address you must refer to the Oracle
Application Server 10g Administrator's Guide10g (9.0.4) Chapter 9.
Start the instance as per normal.
Apply any changes applied to the instance
since the backup was taken.
If you are required to restore the middle
tier to the same host with out having the reinstall the OS follow
the steps below.
Stop the instance if running.
Restore the $ORACLE_HOME overwriting all
files with the files in the most recent backup.
Start the instance as per normal.
Apply any changes made to the instance
since the backup was taken.
Restoring an Infrastructure Instance
Restoring an Infrastructure instance follows
the same step as restoring a middle tier instance except that you
must restore the Metadata Repository database before restarting the
instance. For details on restoring the Metadata Repository
database refer to the next section.
Note: If you installed OID in a
separate $ORACLE_HOME, you must restore the OID ORACLE_HOME before
restoring the Metadata Repository database.
Metadata Repository Database Protection
The Infrastructure Metadata Repository is
maintained in an Orcale9i database. Normally this is a
stand-alone database, installed with the infrastructure and
specifically tuned for the repository. This special purpose
implementation should not be used for other persistent storage.
However, this database does require that you protect its data from
loss. Protecting the Metadata Repository is the same as
protecting any other Oracle9i database.
Note: This is an introduction
to backup and recovery of Oracle9i databases. You need to
refer to the Oracle database documentation or obtain a good book
that covers Oracle database backup and recovery such as the Oracle9i
DBA Handbook, or Oracle Backup & Recovery 101, both from Oracle
The Metadata Repository is stored in an
precisely tuned Oracle9i database that implements all of the data
protection inherent in all Oracle databases. It is recommended
that you implement a separate back-end database to provide
application persistent object storage.
The Oracle9i database implements safeguards
to insure data integrity and consistency. In this section we
will discuss the major features used by Oracle to protect data. The
Oracle9i database implements a transaction log that records most
changes to the database. The database uses this log to recover
data if necessary. Some changes are not logged and so are not
recoverable such as truncating a table. Here is a simplified
example of logged change. A user inserts a row into the
employee table. The information about the change is recorded
in the undo logs. The user issues a commit to make the change
permanent and the undo log is updated to show that the change is
committed. If the user instead issued a rollback command, the
database would used the data in the undo log to remove the change to
the employee table. Lets? go back to the user issuing the
commit. The actual change to the employee table is in memory.
On commit, the database updates the undo logs but may not write the
change to disk for speed reasons. The data on disk does not
match the data in memory, but that is ok since the undo log has a
record of the change. The database writer process (DBW) will
write changes in memory to disk in the background at certain
intervals. Once the database no longer needs to keep the
change information, it writes the change to a Redo Log File Group.
The Redo Files are list of changes that the database no longer
needs. The Metadata Repository is created with 3 Redo Log File
Groups. They are filled with changes in a round robin method.
Once the last one is used, the database will begin overwriting the
first one, Figure 11-1.
Figure 1:Database Transaction Log Files
But lets say that our database crashes
before the DBW writes the change to the employee table to disk.
When we restart the database after the crash, Oracle will verify
that each data file is consistent using a system change number (SNC).
If it finds that the data file does not contain the SCN that it
expects, then the database will go to the undo/redo logs and recover
the data file, updating it with all the missing changes. This
is referred to as rolling forward. Once all missing
transaction are added, the database then uses the undo logs to roll
back the uncommitted transaction. At the point the data file
has been recovered and is up-to-date. Once all data files are
up-to-date, the database will open and resume work. Hence the
undo logs allow the database to rollback uncommitted changes and the
redo and undo logs allow the database to roll data file forward.
This is an excerpt from "Oracle
10g Application Server Administration Handbook" by Don Burleson
and John Garmany.