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 










Oracle Application Server Tips by Burleson Consulting

At the midtier, there normally are multiple instances of the application server, each implementing Oracle?s HTTP Server (OHS) and possibly multiple OC4J containers running multiple copies of the application. As we discussed in Chapter 4, each OHS server implements multiple processes to handle requests, the loss of one having little or no effect on the server. OHS also has the ability to restart without shutting down. As each process completes its request, OHS will kill it and restart it with the new configuration. Thus OHS is available even while reconfiguring itself. Additionally OHS will use mod_oc4j to load-balance to the OC4J containers, providing redundancy within the midtier instance. The mod_oc4j module insures that the OC4J container is running before sending it a request. Because OC4J containers clustered in an island replicate their state to all containers within the island, mod_oc4j can reroute a request to another container within the island if a container is no longer running and still maintain the session?s state.

The midtier instances are clustered using the infrastructure tier for configuration, OID and SSO. A cluster is a group of midtier instances that share a common configuration and work together to distribute the load across multiple servers. A cluster is created using the Enterprise Manager Application Server Control or the DCM utility. All instances in each cluster have the same configuration, and changes to one instance will be propagated to all the other instances in the cluster. If you deploy your application onto an instance that belongs to a cluster, it is propagated to all other instances in the cluster. To create a cluster using the Enterprise Manager web site, you need at least two instances associated with an infrastructure. Figure 9-2 shows an infrastructure with two instances. For this example, both midtier instances are installed on one server; normally they would be installed on separate servers.

Figure 2: Enterprise Manager Farm

Select the Create Cluster button to create a new cluster. Enter the name for this cluster (I used TestCluster1), and select create. This creates an empty cluster.

Figure 3: Enterprise Manager Farm with TestCluster1

Now we need to add the two midtier instances to the cluster. Select the midtier instance to add to TestCluster1 and select the Join Cluster button. You will get a list of available clusters and a warning that unless the cluster is empty, the OC4J instances will be invalidated because they will be reconfigured to match the other instances in the cluster. For this example I created two midtier instances, midtier_1 and midtier_2. I deployed the Pet Store application into midtier_1 and then added it to TestCluster1. Next I added the midtier_2 instance to the TestCluster1 cluster. From the Enterprise Manager Farm page, select the TestCluster1 link to list the instances and their status, which make up the cluster.

Figure 4: Enterprise Manager TestCluster1 status page

You can now view the status page for each of the instances in the cluster by selecting their link. The clustered instances share a common configuration. Applications deployed into one instance will automatically be deployed into all of the instances that belong to that cluster. In this example I deployed the Pet Store application into midtier_1 before adding it to the cluster. Since it was the first instance added, the cluster assumed its configuration. I then added midtier_2 to the cluster, and the Pet Store application was automatically deployed into the midtier_2 instance when it was added to the TestCluster1 cluster.

Figure 5: Enterprise Manager Midtier_2 status page

This ability to cluster instances greatly simplifies the management of multiple midtier instances. When the midtier needs an additional instance to support a growing workload, you can install a basic midtier instance on an additional server and simply add it to the cluster. The new instance will be configured to match the other instances in the cluster.

Note: You must reconfigure the Web Cache to use the new instance. Adding the instance to a cluster will not configure it to use a common Web Cache. See Chapter 5 for information on configuring the Web Cache.

Mid_tier instances (standalone and clusters) associated with a single infrastructure make up a farm. If an instance does not belong to a farm, you must add it to the farm before adding it to a cluster within a farm. Normally, instances are added to a farm when they are installed, but you can add an instance to a farm by navigating to the instance web page and using the Use Infrastructure Wizard. Once an instance is part of a farm, it can be added to a cluster or remain a standalone instance. It is possible to cluster instances without an infrastructure instance, but you lose the cluster manageability because you are now responsible for insuring that configuration changes are propagated to each instance.

Infrastructure Tier

The infrastructure tier not only contains the infrastructure instance but also the repository database. The diagram in Figure 9-1 shows the infrastructure tier configured within a Cold Failover Cluster. Unlike the midtier clusters that are all active, in a Cold Failover Cluster, only one server is active, while the other is standing by in case the first fails. This configuration requires an OS-supported clustering system such as Sun Cluster. When the active node fails, the clustering software restarts the failed programs on the cold node. An exciting new feature of Oracle Application Server 10g is the ability to create the repository database in an existing database. This allows the repository database to take advantage of an already existing high-available back-end database that may implement RAC or be hosted on a large, highly available server. This provides availability for the repository database but not for the infrastructure instance. Oracle will soon provide a capability to cluster and load-balance multiple infrastructure instances so that you can create a redundant infrastructure without using a cold server on standby.

Back-end Database

Behind the application servers is some type of continuous availability database using RAC, DataGuard, or replication. Oracle Real Application Clusters, or RAC, creates multiple database instances of the same database and allows for very fast recovery from an instance failure. DataGuard implements a standby database that is constantly updated from the active database. If the active database fails, the administrator will convert the standby database into an active database, reconfigure the network to point to the new active database, and resume processing. Replication implements multiple active databases that exchange changes between them so that they are consistent (with a small time delay). With replication, if one of the databases fails, processing continues on the remaining databases. Normally the back-end database will implement RAC, which is why the ability to implement the infrastructure?s repository database in the back-end RAC database greatly improves reliability. Implementing Real Application Clusters is outside the scope of this book. For additional information on implementing RAC, refer to the book Oracle9i RAC: Oracle Real Application Clusters Configuration and Internals by Mike Ault and Madhu Tumma (Rampant TechPress, 2003).

Fig 6 Typeset text:

Application Servers

Data Guard


Real Application Clusters

Figure 6: Highly available database solutions

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