Oracle Server Partitioning Explained

Author: Andy Rivenes (arivenes@appsdba.com)
Copyright AppsDBA Consulting, All Rights Reserved.
Last Updated: 16 October, 1998

Terms Explained

Overview

This paper is an attempt to explain what server partitioning is and dispel some of the myths about its performance, or lack of.

Currently Oracle Applications is certifying newer releases for "Server Partition" mode installations. Server partitioning has become a method for allowing a de-coupling of the database server code requirements from the Oracle Application product file requirements. This allows Oracle more flexibility in certifying new versions of the Oracle Server for database use without having to modify the Oracle Applications product files for linking against new server libraries.

Server partitioning refers to an environment where the Oracle Applications product files are linked with one version of the Oracle Server software, and the actual Oracle database runs on a different version of Oracle Server software. This is typically done where the Oracle Applications environment is being run monolithically (e.g. on one machine), but is essentially the same architecture that is employed when running Oracle Applications in a client/server environment (e.g. where the Oracle Applications product files and processes run on a physically separate machine from the Oracle Applications database). The differentiation here is that there are two distinct versions of the Oracle Server software being employed. 

Oracle Applications Monolithic Architecture

Oracle Applications environments that run on a single machine are said to be running a monolithic architecture. This means that the Oracle Applications database and the Oracle Applications product files and concurrent manager processes all run on the same machine. In addition to this, when using the character mode environment, users of the system log directly into this machine.

Oracle Applications Client/Server Architecture

An Oracle Applications client/server architecture is defined as the Oracle Applications database residing on one server machine, and the Oracle Applications product files, concurrent manager processes, and users residing on a second client machine. There are network traffic implications to this architecture since all of the client connections now use a SQL*Net connection to access the database, but in general this traffic is manageable. The advantage to this architecture is that it provides better scalability in most cases. This is possible for two reasons. The first is that machines can only get so big, there is a limit as to how many CPUs, memory, and disks can be added to any given machine. By adding a second machine into the equation the total growth has been effectively doubled (not quite since this would assume equal workload on both machines). The second reason is that database workload and interactive user/concurrent manager workloads are typically very different. It is not unusual to experience a better than two to one increase in capacity by architecting an Oracle Applications environment in this manner. It should be noted that this assumes a character mode environment, with the advent of SmartClient this advantage has been mitigated to some extent. However, it is almost always more desireable to have an entire machine dedicated to the Oracle Applications database, and to not allow direct client connections to the database server machine.

Oracle Applications Server Partitioned Architecure

An Oracle Applications server partitioned architecture is essentially the same as the client/server architecture except that separate Oracle Server database versions are employed. One version for the Oracle database and one version for the Oracle Applications product file environment. Server partitioning can be employed as part of a monolithic or client/server environment.

The only other difference of note is that in a monolithic server partitioned environment IPC connections are made to the database through the SQL*Net listener rather than bequeathed connections (although IPC connections can also be made in a standard monolithic environment). This difference will be elaborated on in a later section as this is a source of confusion, especially as it relates to performance. 

Implementation Explained

Overview

This section will explain how to implement server partitioning in an Oracle Applications environment and will attempt to dispel some of the myths surrounding this architecture. For the purposes of this section a monolithic server partitioned environment is assumed. In the case of a client/server server partitioned environment the steps are essentially the same except that only one copy of the Oracle Server software is needed for each of the machines. 

Server Installation

Since two versions of the Oracle Server software will be installed it is highly recommended that OFA compliant naming be utilized (e.g. /u01/app/oracle/product/7.3.3). The implication here is that two distinct $ORACLE_HOME environments will be created and they should be owned by the same operating system id (e.g. oracle). Because of the use of two $ORACLE_HOME locations and the corresponding environments it is very important that some thought be used in administering this environment. We highly discourage the setting of the Oracle environment at login time and recommend that a separate script be used to allow the explicit setting of the appropriate oracle environment variables.

The Oracle Server software must be installed once for each version. We recommend not creating a database during this step, and the option to just install the server software should be chosen. As a side note, we never recommend choosing the Oracle Installer option to install the server software and the database at the same time because the default database settings are rarely appropriate and should be changed before actual database installation.

It should be noted that although two $ORACLE_HOME environments will be created there will only be one database created. This implies that there will only be one instance along with its associated memory and processes (assuming this is not a Parallel Server installation). We have heard of some confusion surrounding this issue and wanted to formally clear this up. 

Networking Issues

Since there are two versions of the Oracle Server software installed there are also two versions of networking products available. We highly recommend using the version of Oracle Networking products that are associated with the database that will be built. In general this will also be the newest version of the two available.

This will also require that either two versions of the networking configuration files for client access be maintained (e.g. $ORACLE_HOME/network/admin), or that a common area be used (e.g. /var/opt/oracle). 

Oracle Applications Product File Installation

Once the Oracle Server software has been installed the Oracle Applications product file installation can begin. The only real difference here is that instead of setting the $ORACLE_SID environment variable the $TWO_TASK environment variable will be used. This implies that once the database is built access to the database will be through the network listener (e.g. SQL*Net or Net8). Consideration should be given as to whether dedicated server connections or shared server connections will be utilized for client access. Our recommendation is that all installation and concurrent manager connections should be made through dedicated servers, and that interactive user access can be made either with shared server or dedicated server connections. The decision to utilitize client shared server connections should be made based on resource constraints, and dedicated server connections should be preferred from a performance and administration standpoint.

One other issue of significance is that proper environment variable administration must be maintained. The $ORACLE_SID environment variable should be explicitly unset, the $TWO_TASK environment variable explicitly set, the appropriate $ORACLE_HOME set (e.g. the version that Oracle Applications will use and not the version that the database will use), and that the appropriate $PATH setup occurs. The Oracle Applications Installation Guide does a very good job of detailing these requirements.

All references to the Oracle Applications product file requirements should be associated with the $ORACLE_HOME that is being used for Oracle Applications. However, all RDBMS issues, mainly patches, should be run against the database’s $ORACLE_HOME. Care should be taken to identify which $ORACLE_HOME is to be used.

Network Performance Explained

One of the biggest areas of confusion with server partitioning in a monolithic environment is the impression that there is a performance issue with connections to the database. This largely stems from the perception that connections made natively to the database (e.g. bequeath connections made using the $ORACLE_SID environment variable) are faster than connections made through the $TWO_TASK environment variable. In general this is not the case and an explanation of these two connection methods is probably appropriate. Oracle networking supports both "local" protocols and "remote" protocols. Local protocols are defined as protocols used to connect to a database on the same machine that the request is made from. Remote protocols are defined as protocols that support connections over a network between two machines.

There are actually two local protocols in most UNIX environments, the bequeath or BEQ protocol adapter and the interprocess communication or IPC protocol adapter. The chief difference in these two protocols is that an IPC connection is made through a listener process, and hence can support both dedicated and shared server connections. Bequeath connections are made using dedicated server processes and the code to create this process is part of the protocol adapter. The other difference with a bequeath connection is that in products such as Server Manager no SGA is required to attach to. The key here is that once started both of these connection methods make use of the same "very fast internal mechanism" to quote an internal Oracle technical note.