Optimal Flexible Architecture (OFA)

The Optimal Flexible Architecture (OFA) is a set of guidelines and conventions regarding the installation of the database software and the location of individual Oracle databases. OFA offers best-practices guidelines for database installations. Each major release of the Oracle database includes its own OFA guidelines and we will now discuss the current state of this architecture for the present release.

If you perform a standard installation of the database software or accept the creation of a starter database, then the OFA guidelines are implemented for you. Alternately, you can perform a custom installation of these components, but following the OFA structure is still essential. OFA includes these elements:

• Locating the Oracle database installation separately from the server operating system.
• Defining an ORACLE_BASE location
• Defining an ORACLE_HOME location
• Defining the database files and recovery areas
• Using the OFA structure for a database upgrade
• Using the OFA structure for a multiple installations

ORACLE_BASE

The first objective of the OFA is to segregate the location of all Oracle files from other files or products which might reside on the same system. Furthermore, one must distinguish between different owners of different Oracle software installation. Towards this end, ORACLE_BASE is a logical location in which all Oracle files for a given server and software owner are stored. The basic form of this logical location is:

mountPoint/app/oracleOwner

On a Linux or Unix platform this same location might be as shown here, where oracle is the operating system user which owns the database software installation:

/u01/app/oracle/

In an MS Windows environment where the Administrator user performed an installation of the database, the ORACLE_BASE location might be as follows:

C:\app\Administrator\

ORACLE_HOME

The next objective of OFA is to isolate the database software files from the database storage files. Also, this seeks to separate the database software files from one version of the database to another. The basic form of this logical location for the database software is:

ORACLE_BASE/ORACLE_HOME

Database Files & Recovery Areas

Database storage of live data is separate from both the database software and the database recovery files. The database storage area is defined from the ORACLE_BASE starting point and is typically named as follows:

ORACLE_BASE/oradata

Likewise, the storage for database recovery files, managed by a facility known as the Flash Recovery Area, generally follows this form:

ORACLE_BASE/flash_recovery_area

Physical Paths

Based upon this structure, consider some hypothetical physical directory paths which illustrate the use of this configuration.

For example, suppose that one is operating in a Linux environment using release 1 (R1) of the 11g database. These may be the paths which are in use.

Alternately, examples of these physical paths within an MS Windows platform might be as shown here.

With this basic structure, a series of changes can occur to the database environment while potential conflicts and invalidations are avoided. Consider some scenarios which we discuss next.

What If The Database Software Is Upgraded?

Now, suppose that one upgraded to release 2 (R2) of the database. Using this architecture, the files representing the user database, and other related structures, are unaffected. A new ORACLE_HOME location could be defined for R2 and the database restarted using that new release. The original R1 software files would also be unaffected and can be retained until such time as one confirms that the upgrade was successful. At that point, the software files for R1 could be removed. To illustrate, after a successful R2 upgrade, the following Linux / Unix paths might exist:

You can see that the storage location of the database files and recovery area have not changed, while the software location of the new version has changed.

Notice an example of a directory structure from exactly such a scenario, as it might appear on an MS Windows platform.

What If There Are Multiple Installations?

Suppose that a single server contained the Oracle Database and the Oracle Database Client software for R2. The following distinct ORACLE_HOME paths might easily co-exist for each product:

/u01/app/oracle/product/11.2.0/dbhome_1

/u01/app/oracle/product/11.2.0/client_1

Or suppose multiple instances of the same product were installed on the same machine. Multiple instances of the Oracle database software might reside in these distinct ORACLE_HOME paths:

/u01/app/oracle/product/11.2.0/dbhome_1

/u01/app/oracle/product/11.2.0/dbhome_2

/u01/app/oracle/product/11.2.0/dbhome_3

The data files for each of these database instances would likewise be isolated from each other within the data storage paths. In this example, notice how the database names are included within the data storage paths:

/u02/app/oracle/oradata/test8a

/u02/app/oracle/oradata/test8b

/u02/app/oracle/oradata/test8c