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 









Configuring OHS and Using Server Logs

Oracle Application Server Tips by Burleson Consulting

The OHS is configured using one main configuration file called httpd.conf, and a supplemental file called oracle_apache.conf.  The both files are located in the $ORACLE_HOME/Apache/Apache/conf/ subdirectory.  Each Oracle9iAS instance installs an OHS server and has a unique httpd.conf file. 

When OHS starts, it reads three files: httpd.conf, access.conf, and srm.conf.  The oracle_apache.conf file is used to load and configure specific Oracle modules and is an INCLUDED file at the end of httpd.conf.  It is common practice to place all configuration data in the httpd.conf file and leave the access.conf and srm.conf files empty.  At this point, we will walk through a sample httpd.conf file and discuss the important configuration parameters.

Like the familiar init.ora of Oracle databases, the httpd.conf file starts with heading data and uses the?#? character for comments.  When the Oracle Universal Installer creates the httpd.conf file, it sets the parameters necessary to get the application server up and running.  Most settings are appropriate and should only be changed when specific situations warrant.  Important: read the comments before making changes.  The parameters are grouped into three sections: global parameters, the default server parameters, and virtual host parameters.  At the very end are the Oracle specific configuration files.

Global Parameters

ServerRoot in the OHS is analogous to the database ORACLE_HOME. When OHS is looking for configuration or log files it will use the ServerRoot as the base directory. 

ServerRoot "/home/oracle/oraportal904/Apache/Apache"

When defining a file location, placing  ?/? (?X:\? in windows) defines a path/file in httpd.conf and tells OHS to use only that path/file.  If the path/file is defined without a leading ?/?, then OHS will consider it a relative path/file and append the ServerRoot to the front.  Thus, if the ServerRoot is set to ?/opt/oracle/mydir? and ErrorLog is set to ?logs/error_log?, OHS will log errors to ?/opt/oracle/mydir/logs/error_log?.

PidFile /home/oracle/oraportal904/Apache/Apache/logs/

As we saw earlier, OHS prespawns server processes (or threads in windows) to speed the handling of requests.  The UNIX OS pid of the parent server process is stored in the PidFile location.  To reset log files or kill OHS from the operating system you need to use the pid located in the PidFile.  Other parts of the application server may also need this information so it is not recommended to change the file name or location once installed.

MinSpareServers 5
MaxSpareServers 10
StartServers 5

The Server Pool Size parameters configure the number of child server processes created when starting, and dictate when to add or remove processes.  In this case, the OHS spawns five child server processes on startup and checks periodically to insure that there are five spare processes waiting to handle new requests.  If the processes are fewer than specified in MinSpareServer, the parent process will spawn additional processes.  If there are more than specified in MaxSpareServers, the parent process will kill some of the idle child processes.  This allows OHS to dynamically adjust to changing load levels.  Set StartServers to a number between Max and Min SpareServers, or OHS will simply adjust the number on it?s first check.

MaxClients 150

Max Clients is similar to the database processes parameter.  It is used to limit the number of child server processes that OHS can create.  When it reaches this limit, all new requests are rejected.  It should be set higher than the expected highwater mark of users connected to the system.   It can be used to limit resource use on a restricted system. However, refusing connections from clients is rarely a good idea.  Normally, it is better to run slow than refuse the client.  The main value of this parameter is to stop the run away creation of child processes in case of an error.

# LoadModule foo_module libexec/
LoadModule mmap_static_module libexec/
LoadModule vhost_alias_module libexec/

The next important task is the loading of module directives.  Here, OHS reads the directives from each module file so that it can dynamically load and use the module when needed.  One important note:  some modules rely on other modules, therefore the order that OHS reads each set of directives is important.  Do not change the order of the module listings unless you are sure you will not break another module. 

All the modules available to OHS are listed under ?ServerRoot/libexec? and end with ?.so?.  To list the modules currently loaded, use ?ServerRoot/bin/httpd ?1?.

Default Server Parameters

Here, we transition to the Default or Main Server Parameters.  These parameters are used by the child processes, and as we will see later, establish the default parameters used by a Virtual Host, unless overridden.  The default parameters start with the ports that OHS will listen on.

Port 7778
Listen 7779

The port is where OHS waits for a request.  Normally, HTTP requests are sent to port 80 by default.  Oracle has set the port to 7777 for the application server.  If you install multiple instances on one physical server, the first instance will be assigned port 7777.  As each successive instance is installed, the OUI will detect that 7777 is used and will increment the port number by 1 until it finds an unused port.  Thus, the second instance installed will be on port 7778, and the third on 7779, and so forth. 

The Listen parameter allows you to have OHS listen on additional ports or even for other IPs.  It can be used either with the Port parameter or in place of it.  If your server is on multiple networks, you can use the Listen parameter to limit the networks that OHS accepts requests from.   For example:  Listen   will direct OHS to service requests that arrive at that address.  Listen replaces the BindAddress directive that performed the same function.  However, you can have multiple Listen parameters, but you can only have one BindAddress parameter.  A second BindAddress will overwrite the first.  BindAddress is no longer available starting with Apache 2.

User oracle
Group oracle

Apache normally uses port 80 and is started as root.  Apache must be started as root to use ports below 1024.  However, for security reasons, you do not want Apache responding to requests as root.  By setting the User and Group parameters, you are telling the primary server process (which is running as root) to spawn child processes running under the user and group specified.  However, since OHS uses ports above 1024, it is started under the user and group that it was installed under, and the User/Group parameters are not required.  If you decide that all or some of your OHSs will listen on port 80, you will have to start those OHSs as root and use the User/Group parameters to re-privilege the child processes.


The ServerName is a misunderstood parameter.  If defines the response name and is used in redirecting URLs (which we will discuss later).  It can be either a fully qualified domain name or an IP address.  If you are using Virtual Hosting (described later in this chapter) you can override this parameter in the Virtual Host. 

Be careful changing the ServerName. If you create a name that happens to be an actual domain name, you might confuse your clients or cause redirection to fail.


The ServerAdmin parameter is an email address that is included on most server-generated documents, such as error messages.  This will give your clients an address to contact if necessary. 

DocumentRoot "/home/oracle/oraportal904/Apache/Apache/htdocs"

The DocumentRoot parameter defines the directory that OHS will serve static content files from.  It can be defined explicitly, as in the example, or as a directory off the ServerRoot.  The above example can also be defined as ?DocumentRoot ?htdocs??, since our ServerRoot is ?/home/oracle/oraportal904/Apache/Apache?.  The directory defined in DocumentRoot can be any directory that the User/Group of the child processes has permission to read, including a Network File System (NFS).  Static files are normally separated into subdirectories located off the DocumentRoot such as:

htdocs ? opening page
htdocs/resume ? resume for company employees
htdocs/consulting ? company consulting services
htdocs/consulting/database/oracle ? the oracle database consulting pages.

Many administrators are starting to change the DocumentRoot to ?/var/www?.  This is fine as long as the User/Group has the necessary permissions to access the files.

Now that we have defined the document directories, we need to tell OHS what actions it can perform in each directory.  To do this, we will introduce Container Directives. 


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