The other key directory shown in Figure 5.3 is the ORACLE_BASE directory. This directory serves as a gathering point under which you can store multiple versions of the Oracle software. For example, you may be running on version 8.0.1, but want to try out the 8.0.4 software. Having multiple Oracle homes enables you to test the new 8.0.4 software on a test database while keeping the production database running on the 8.0.1 software.

The next issue when you are planning where to put the software is how much space to allocate for this purpose. There is no magic number. As part of the exercise in the next section, you learn how to figure the amount of disk space for the Oracle software based on which products you are loading. Remember, Oracle makes a wide range of software. It is too difficult to make tapes for each customer based on what that customer orders, so Oracle ships in a few different bundles. This usually means that you get far more software on your distribution tape or CD-ROM than you need for your work. Therefore, you must go through and determine the software packages that you will be using and allocate space for them on the software disk, in the database itself (for support tables and so forth) and in memory.

I always plan on having at least two full releases of the Oracle software on my system when I am performing the sizing exercise. Obviously, I do not want to maintain two versions routinely, and I like to have all databases (production and development) using the same version to make things run more smoothly. However, when Oracle ships out a new version of the database, I always like to run a thorough test against a test or development instance before I try it out on the production databases. I also like to test it against each of the test instances, if there is more than one, because different applications can run into different problems with a new release of supporting software, such as the RDBMS. Of course, if you have far more nerve than I do, you can just let this new, untested software fly on your most important, mission-critical production database. One final note: Leave yourself at least a 10 or 20 percent margin for error when sizing the disk space for your software. The software has grown in size since I have worked with it, so this space helps accommodate your next version. You also may find out that you need additional components (for example, SQL*Net) as your applications and user needs change over time.

Administrative Directories

The other structure that I tend to use frequently under the ORACLE_HOME directory is the admin tree. This is where you will find log and trace files that can tell you what is and has been happening to your database. I also like to put create directories under here to store the data definition language (DDL) SQL scripts that I use to create database objects. I like putting them here because these directories are set up so that only DBAs can access them. In locations where the DBA does not control the DDL, I store these scripts with the application software.

Local Directories

Oracle recommends putting a local subtree for locally developed Oracle software, but I have found that most places have their own directories for applications. If they use version control software such as PVCS, a number of directories are used. There will be some kind of scheme to control the level of the software modules (production, test, development, and so forth). This local subtree can be useful if you have the responsibility of controlling software builds in addition to being the DBA. Otherwise, put the local applications somewhere else.

Data and Log Directories

The next requirement is some disk space to store your data, log, and other files. In a really small instance, you can put your data on a single disk in a single directory. Generally, I like to split data files from different databases into different directories, which have names that identify the database. When I restore a test database that has been corrupted, I want to make sure that I am restoring the test data from tape and not the production data. Of course, input/output loading is a function of the disk drive itself, so having multiple directories does not balance this load. Think of it as being a neat housekeeper. The basic concepts for data directories are shown in Figure 5.4.

Figure 5.4.  Recommended data directory layouts.

The exact names of the disks and directories vary between different computer systems. On some operating systems, you may have to specify the disk drive by a letter (for example, Novell o:\oracle) or some other designator. However, the general concepts remain the same. You designate an Oracle Home and some data directories. You lay out the data files depending on the number of disk drives that you have and what the input/output load is that you expect to balance based on application needs.