Constrained Server Topography with Oracleís Application Server 10g

by John Garmany

Before building your Oracle Application Server 10g production system, you have a number of decisions to make. What load will your application place on the server and can the server handle that load? How many servers will be in your topography? Which components will you install on which servers? What is your tolerance for downtime?

If you follow application server best practices, you will need at least four servers for the application server, and that does not include the back-end database. The basic installation includes the Web cache on server one, two middle tiers on server two and three, and the infrastructure on server four. This allows for load distribution, but there are two single points of failure; namely, the infrastructure and the Web cache. This article will discuss installing Oracle Application Server 10g and the supporting back-end database on less than four servers. You might ask, why would I do this? The answer is, because that is what most people do.

Single Server

To start, we will discuss what most believe is the simplest server topography (about which I vigorously disagree), a single server for all components. By single server, I mean one server, usually with 2 ó 4GB RAM supporting an Oracle9i or 10g back-end database, and the entire EE edition of Application Server 10g. Truly a single point of failure!

This configuration is obviously the minimum, and it provides the minimum capability. A quick look at the installation documents will tell you that the Forms/BI install should not even fit on a single server with less that 2GB, yet I have seen a number of these installations. This configuration guarantees that the sever will need to page during operations, significantly impacting response time. On one clientís Linux server (single cpu/1.5GB RAM) the Application Server 10g and the database 10g used 15 percent CPU without any users being connected. While this configuration minimizes the number of servers, managing that one server requires extra work. This configuration will not support many users, nor will it scale to a large application. Likewise, tuning individual components, like the back-end database, is virtually impossible because the server is so overloaded.

Despite its drawbacks, the single server topography may meet your needs if the server is powerful enough to handle the load place on it. If this is the configuration you have selected there are a number of configuration options that can reduce the server load. First, install only what you need. Many of my clients have too much application server. In one case, the client was running the Enterprise Edition of 9iAS to support a mod_plsql application.

This application ran on the Oracle HTTP Server (OHS) and connected directly to the back-end database. The infrastructures, mid-tier, SSO, all the other components of 9iAS were not being used. In fact, the Oracle database comes with an OHS server that supports Jserv and mod_plsql. This client did not even need the application server. By shutting down all the components except OHS, the server suddenly had memory to expand the database, and application performance jump dramatically.

So here are some lessons learned from this experience: Donít install, monitor, and maintain components that you are not using. If you are only using J2EE, donít install the infrastructure. Next, get rid of the Metadata Repository database. Oracle promised to allow you to load the Metadata Repository into the back-end database, and now they have come through on that promise (refer to my earlier article on DBAzine on loading the MR into an existing database). This removes the 9iR1 database previously required to support the metadata repository. Lastly, determine if the Web cache is providing you with any additional capabilities. On such a constrained configuration, the Web cache will be small and may not provide you with any real caching at all. If you find that is the case, simply shut down the Web cache (or donít install it) and point the users directly to the OHS port. Figure two shows the foot print of a complete AS10g install verses the constrained configuration discussed above.

As you can see, by eliminating the Web cache and the separate Metadata Repository, we significantly reduced the memory footprint, and thus could expand the size of the back-end database and middle tier (additional OC4J containers or larger memory for the containers).

Two-server Configuration

Adding a second server will allow you to distribute the load and better optimize the individual components. There are two basic ways to configure AS 10g on two servers, and the one you choose will, of course, depend on you application. Normally, the second server supports the back-end database. However, that is not always the optimal solution. What is surprising to many DBAs is that using the second server to support the Web cache may provide better application performance. The Oracle Web cache was designed to reduce the load on the application server components and the back-end database. By frequently caching server static and dynamic objects, the Web cache acts as the application server proxy, passing back only those objects it cannot serve to the OHS.

Read the complete article here:


Need an Oracle Health Check?

Want to ensure that your Oracle database is optimized?  Our remote two-day Oracle health check is perfect.

In just a few hours we pinpoint all database bottlenecks and we can certify that your Oracle database is tuned.

Just call 800-766-1884 to schedule your check-up!