Starting with Business Needs

Determining the needs of a business is a simple concept. The users and developers tell you what they want and you can implement it. The problems arise when the users describe things in general terms and you are the one left to determine the details. Here are some specific details that you need to have as a DBA before you can construct a sound installation plan:

•  The supporting tools that will be used for application development or operation

•  The rough size of the database and any logical groupings of tables

•  A feel for the daily processing cycle

•  The expected data traffic patterns for the various tables

•  If you are not acting as system administrator, a feel for the disk drives and tape drives that you will be allocated

•  User requirements for data backup, recovery, and reliability

Tools

The first requirement you should be provided with is a list of the tools that are required to support the database itself. Oracle provides a number of options for development. There are the Forms and Reports generators provided by Oracle and third-party vendors. There are also a number of precompilers that are available as part of the Oracle environment (Pro*C, Pro*COBOL, and so forth). These types of products are relatively simple to integrate. They usually involve merely loading them from the distribution media and linking them with the database as part of the installation process.

If you are using a third-party development tool, you should check its requirements for interfacing with the Oracle database. There may be options required or specific version levels of products that you need to install. The vendor may also require table space or dedicated memory processes to be operational and you need to plan for these items. This process is no more difficult than the one that you use for the Oracle-supplied products. You just need to remember to add this during your planning process so that you do not have to come back later and reconfigure your system. As always, make sure that the products will work with one another (especially the operating system and Oracle release).

Sizing

Next on your list of data to collect before planning the instance is a rough estimate for the tables that the users or developers want to create. It is also important to determine whether there are any logical groupings of tables (base data tables, frequently used lookup tables, and so forth). This affects the tablespaces that you design and how you split tables between disk drives to level input/output loads. It also helps you determine the size of supporting tablespaces, such as temp and rbs.

Traffic Patterns

Another important factor when laying out data is an understanding of the expected data traffic patterns for the tables. You may want to locate tables that have heavy usage on different disk drives. If you have a small number of tables that receive extremely high data traffic, you may want to consider disk striping, multiple database writers, and the parallel query option when laying out your plans.

Daily Processing Cycle

You should also be provided with a feel for the daily processing cycle of the application. This is important when you decide whether to use archive logging. For data warehouses wherein data updates occur in a single large batch at night, it is possible to perform cold backups just after the batch upload and not use archive logging. On heavy transaction processing applications, you need to use archive logging to be able to recover all the transactions made during the day. If all the activity is concentrated during specific periods during the day, you might need to consider options such as parallel query and multiple database writer processes.

Map System Resources

Because your task is to map user requirements to the Oracle software and available system resources, you need to know what those system resources are. If you are also the system administrator for the server, you can map this out for yourself. If you are not, you need to coordinate with the system administrator to determine the following:

•  The memory that will be available for Oracle and Oracle user processes. In most database servers, you can use all the system memory except that used by the operating system. However, there are other applications that have memory-resident components, so you should check to see whether you are competing with anything else. This can vary from as little as 16 megabytes to well over a gigabyte.

•  The tape drives available and whether any of them can be dedicated to Oracle uses such as archive logging. Some systems have tape drives that are available only to operators and therefore cannot be used by the DBA for routine tasks.

•  You need to know which disk drives are available, how large they are, and what options are available to you for RAID storage, disk striping, disk mirroring, and so forth.

Backup, Recovery, and Reliability

Finally, it is important to get confirmation from the users as to what their requirements are for backup, recovery, and reliability. Specifically, if ultrahigh availability is desired and the users are willing to pay for it, you can mirror the disk drives so that if one drive fails, you can still access data from the other drive. Some development installations are cost-conscious and some developers are willing to live without disk mirroring or disk space for archive logging in return for lower system costs. The key from the DBA point of view is to document the requirements, get everyone to buy into them, and then construct a database that meets these requirements.