Optimal Flexible Architecture (OFA)

Optimal Flexible Architecture (OFA)

OFA is a method for configuring the Oracle database and other databases. OFA takes advantage of the OS and disk subsystems capabilities to create an easy-to-administer configuration that allows maximum flexibility for growing and high-performance databases. The methods described here are the basics of OFA.

OFA is designed to:
- Organize large amounts of complicated software and data on disk, to avoid device bottlenecks and poor performance
- Facilitate routine administrative tasks such as software and data backup, which are often vulnerable to data corruption
- Facilitate switching between multiple Oracle databases
- Adequately manage and administer database growth
- Help eliminate fragmentation of free space in the data dictionary, isolate other fragmentation, and minimize resource contention


Using Optimal Flexible Architecture

At the core of OFA is a naming scheme, which gives you a standard to apply to your mount points (which are often the physical disks), directories and subdirectories on those mount points, and finally the files themselves.


Mount point syntax:

Name all mount points using the syntax /pm, where p is a string constant and m is a unique fixed-length key (typically a two-digit number) used to distinguish each mount point. Example mount points are /u01, and /u02. Home directories syntax: Name all home directories using the syntax /pm/h/u. Where pm is a mount point name, h is a standard directory name and u is the name of the owner of the directory.

Examples of OFA-compliant home directories are:
/u01/app/oracle
/u01/home/oracle


Software directories syntax:

To help fulfill the OFA feature of simultaneously executing multiple versions of application software, store each version of the Oracle software in a directory matching the pattern /pm/h/u/product/v. Here product is a literal and the variable v is used for the version number.
So an OFA-compliant installation of the Oracle Database 11g version 11.1.0 would look like:
/u01/app/oracle/product/11.1.0


Naming subdirectories syntax:

To facilitate the organization of administrative data, you should store database-specific administration files in subdirectories matching the pattern /h/admin/d/a/, where h is the Oracle software owner’s home directory, admin is a literal, d is the database name, and a is a subdirectory for each of the database administration files.

Following is a list of these administration file subdirectories:
- adhoc: Ad hoc SQL scripts for a particular database
- arch: Archived redo log files
- adump : Audit files (Set the AUDIT_FILE_DEST initialization parameter to the adump directory. Clean out this subdirectory periodically.)
- bdump: Background process trace files
- cdump: Core dump files
- create: Programs used to create the database
- exp: Database export files
- logbook: Files recording the status and history of the database
- pfile: Instance parameter files
- udump: User SQL trace files

Note:
For 11g, bdump and udump no longer exist in $ORACLE_BASE/admin. Their contents have been modified and moved to the DIAGNOSTIC_DEST/diag/db_name/sid/ subdirectories.
The cdump destination has been moved to DIAGNOSTIC_DEST/diag/db_name/sid/cdump.


File-naming syntax:

The following naming convention for database files ensures that they are easily identifiable:
- Control files: /pm/q/d/control.ctl
- Redo log files: /pm/q/d/redon.log
- Data files: /pm/q/d/tn.dbf

The variables used in these file names are:
- pm: A mount point name as described previously
- q: A string distinguishing Oracle data from all other files (commonly named ORACLE or oradata)
- d: The value of the initialization parameter DB_NAME (the database name)
- t: An Oracle tablespace name
- n: A two-digit string

Note: Do not store files other than control files, redo log files, or data files associated with database d in the path /pm/q/d/.