Isolation from other application services and environmental variables

One of the most effective techniques for improving the availability of a given ORACLE on NT instance is to isolate the database service from other application services. A production ORACLE instance with requirements to support more than a handful of concurrent users and/or with stringent availability requirements should be run on a dedicated database server. Below are details of specific steps that can be implemented.

1) Do not run the ORACLE instance on a primary or backup domain controller. Services on the PDC or BDC can impact the ORACLE instance, as well as the ORACLE instance having a undesired impact on the PDC.

2) Limit file service access to the database server. Only the DBA's and system or network administrators (plus perhaps a few application developers) need access to the file system. End users should not be able to store documents, spreadsheets, etc., on the file system of the database server. File serving and sharing on the database server absorbs computing resources as well as giving end users an opportunity to accidentally damage data files, executables, scripts, etc., used by the database instance, unless the file system security is tightly managed. In this case, the best course of action is avoidance. There may be lots of space available on the database server, but the assumption should be made that the database will need most or all of that space at some future point in time.

3) Limit print services on the database server. There will likely be very few cases where print services from database server are actually needed. Eliminate this overhead and any associated stability risks by refraining from using the print services through the database server.

4) Limit console login authority. Only the DBA's and system administrators need login authority to the database server. Console login privileges provide the ability to accidentally start or stop a variety of services that can impact the ORACLE instance, as well as the ability to perform a shutdown or kill operating system processes. All of these capabilities can be secured, but again the best policy is avoidance. If a well-meaning user can't accidentally break something, then he or she won't.

5) Secured physical location. The database server should be in a location that is inaccessible to everyone except the administration personnel. Ideally, this physical location should have a sufficient UPS in the event of power failure, and a fire containment system. The database server should not be physically located such that an end-user could accidentally trip over the power cord or network cabling while walking past the server.

6) One ORACLE instance and version per box. Since multiple application services compete for computing resources, only one database instance should be run per box. A database engine will attempt to use all available CPU, memory, and disk workload resources when necessary. Eliminate this competition and any instability that it generates by running only a single instance on each box, especially if these are production instances. Ideally, there should be at least two seperate database servers: one for production, and one for development. This seperation prevents development mishaps, upgrades, etc., from impacting a production instance. In some cases, a quality assurance instance is also justifiable. A good rule of thumb is to keep the development server at about half of the throughput capacity of the production server. In this way, potential performance problems are more likely to be noticed before the application goes into production.

ORACLE8 now provides the capability to have multiple versions installed on the same box through the use of multiple ORACLE_HOMES. This feature can be useful for upgrade activity, but should not be taken as an encouragement to run multiple instances (of the same or a different version) on the same box. The inability to have multiple ORACLE7 versions safely installed on the same NT box constraints the ability to apply a patch to a development instance for testing without automatically applying that same patch to all other instances on the same box. Seperation of instances not only opens up better maintenance windows, it also removes any instabilities resulting from contention and competition of instances.

7) Limit non-ORACLE software, applications, and processes. Due to the nature of Microsoft's Component Object Model, it's shared components, and the object resolution provided by the registry, it is entirely possible to install a non-ORACLE software component that damages an ORACLE-related software component or registry entry. A good rule of thumb is to assume that different applications will not run on the same box until you have explicitly proven that assumption to be false. Whether the non-ORACLE application is a commercial product or a custom creation, it's peaceful co-existence should at least be tested with a non-production instance before installing on a production instance. Ideally, this application or component should be run on a server seperate from the ORACLE database, even if it connects to and does work with the ORACLE instance. SQL*Net/NET8 provides the transport layer that makes the physical location of the ORACLE instance completely transparent to any application, so there is absolutely no reason that a server-side application that interacts with an ORACLE instance has to be installed and run on the same box, regardless of whether it is a middle-tier component, a web-server based component, etc.

8) Do not run a multi-server backup solution from the database server. Although this temptation is appealing because the database server will attain higher throughput on backups with the backup solution physically connected to and run from the database server, it can cause instabilities through competition for resources, and it generally severely limits the window of opportunity for server or database maintenance. Essentially, offline corrections and administrative work cannot be done during the day because of user workload, and cannot be done at night because the database server and other servers are being backed up by the database server. This is especially true of production instances, and can also easily become true of development instances. Avoid this particular temptation, unless the backup apparatus is dedicated only to the database server.