Call now: 252-767-6166  
Oracle Training Oracle Support Development Oracle Apps

 E-mail Us
 Oracle Articles
New Oracle Articles

 Oracle Training
 Oracle Tips

 Oracle Forum
 Class Catalog

 Remote DBA
 Oracle Tuning
 Emergency 911
 RAC Support
 Apps Support
 Oracle Support

 SQL Tuning

 Oracle UNIX
 Oracle Linux
 Remote s
 Remote plans
 Application Server

 Oracle Forms
 Oracle Portal
 App Upgrades
 SQL Server
 Oracle Concepts
 Software Support

 Remote S


 Consulting Staff
 Consulting Prices
 Help Wanted!


 Oracle Posters
 Oracle Books

 Oracle Scripts

Don Burleson Blog 









Backing up the Application Server 10g

Oracle Application Server Tips by Burleson Consulting

The first step is to define you backup strategy and implement it.  You must periodically review you strategy to insure that it still meets your business needs.  A backup strategy defines when you need to backup each server, and how you will recover if a server goes down.  Part of this discussion must also address down time cost.  If a system has a high per minute downtime cost (thousands of dollars per minute) then there is a need to implement a high available solution, even if system availability requirements are only 10 hours per workday.  Most companies start by stating that their system must be available 24 hours a day, 7 days a week.  In this case, refer to chapter 9, High Availability.  Faced with the expense of these solutions, many companies more realistically define their availability needs based on user/customer requirements.  Your backup strategy must support your business needs.

The system availability requirements will determine whether you can perform cold or hot backups.  A cold backup requires that you shutdown the application server, to include the Metadata Repository.  A cold backup is consistent across the application server components because they are not running when the backup is taken.  Cold backups are the easiest to execute and maintain.  Hot backups are required when the application server must remain available to respond to users during the backup process.  A hot backup of the middle tier instances is a relatively easy process but is muck more complicated for the Metadata Repository database and the backend database.  Finally there are solutions external to the Oracle software to automate backups such as products from Veritas etc.  For information on these products you should refer to the vendor.  For this discussion, we will focus on the application server and the metadata repository database.

What to Backup

On each server within the application server topography there are four types of files that need different levels of protection.  This is true for both the application server and the Oracle9i database.  Your backup strategy needs to address each category of file.

First are the operating system files.  These files make up the OS and you need to refer to the OS reference to determine which OS files needs protection.  Normally these files do not change over time unless you change the configuration or apply patches.  A full backup, taken after updates will normally suffice. 

The second set of files are the Oracle product files.  These files are located in the instance $ORACLE_HOME and the oraInventory directories.  These include the product binary files.  Like the OS, these files do not change once installed unless additional components or patches are installed.  Again, a full backup after changes in configuration or patches will suffice.

The third set of files is the data, configuration and application files that change during the normal course of operation.  These include files maintained buy the user application, the Oracle Internet Directory, and the Metadata Repository database data files, control files and archive log files.  It is these files that backup protection must be routinely maintained.

The final set of files are the log files.  Unless you have a audit, SLA or other reason to insure that these files are protected, their loss will have little impact and they can be excluded from a backup routine.  Note, this does not included database archive log files that are critical to the database recovery mechanism.

The easiest strategy is to execute a full backup of all servers each night.  While easy, there are drawbacks.  First the backup will be large and time consuming.  If will also be time consuming if you are required to restore one file, which must be located within the full backup.  Second it is wasteful of resources because for the most part you are constantly backing up unchanged data.  A more useful strategy would be to execute a full backup on the weekend and do nightly backups of the third set if files. 

Finally, it is important to know your system because you may only need to backup the middle tier once with nightly backups of the infrastructure tier.  If the files on the middle tier are static then they only need to be backed up when changed.

Application Server Protection

For the most part, the files that make up the application server do not change over time.  Static web pages and configuration files will not change unless you update the user application or deploy additional applications.  For example, if the Web Cache is placed in front of a cluster of application servers if only needs to be backed up when the configuration changes.  It is a waste of resources to nightly backup the Web Cache server since the only data that has changed is in the cache itself and you don't want a backup of the cache data.  On the other hand, the Infrastructure instance contains OID which normally is regularly updated by the user application and the application server. 

Backing Up Application Server Instances

Developing a backup strategy for a middle tier instance requires knowledge of the user application running on it.  For instance, if the user application maintains local data or state information in a local file, that file may be critical to routinely backup.  If all persistent data is maintained in a back-end database, there may be no requirement to nightly backup a middle tier instance.  Normally, a nightly backup of the instance $ORACLE_HOME will suffice.  You can also take incremental backups of only changed files, however this could lead to problems while attempting to find a file that needs to be restored.  Since it was only backed up when changed, you will have to first identify which backup contains the file before beginning the restore process.  To completely restore the instance, you would need to restore the last full backup and all later incremental backups to insure that you have restored the latest version of each file.  For that reason, I recommend that you take a full backup of the instance $ORACLE_HOME for each routine backup.  This can be accomplished using the tar utility or you backup utility.

[oracle@appsvr oracle]$ . ./midenv
[oracle@appsvr oracle]$ cd $ORACLE_HOME
[oracle@appsvr oracle]$ tar cvzf /u03/oracle/backup/ . 

The above commands will source the mid tier environment, change to the mid tier?s $ORACLE_HOME directory and then backup that entire directory to the backup location.  I can then backup to tape in the background if needed.  This command can be used while the instance is running.

In the case of the Infrastructure instance, the Metadata Repository database is an Oracle9i database and must be maintain accordingly, see next section.  You still want to backup the database files with the instance but you will also have to execute a database backup (Hot or Cold). 

Finally, do not forget to backup the oraInventory directory whenever you take any action that requires starting the Oracle Universal Installer.  This is where Oracle saves information about what is installed on the server to include patch information.  If you have to rebuild the server you will need to restore the oraInventory directory in order to apply patches/upgrades in the future.  When you backup the oraInventory directory, include the oraInst.loc and oratab files.

Now that we have a backup, hopefully you will never use it.  But if you need it, you need to know how to use it to restore an application server instance.

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

If you like Oracle tuning, you may enjoy the new book "Oracle Tuning: The Definitive Reference", over 900 pages of BC's favorite tuning tips & scripts. 

You can buy it direct from the publisher for 30%-off and get instant access to the code depot of Oracle tuning scripts.


Oracle Training at Sea
oracle dba poster

Follow us on Twitter 
Oracle performance tuning software 
Oracle Linux poster


Burleson is the American Team

Note: This Oracle documentation was created as a support and Oracle training reference for use by our DBA performance tuning consulting professionals.  Feel free to ask questions on our Oracle forum.

Verify experience! Anyone considering using the services of an Oracle support expert should independently investigate their credentials and experience, and not rely on advertisements and self-proclaimed expertise. All legitimate Oracle experts publish their Oracle qualifications.

Errata?  Oracle technology is changing and we strive to update our BC Oracle support information.  If you find an error or have a suggestion for improving our content, we would appreciate your feedback.  Just  e-mail:  

and include the URL for the page.


Burleson Consulting

The Oracle of Database Support

Oracle Performance Tuning

Remote DBA Services


Copyright © 1996 -  2017

All rights reserved by Burleson

Oracle ® is the registered trademark of Oracle Corporation.

Remote Emergency Support provided by Conversational