Memory Allocation and Alternatives

A few additional thoughts on memory area planning are in order. The estimates that you obtain from filling out these requirements tables are based on the minimum needs for the tool itself. For example, suppose you come up with an estimate of 7.6MB for SQL*Forms 3.0 Runtime for your estimated 10 users. This means that 7.6MB ensures that SQL*Forms Runtime will function for you. It does not take into account the fact that if you are running a complex decision-support application, your performance will be severely degraded if you do not allocate an additional 10M to sort the large lists of values that the application returns. It also does not take into account the larger log and database buffer space that is needed for intensive transaction processing environments.

Don’t worry—there is a chapter coming up on tuning that discusses these subjects (Chapter 24, “Oracle8 Database Tuning”). For now, just realize that the numbers that you come up with for memory do not take these factors into account. I always recommend buying a little extra memory. Buying 2GB of memory for a small system is a waste of money. However, trying to get a large system functional with 32MB is almost impossible. Chances are, if you buy a little extra memory, you applications will grow and new releases of the operating system and Oracle will probably need it soon anyway.

Logical Database Design

In many cases, you will be installing your Oracle database before you have completed the design for your system. The logical database design is a description of the tables, indexes and other database objects that will be needed for a given application. You need to have the logical database design completed before you can begin the physical database design. So what if you do not have the logical database design for your application completed? Basically, you allocate space for the data files that you expect to put in place for the user data and concentrate on the physical database design associated with the core Oracle tablespaces (that is, system, rollback, and temp).

Physical Database Design

Recall that your first task in the installation process was to go through the Installation and Configuration Guide to verify that you have the correct versions of supporting software, operating systems, and so forth. Just after the tables listing the compatibility requirements, you will find a series of tables that enable you to calculate the distribution (Oracle software) space requirements, the database (internal control tables for the particular Oracle tools), and the memory space requirements for the software components that you are loading. This takes the form of a series of tables. Figure 5.5 shows an example table of some selected line items from a typical space requirements table for the UNIX versions of Oracle.

Figure 5.5.  A typical space requirements table for Oracle.

DBAs usually photocopy these tables so that they can write on them. Several copies can be useful because you may need to fill in different sheets for each instance. Although you have to load only one version of the Oracle software on a given machine, you have to allocate database space in each application that uses a particular tool. I also find that it is easier to come up with estimates of the number of users on an instance-by-instance (application-by-application) basis for large installations. You will find a number of space calculator tables for the basic server products, the networking products, the development tools, and so on. The goal is to fill out each of these tools as best you can (this is tough when you first start out, so err on the high side whenever possible) and then total the individual sheets to come up with an instance-by-instance total for software space, database space, and memory.

RAID and Other Storage Alternatives

On many computer systems, disk drives used to cost in the five-figure range for storage capacities that were much smaller than your average PC hard disk of today. The thought was that these mainframe and midrange disk drives were engineered so well that they provided a high degree of reliability. Then some folks came along with the concept of RAID. This originally stood for redundant array of inexpensive disks and is now often described as redundant array of independent disks. The concept is that you take a number of disk drives and connect them together logically for speed, reliability, or both.