Call now: 252-767-6166  
Oracle Training Oracle Support Development Oracle Apps

 E-mail Us
 Oracle Articles
New Oracle Articles

 Oracle Training
 Oracle Tips

 Oracle Forum
 Class Catalog

 Remote DBA
 Oracle Tuning
 Emergency 911
 RAC Support
 Apps Support
 Oracle Support

 SQL Tuning

 Oracle UNIX
 Oracle Linux
 Remote s
 Remote plans
 Application Server

 Oracle Forms
 Oracle Portal
 App Upgrades
 SQL Server
 Oracle Concepts
 Software Support

 Remote S


 Consulting Staff
 Consulting Prices
 Help Wanted!


 Oracle Posters
 Oracle Books

 Oracle Scripts

Don Burleson Blog 








Oracle Optimal Flexible Architecture (OFA)

Oracle Database Tips by Donald Burleson


See this link for a full copy of Oracle's Optimal Flexible Architecture (OFA) standard.

In accordance with the Oracle National Technical Response Team, the OFA process involves the following three rules:

1.      Establish an orderly operating system directory structure in which any database file can be stored on any disk resource.

?        Name all devices that might contain Oracle data in such a manner that a wild card or similar mechanism can be used to refer to the collection of devices as a unit.

?        Make a directory explicitly for storage of Oracle data at the same level on each of these devices.

?        Beneath the Oracle data directory on each device, make a directory for each different Oracle database on the system.

?        Put a file X (X is any database file) in the directory /u??/ORACLE/sid/type_desig (or on W2K or NT: C:\oracle\sid\type_desig) if and only if X is a control file, redo log file, or datafile of the Oracle database whose DB_NAME is sid. The type_desig specifies the type of file to be placed in the directory at that location and is usually data, index, control or redo.


You may wish to add an additional directory layer if you will have multiple Oracle versions running at the same time. This additional layer includes the version level.

2.      Separate groups of segments (data objects) with different behavior into different tablespaces.

?        Separate groups of objects with different fragmentation characteristics in different tablespaces (e.g., don't put data and rollback segments together).

?        Separate groups of segments that will contend for disk resources in different tablespaces (e.g., don't put data and indexes together).

?        Separate groups of segments representing objects with differing behavioral characteristics in different tablespaces (e.g., don't put tables that require daily backup in the same tablespace with ones that require yearly backup).

3.      Maximize database reliability and performance by separating database components across different disk resources. A caveat for RAID environments: Consider spreading datafiles across multiple controller volume groups.

?        Keep at least three active copies of a database control file on at least three different physical arrays.

?        Use at least three groups of redo logs in Oracle9i. Isolate them to the greatest extent possible on hardware serving few or no files that will be active while the RDBMS (relational database management system) is in use. Shadow redo logs whenever possible.

?        Separate tablespaces whose data will participate in disk resource contention across different physical disk resources. (You should also consider disk controller usage.)

Minimum OFA Configuration

The minimum suggested configuration would consist of seven data areas: disks, striped sets, RAID sets, or whatever else comes down the pike in the next few years. These areas should be as separate as possible, ideally operating off of different device controllers or channels to maximize throughput. The more disk heads you have moving at one time, the faster your database will be. The disk layout should minimize disk contention. For example:

AREA1. Oracle executables and user areas, a control file, the SYSTEM tablespace, redo logs

AREA2. Data-datafiles, a control file, tool-datafiles, redo logs

AREA3. Index-datafiles, a control file, redo logs

AREA4. Rollback segment-datafiles

AREA5. Archive log files

AREA6. Export files

AREA7. Backup staging

Of course, this is just a start; you might find it wise to add more areas to further isolate large or active tables into their own areas as well as to separate active index areas from each other.

The structure on UNIX could look like the following:

/oracle0/product/oracle/9.0.1/          Top level $ORACLE_HOME
                                              bin/                  Standard distribution structure under version
/oracle0/data/                    Place instance names under type directories
                                  bdump/          backup_dump_dest
                                  udump/                         user_dump_dest
                                  cdump/                         core_dump_dest
                                  pfile/               initialization file location (linked back to dbs directory)
                                  create/               Database creation script storage area

Using this type of structure even on a RAID5 volume allows for a logical separation of files for ease in locating and controlling database files. For other platforms just alter the directory syntax; for example, on NT the /oracle0/product/oracle/9.0.1 directory becomes c:\oracle0\product\oracle\9.0.1\.

I have seen several questions posted as to why the standard says to use u01, u02, and so on for mount points. This based in old UNIX naming conventions and has little actual usefulness in modern structures. Call the mount points whatever you wish as long as it meets your requirements. I suggest using the application name, for example.


If you like Oracle tuning, you may enjoy the new book "Oracle Tuning: The Definitive Reference", over 900 pages of BC's favorite tuning tips & scripts. 

You can buy it direct from the publisher for 30%-off and get instant access to the code depot of Oracle tuning scripts.



Oracle Training at Sea
oracle dba poster

Follow us on Twitter 
Oracle performance tuning software 
Oracle Linux poster


Burleson is the American Team

Note: This Oracle documentation was created as a support and Oracle training reference for use by our DBA performance tuning consulting professionals.  Feel free to ask questions on our Oracle forum.

Verify experience! Anyone considering using the services of an Oracle support expert should independently investigate their credentials and experience, and not rely on advertisements and self-proclaimed expertise. All legitimate Oracle experts publish their Oracle qualifications.

Errata?  Oracle technology is changing and we strive to update our BC Oracle support information.  If you find an error or have a suggestion for improving our content, we would appreciate your feedback.  Just  e-mail:  

and include the URL for the page.


Burleson Consulting

The Oracle of Database Support

Oracle Performance Tuning

Remote DBA Services


Copyright © 1996 -  2020

All rights reserved by Burleson

Oracle ® is the registered trademark of Oracle Corporation.