Recovering the Application Server Oracle Application Server Tips by Burleson Consulting

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.

1. Insure that the /etc/hosts file matches the original file from the failed installation. 

2. Create the same user and groups to own the Oracle files. 

3. Restore the oraInst.loc and oratab files to the appropriate directories (depending on your OS). 

4. 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). 

5. Create and restore the oraInventory directory from the backup. 

6. 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 Oracle files.

7. Set the file permissions by running $ORACLE_HOME/root.sh as the root user.

8. 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.

9. Start the instance as per normal.

10. 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.

1. Stop the instance if running.

2. Restore the $ORACLE_HOME overwriting all files with the files in the most recent backup.

3. Start the instance as per normal.

4. 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 Press.

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. 

Undo Logs

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.