The Optimal Flexible Architecture is a standard of recommended guidelines  for  installing and configuring databases. This method offers mount point, directory, and file-naming conventions that work with the Oracle Universal Installer.

It allows the database to be installed in a directory structure that allows multiple version of oracle to be installed on the server and also to ensure maximum performance.

Oracle by default installs the software in an OFA-compliant manner if you create your filesystems correctly

Benefits of using the OFA method:

A standardized configuration across all servers

• • Easily manageable installation and maintenance of different Oracle versions.
  • Separation of Oracle software files from database files.
  • Separation of database files to improve manageability and performance.
  • Logical and distinguishable database file names.
  • Separation of files across multiple mount points to reduce I/O contention.As you plan your oracle software and database installation, remember to implement the OFA.  We currently have fileystems, mounted as /u01 through /u08 as shown below:
    Filesystem 1K-blocks Used Available Use% Mounted on
    /dev/mapper/VolGroup00-u01 185650528 61464 176135496 1% /u01
    /dev/mapper/VolGroup00-u02 51474912 53272 48783816 1% /u02
    /dev/mapper/VolGroup00-u06 80503356 53272 76337700 1% /u06
    /dev/mapper/VolGroup00-u04 40185112 49176 38071552 1% /u04
    /dev/mapper/VolGroup00-u05 80503356 53272 76337700 1% /u05
    /dev/mapper/VolGroup00-u03 40185112 49176 38071552 1% /u03
    /dev/mapper/VolGroup00-u07 103080888 61464 97760160 1% /u07
    /dev/mapper/VolGroup00-u08 103080888 61464 97760160 1% /u08

    Your database files will be spread across these filesystems. The mount points /u01 through /u08 have been  created to house the  oracle software, configuration, and database files.

    At a minimum, an OFA compliant database requires four mount points: /u01 for the software and /u02, /u03, and /u04 for database files.Note that a mount point is a Linux term for a filesystem. A filesystem is a directory structure that holds files. It can span multiple disks and can be mounted from a different machine over a network (Network File System, NFS).

    The Sysadmin or storage admin will create and mount these filesystems . Each mount point is typically named with the convention /uN where N is the filesystem number (such as /u01).

    OFA Structure

    Files on /u01
    
    You will create the app/oracle sub-directory under /u01 mount point. This will look something like this.

    /u01/app/oracle

    app – is short for application and this where you will install your oracle files (usually called oracle binaries)

    The path /u01/app/oracle directory is usually referred to as the ORACLE_BASE and this is the root directory for the oracle database.

    underneath this directory, you will create the product folder and the path will look like so – /u01/app/oracle/product.

    The table below shows the default directory paths for the ORACLE_BASE and ORACLE_HOME recommended by oracle.
    under the  /u01/app/oracle directory, an important split takes pace,  the subdirectories /product and /admin are created, as shown:

    /u01/app/oracle/admin

    Under /u01/app/oracle/product, each version of the Oracle database is installed.You would be running multiple versions of oracle from the server.  For example, you will be running  Oracle 11.2.04 and Oracle 12.2.0.1 on the same machine, you would have the following directories:

    /u01/app/oracle/product/11.2.0.4
    /u01/app/oracle/product/12.2.0.1

    Oracle knows which version you want to run by setting your linux environment variable $ORACLE_HOME. This variable defines which Oracle software executables are used.

    For example:

    echo $ORACLE_HOME
    /u01/app/oracle/product/11.2.0.4

    This shows that your database environment is set to run Oracle 11.2.0.4. All the Oracle software
    installation files for 11.2.0.4 are stored in this directory.

    Under the /u01/app/oracle/admin directory are all the startup, configuration, and log files for each database
    instance, regardless of version are stored here.

    For example:

    /u01/app/oracle/admin/kuddev
    /u01/app/oracle/admin/kudtst

    This indicates there are two databases on this machine (kuddev and kudtst). A list of the contents under the /
    /u01/app/oracle/admin/kuddev/ will display the following directory/files.

    [69-64-90-149:oracle]$cd kuddev/
    [69-64-90-149:oracle]$ls
    adump dpdump pfile scripts xdb_wallet
    

    Each of these subdirectories hold files specific to the database instance kuddev. The directory structure and most of the files are created during database installation.

    Let’s review the contents of each of these sub directories.

  •  The adump –  directory contains trace files created by the database for auditing purposes. Every time a user connects internal to the database, this event is logged and a small, unique trace file is created.
  • The dpdump – Because Data Pump is server-based rather than client-based, dump files, log files, and SQL files are accessed relative to server-based directory paths. Data Pump requires that directory paths be specified as directory objects.
  • Scripts  – The Scripts directory contains the database creation scripts generate using DBCA.

