Page 93
Page 94
The Oracle database is a powerful yet complicated data storage and retrieval system, capable of supporting enormous workloads while maintaining high levels of performance, security, and data integrity. An integral part of a successful database is the manner in which the software is installed and configured on the database server. This chapter examines the role the server software and configuration plays in the database environment, and deciphers the sometimes confusing aspects of the Oracle server installation. This chapter also explores strategies for creating your Oracle server environment, as well as your first Oracle database. Finally, it looks at what you can do to familiarize yourself with an unfamiliar Oracle database.
When configuring a server to house the Oracle software, you must take several key factors +into consideration. These include the flexibility of the design, the ease of administration, and the simplicity of the structure. If you design your environment with these points in mind, you will be rewarded with an environment conducive to your uptime and performance goals, as well as avoid the problems and anxiety that a poorly designed server structure can create.
The Oracle standard for creating and configuring your Oracle environment is named the Optimal Flexible Architecture, or OFA, Standard. It is a set of rules and guidelines that enables you to easily create and configure a production-level Oracle server. As the name states, the OFA Standard was created to give you the most flexible Oracle environment without sacrificing usability, ease of administration, or simplicity of design.
Mr. Cary Millsap of Oracle Corporation wrote the OFA Standard in the early 1990s. The definitive white paper on the structure can be found at http://www.europa.com/~orapub/index.html. Mr. Millsap's article goes into much more detail than will be described here. His white paper deals with configuring the entire environment, while we are concerned with the creation and configuration of the operating system directory structures and naming conventions used to support the Oracle database. Mr. Millsap's OFA Standard paper is required reading for any Oracle DBA or systems integrator interested in the best practices for implementing an Oracle installation.
Mr. Millsap sums up the purpose of the OFA Standard Recommendations with his statement that "A good standard should act as a strong floor, without becoming a ceiling that inhibits `creative magic.'" The OFA Standard Recommendations are just thoserecommendations. Your specific environment will have requirements and specifications that are best met with methods not included in (or contrary to) the OFA Standard. However, close study of the OFA Standard will reveal many best practice methods that would only be obvious through difficult trial, error, and experience.
The first step in configuring your environment is to decide on the naming and creation of the OS mount points and top-level directories of your Oracle installation. As with many
Page 95
configuration items, the implementation varies from UNIX to Windows NT, but the general concepts remain the same. The first OFA rule relates to this topic and is
OFA Recommendation 1: Name all mount points that will hold site-specific data to match the pattern /pm, where p is a string constant chosen not to misrepresent the contents of any mount point, and m is a unique fixed-length key that distinguishes one mount point from another.
In other words, create top-level mount points that are unique, but do not have meaning in and of themselves. The character portion (p) should be short and simpleone or two characters are ideal. The numbered portion distinguishes the mount points from each other. Each mount point should have the same named portion, and be of the same length, for example, u01, u02, and u03 or ora01, ora02, and ora03.
On a Windows NT server, the different drives and volumes are already separated according to drive letters. This makes the usage of mount-point names as described above unnecessary. Use a directory named orant (the default Oracle name) on each drive to denote Oracle applications and files.
NOTE |
To minimize confusion, UNIX naming conventions will be used throughout this explanation. However, unless otherwise indicated, all of the structure and naming conventions given are applicable to both UNIX and Windows NT environments. |
Using mount points without site-specific, application-specific, or hardware-specific connotations enables great flexibility when reconfiguring your system. Consider the following example: Bob, a novice DBA, names mount points on his UNIX system that refer to the physical disks each mount-point volume is attached to. This makes it very easy for Bob to balance his datafile I/O over drives. By glancing at the pathname, he can tell that his main data tablespace is on DISK01, while his index tablespace is on DISK05. But, as always happens, Bob's database grows, forcing him to add more disks and new hardware. Bob wants to take advantage of his new RAID controller to stripe and mirror some volumes, which means he must reorganize his entire drive subsystem to accomplish this goal. Unfortunately, this also means that if he wants to keep his naming convention, he must rename his mount points and change all of his backup scripts, applications, and so on, to point to the new paths. Bob could have avoided this hassle by using directory names that are unique, but that by themselves have no meaning.
One of the benefits gained from implementing an OFA-compliant configuration is the ease in which multiple applications and multiple versions of the same application can be installed, using the same directory structure. In an OFA environment, each application has its own home directory that stores the binaries, configuration files, and so forth that are necessary for running the application. The next two OFA rules relate to this and are as follows:
OFA Rule 2: Name application home directories matching the pattern /pm/h/u, where pm is a mount-point name, h is selected from a small set of standard directory names, and u is the name of the application or application owner.