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

 
 Home
 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
 Analysis
 Design
 Implementation
 Oracle Support


 SQL Tuning
 Security

 Oracle UNIX
 Oracle Linux
 Monitoring
 Remote s
upport
 Remote plans
 Remote
services
 Application Server

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

 Remote S
upport  
 Development  

 Implementation


 Consulting Staff
 Consulting Prices
 Help Wanted!

 


 Oracle Posters
 Oracle Books

 Oracle Scripts
 Ion
 Excel-DB  

Don Burleson Blog 


 

 

 


 

 

 

 

 

Oracle Concepts - Optimal Flexible Architecture OFA Standard

Oracle Tips by Burleson Consulting

Optimal Flexible Architecture (OFA)

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

Optimal Flexible Architecture provides a logical physical layout for the database that helps the DBA to manage the system. In addition, a properly configured Oracle instance will minimize contention thus improving performance. Perhaps one of the most overlooked tuning option, configuration, must utilize OFA guidelines to be successful.

In accordance with Cary V. Millsap of the Oracle National Technical Response Team, the OFA process involves following 3 rules:

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

  1. 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.

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

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

  4. Put a file X in the directory /u??/ORACLE/D (or on VMS                 DISK2:[ORACLE.D]) if and only if X is a control file, redo log file, or data file of the Oracle Database whose DB_NAME is D. X is any database file.

Note: 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.

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

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

  3. 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 also spread across controller volume groups. 

  1. Keep at least three active copies of a database control file on at least three                different physical drives. 

  2. Use at least three groups of redo logs in ORACLE7. Isolate them to the greatest extent possible on hardware serving few or no  files that will be active while the RDBMS is in use. Shadow redo logs whenever possible.

  3. 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, either 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 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-data files, a control file, tool-data files, redo logs

* AREA3: Index-data files, a control file, redo logs

* AREA4: Rollback segment-data files

* AREA5: Archive log files

* AREA6: Export Files

* AREA7: Backup Staging

Of course, this is just a start, you mind find it wise to add more areas to further isolate large or active tables into their own areas as well as separating active index areas from each other.  Note that on a modern system this configuration may require 4-2 channel controller cards and 8 physically separable disk arrays.

The structure on UNIX could look like the following:

/oracle0/product/oracle/8.1.3/            Top level $ORACLE_HOME
                                              bin/                  Standard distribution
structure under version
                                              doc/  
                                               rdbms/
                                               ?
/oracle0/data/                      Place instance names under type directories
                     ortest1/
                     ortest2/
/oracle0/control/
                     ortest1/
                     ortest2/
/oracle0/redo/
                     ortest1/
                     ortest1/
/oracle0/admin/
                     ortest1/
                                  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
                     ortest2/
                                ?
/oracle1/data/
            /control/
            /redo/
/oracle2/data/ 
            /control/
            /redo/
?
/oracle7/data/
            /control/
            /redo/
 

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/8.1.3" directory becomes "c:\oracle0\product\oracle\813\".

Oracle Structures and How They Affect Installation

As can be seen from the previous section, an Oracle database is not a simple construct. Much thought must go into file placement, size, number of control files, and numerous other structural issues before installation. It is a testament to the resiliency of the Oracle RDBMS that even if most of the decisions are made incorrectly, the database that results will still function, albeit, inefficiently.

The structures are as follows:

Oracle executables

Data files?data, index, temporary, rollback

Redo logs

Control files

Export files

Archive logs

Placement of any LOB or BFILE storage structures

Let?s examine each of these.

Oracle Executables

The Oracle executables are the heart of the system. Without the executables the system is of course worthless since the data files are only readable by Oracle processes. The Oracle executables should be on a disk reserved for executables and maybe some user files. Disk speed is not a big issue, but availability is of major concern. The executables will require 150 to over 200 megabytes or more of disk space. The installation process will create a directory structure starting at a user-specified root directory. There will usually be a subdirectory for each major product installed.

 


This is an excerpt from the eBook "Oracle DBA made Simple".

For more details on Oracle database administration, see the "Easy Oracle Jumpstart" by Robert Freeman and Steve Karam.  It?s only $19.95 when you buy it directly from the publisher here.

 


 

 
��  
 
 
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 -  2017

All rights reserved by Burleson

Oracle ® is the registered trademark of Oracle Corporation.

Remote Emergency Support provided by Conversational