• pfile – The pfile directory contains the init.ora file for the database. This is the configurable startup file that contains database parameters.Another very important subdirectory is the trace directory located under /u01 /app/oracle/diag/rdbms/kuddev/kuddev. As you can, this directories are specific to each database on the server.
  [69-64-90-149:oracle]$pwd
  /u01/app/oracle/diag/rdbms/kuddev/kuddev[69-64-90-149:oracle]$ls
  alert hm incpkg lck metadata metadata_pv sweep
  cdump incident ir log metadata_dgif stage trace
• cdump – Core dump files are sometimes generated when an Oracle process has really big problems.
  These files are very large, sometimes filling up an entire filesystem. They are not much use to the DBA, but if needed, Oracle Support can analyze them. Unless there is a real need to keep and compress a core dump, it is usually best to delete the file.
• trace – Trace files can be intentionally generated by you. These files contain a wealth of diagnostic information, including the SQL being executed inside the database. You can turn on tracing to generate these files. The files are then analyzed to identify problems or tune SQL.You will use these files to diagnose database issues and sometimes provide them to oracle support so that they can review and diagnose/solve database performance issues.From an administration standpoint, it is easier to maintain the separation between actual data files and the Oracle installation/configuration files. This simplifies monitoring space usage, backups, and performing recoveries.Data Files and Other OFA ConventionsYou will dedicate  three mount points for the data files. For example
  /u02/oradata/ORACLE_SID/system01.dbf
  /u03/oradata/ORACLE_SID/employees01.dbfPhysical database files are stored under the ../oradata directory. Notice the subdirectory identifying the database each file belongs to.In this case, there are no other files on /u02.Be sure not to place  non-Oracle files or Oracle configuration/installation files in the same directories as the data files.File names can be in any form; Oracle doesn’t care. However, it is a good idea to make them descriptive.Oracle recommended structure for directories in  Optimal Flexible Architecture Installation

  Directory	Description
  /	Root directory
  /u01/	User data mount point 1
  /u01/app/	Subdirectory for application software
  /u01/app/oracle/	Oracle Base directory
  /u01/app/oracle/admin/	Sub-directory for database administration files
  /u01/app/oracle/admin/TAR	Sub-directory for support log files
  /u01/app/oracle/admin/db_name1/	admin Sub-directory for db_name1 database
  /u01/app/oracle/admin/db_name2/	admin Sub-directory for db_name2 database
  /u01/app/oracle/fast_recovery_area/	Sub-directory for recovery files
  /u01/app/oracle/fast_recovery_area/db_name1	Recovery files for db_name1 database
  /u01/app/oracle/fast_recovery_area/db_name2	Recovery files for db_name2 database
  /u02/app/oracle/oradata/u03/app/oracle/oradata /u04/app/oracle/oradata	Oracle data directory
  /u01/app/oracle/product/	Distribution files
  /u01/app/oracle/product/12.1.0/dbhome_1	Oracle home directory for Oracle Database, for user oracle

  Oracle recommended directory structure for log Files in an Optimal Flexible Architecture Installation

  Directory	Description
  /u01/app/oracle/admin/TAR	Sub-directory for support log files
  /u01/app/oracle/admin/orcl/arch/*	Archived log files
  /u01/app/oracle/admin/orcl/create/	Contains the database creation log files
  /u01/app/oracle/oradata/orcl/*.log	Redo log files
  /u01/app/oracle/admin/orcl/dpdump/	Contains the data pump file dp.log
  /u01/app/oracle/diag	Contains all database, listener, sqlnet and other diagnostic logs
  /u01/app/oracle/audit	Contains all audit logs
  /u01/app/oracle/cfgtoollogs	Contains logs for configuration assistants such as Oracle Database Configuration Assistant, Database Upgrade Assistant, and Oracle Net Configuration Assistant

Follow the link below to read more about the OFA

Optimal Flexible Architecture

Physical Database Layout

Create database objects

Possible disk solutions

Impact on SQL Data Definition Language