||Oracle Database Tips by Donald Burleson
Oracle installation is a complex topic. With the new CD-based
installs, many of the platform dependencies dealing with
installation have been reduced, but you as database administrator (DBA)
need to be aware of the differences that apply to your platform.
Usually, these differences will be explained in the release
documents and platform-specific installation and user's guide
provided with your software distribution. However, there are
universal topics that involve structure and layout issues, and the
purpose of this chapter is to present those topics and give you a
general idea of the way to proceed with your installation.
1.1 Things to Consider Before
Oracle Corporation has devised a standard architecture layout that
it suggests should be used when installing Oracle. I have found that
this standard layout, known as the Optimal Flexible Architecture or
OFA for short, to be a logical way of laying out a database. OFA
naming and layout standards should be used even in situations where
the boundaries blur between disks, volumes, groups, and arrays, as
is happening in the arena of RAID (redundant array of independent
disks) technology. OFA should be used even when RAID5 or other RAID
solutions are present because of the fact that it is a logical way
to layout the database.
By using OFA you, and
subsequent DBAs, can easily locate all files associated with the
database. I have seen databases where OFA or an OFA-based
arrangement weren't being used; files were placed anywhere it was
convenient. This chaos method of database file placement led to bad
backups due to missed files, deletion of files that were in use,
and, because no one was tracking where files where placed,
Optimal Flexible Architecture (OFA)
In accordance with Cary V. Millsap of 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
* 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