8.2 Optimal Flexible Architecture (OFA)

< Day Day Up >

---

8.2 Optimal Flexible Architecture (OFA)

OFA is a standard configuration recommended by Oracle Corporation for its customers to promote a standard disk configuration or directory structure, for a consistent way of managing disks and directories. Almost any relevant books, including documentation available from Oracle Corporation, will have topics of discussion on the OFA standards. While many companies have not used OFA to configure their directory structure, it is a good practice to follow some form of standard for consistency among the various installations within the organization. This helps in the transfer of knowledge when new associates are hired, and helps in operating under some standard principles.

Implementing the OFA standard is not a requirement for installing and configuring Oracle but rather a general guideline or standard for efficient configuration.

While OFA was originally written and recommended by Oracle for the Unix platforms, many companies have applied and written similar standards for the Windows platform.

Figure 8.1 explains the basic high-level hierarchical view of the directory structures and layouts as defined under the OFA standards.

Figure 8.1: Optimal Flexible Architecture (OFA).

This is exactly what the OFA standard is all about, basically a directory structure to keep the files across all installations of Oracle in an enterprise in a consistent manner. From the root level there are n levels, based on the disk configuration. OFA recommends 9-, 12-, 18-, or 24-partition disk configuration.

To help explain the structure easily, only four levels have been shown in the diagram, ORACLE_BASE/app/admin and the U01 through U04../oradata structures.

The ORACLE_BASE directory structure and its subdirectories are the main product and database configuration directories. Under the app directory are product and admin directories. The product and admin directories are further split into more subdirectories. Under the product directory is a specific version-related file and under the admin directory is the SID (in the figure it is represented by PRODDB) specific administration file. The parameter file is located under the pfile directory, the alert log file under the bdump directory, and background process files are located under the udump directory.

The above descriptions are all centered on a single instance, single database configuration. In the case of a RAC implementation, this is definitely not the case; we have two or more instances talking to a common shared database. As we have discussed earlier, it is only in a clustered database environment like OPS or RAC that the true definition of an instance and database is laid out.

Now how do we differentiate between these instance-specific information and structure? This discussion covers various areas of a RAC implementation and also depends on what kind of operating system RAC is being installed. For example, if the installation is on a Sun cluster^[1] or an HP-UX cluster, Oracle requires that the data files are stored on raw device partitions. However, if RAC is being installed on an HP Tru64 (previously called COMPAQ Tru64) platform, or on either the Linux or Windows operating system (with Oracle Release 9.2.0.1 or higher) the data files could be stored on file systems.

Note

We will look at raw partitions in more detail later in this chapter.

The parameter file used in a RAC configuration is also different compared to a single instance configuration because, in this case, multiple instances would require their own parameter file and certain parameters have the same values, while the others have different values. In Oracle 9i, all the parameters that are specific to an instance and that have values common across instances, can be stored on one file; they can also be located on a common disk for providing visibility to all instances participating in the clustered configuration.

Thus the original OFA specification has been slightly modified to accommodate the commonness of the clustered database while also providing an opportunity to identify specific files such as the udump, bdump, archives, etc., located for each instance. So where a configuration that requires Oracle and an O/S for each instance is located on its own disks that are not shared across the cluster, Figure 8.2 shows a way to organize the files using a modified version of the OFA standard. While for the most part, the same standard of hierarchical definition is maintained, in certain areas like the admin layer a slight modification has been made to more specifically identify the Oracle-generated instance specific files. The product and admin directories are further split into more subdirectories.

Figure 8.2:  

Under the admin directory is the database name (in the figure it is represented by PRODDB) specific administration file. Under this is the pfile and directories that contain files common across instances, or files that are common and also contain prequalified parameter definitions. The instance-specific files like the trace and alert log files are located a level deeper.

As we step through the various phases of installation and configuration of the database a more detailed explanation of the contents of each of these directories will be given.

^[1]The var VERITAS file system is also available for Sun platforms, in which case raw devices are not required.