Upload
sridhard1977
View
229
Download
0
Embed Size (px)
Citation preview
8/7/2019 Oracle Ofa Whitepapaer
1/23
Oracle System Perform ance Group Technical Paper, Septem ber 24, 1995
The OFA StandardOracle for Open Systems
Cary V. Millsap
Oracle Corporation
Septem ber 24, 1995
The OFA Stand ard is a set of configuration gu idelines that w ill give you faster, mor e reliable Ora-
cle databa ses that require less work to maintain. The OFA Stand ard is written by the found er of
the Oracle team r esponsible for installing, tuning, and u pgra ding several hun dred s of sites
world wid e since 1990this pap er is based on th e best practices of those hund reds of sites. Today
the Op timal Flexible Architecture described in the OFA Stand ard is built into the O racle con-
figuration tools and documentation on all open systems ports.
This paper form ally defines the OFA Stand ard for configuring com plex Oracle systems at sites
demand ing high p erformance w ith low m aintenance und er continually evolving requirements. It
also details how th e OFA is derived from requirem ents essential to successful imp lementation of
complicated software on any system . Along with the d efinition of the OFA, this pap er will also
reveal the strategy and analysis that motivate the ind ividual recomm enda tions of Oracle Services
Optim al Flexible Architecture. By read ing this pap er, you w ill mor e fully und erstand the chal-
lenges that confront the Or acle Server configuration p lanner.
Perm ission to copy withou t fee all or part of this mater ial is granted p rovided that the copies are not mad e or
distributed for direct comm ercial adv antage, the Oracle Corporation copyright notice and the title of the
pu blication and its data app ear, and n otice is given that copying is by perm ission of Oracle Corpor ation. To copy
otherwise, or to republish, requires a fee and/ or specific permission.
1993, 1996 Oracle Corporation. Oracle part number A19308-1
8/7/2019 Oracle Ofa Whitepapaer
2/23
8/7/2019 Oracle Ofa Whitepapaer
3/23
8/7/2019 Oracle Ofa Whitepapaer
4/23
4 Cary V . Millsap
Oracle System Perform ance Grou p Technical Paper , Septem ber 24, 1995
If files from two or m ore ap plications will live
together in a m ount p oint subtree, it is impor-
tant that the mount p oint name not denote the
presence of one app lication to the exclusion of
anoth er. For examp le, consider a situation in
wh ich you w ould like to balance I/ O load by
storing both a n Oracle database file and an on-line backup of some other data w ithin a single
disk slice. You shouldnt call that disk slices
mount p oint/oracle because that would p ut a
misleading name in the path of the non-Oracle
files stored there. And you sh ould nt call the
mount p oint/backup because you wou ldnt
wa nt to keep Ora cle da tabase files in a directory
that looks like it has been m ad e exclusively for
storage of backed up files.
Mount points that contain files from multiple
app lications are given nam es only to distingu ish
one mou nt p oint from a nother, like/u01 an d
/u02, or even/ulna/disk01 an d /ulna/disk02.
Using zeros to pad distinguishing keys to a
fixed length m akes sorted lists of mou nt point
nam es come ou t right, like
/u1/u08 /u10
/u09 instead of /u11/u10 /u2
Unfortunately, storing files from two or more
databases on the sam e drive contradicts re-quirem ent 4. The only w ay to satisfy
requirements 2 and 4 simu ltaneously is to buy
more disk drives than your initial sizing esti-
mates probably showed. Adm inistrators with
tight hardw are bud get constraints normally
sacrifice maximal fault resilience (req. 4), be-
cause per forman ce (req. 2) is almost always
more important. So, the degree to which you
are willing to solve this conflict with ha rd ware
quantity determines the strategy you should
take for nam ing your m ount p oints. An alterna-
tive strategy for the sm all percentage of Oracle
sites that can pursue fault resilience without
sacrificing p erforman ce is given in section 6 in
this paper.
Resist the temp tation to encode controller or
disk identification characters into a mount point
name. Putting specific hardware configuration
deta il into directory nam es causes exactly the
types of problems that m ount p oint names were
designed to avoid. Mount point nam es allow u s
to abstract away the d etails of hardw are im-
plementation that are irrelevant to the
challenges that a systems users face.
Adm inistrators can be tempted to m atch mount
point nam es with d evice nam es because, to bal-
ance I/ O load, they have to make decisions
about d irectory contents based on I/ O statistics
printed for devices. How ever, denoting hard -
ware information within a mount p oint name
causes trouble if you ever up grade your disk
hard ware. New hard ware that uses different
device names than you had before (consider the
case of exchan ging a SCSI drive for an IPI d rive)
will require you to invest time into chan ging
path names in you r ap plications if you intend to
follow your own hard ware-bound nam ing tra-
dition. Your best mount point naming decision
is to use names unrelated to your hard ware de-
vice names an d to exam ine system files (or
write a pr ogram to d o it for you) on the rare
occasion when you need to balance your sys-
tems I/ O load.1
1.2 Login Home Directories
On very old UNIX systems, home directories
were p laced in /usr. That w orked w ell enough
for single-user systems, but having home direc-
tories in/usr did cause unnecessary challenges.
For example, having d irectories in/usr in-
creases risk of accidenta l file loss at up grad e
time when the entire/usr subtree is replaced;
also, if the/usr file system fills, UNIX will crash.
UNIX books today usua lly recommend that
login home d irectories be placed in a directory
called /u or /home. Using/u or /home works
fine for sites w ith average data volume. How -
ever, a challenge a rises if the set of files to be
contained w ithin a single hom e directory is too
large to fit on an y single disk slice. For examp le,
Oracle Financials and Manufacturing software
consum es almost a gigabyte, all of which is
supp osed to reside in some d irectory calledapplmgr, but no single d isk slice on your sys-
1 The requirem ent imp licit here is very similar to
requ irement 6 (to which you will be introdu ced
shortly): It must be possible to exchange hard war e
components without having to revise programs that
refer to them .
8/7/2019 Oracle Ofa Whitepapaer
5/23
OFA Standard 5
Oracle System Perform ance Group Technical Paper, Septem ber 24, 1995
tem is big enough to hold all of it. Hence, the
following requirement:
Requirement 5. It must be p ossible to dis-
tribute across two or m ore disk drives
both (a) the collection of hom e d irecto-
ries and (b) the contents of an
individual home directory.
The following ru le offers an elegant solution to
requirement 5:
OFA 2 Name home directories matching t he pattern
/pm/h/u, wherepm is a mount point n ame,h is se-
lected from a small set of standard directory names,
andu is the name of the owner of the directory.
Placing all hom e directories at the same level in
the UNIX file system means that w e can pu t
home directories on different mount points, yetstill be able to refer to the collection of login
homes w ith a single pattern. We meet require-
ment 5.a without violating requirement 1 by
placing two large home subtrees at the same
level on separate mount points. For example,
the Oracle Server software own er hom e direc-
tory might be/u01/app/oracle, and th e Oracle
Applications software owner home directory
might be/u02/app/applmgr. Even though tw o
enormous subtrees are on different disk slices,
we can still use a single pattern in this exam-
ple,/*/app/*to refer to all app lications owner
login home directories on the system.
To illustrate requ iremen t 5.b, consider th e Ora-
cle Finan cial and Manu facturing App lications
software owner, typically named applmgr,
which can own m ore than a gigabyte of UNIX
files on a system wh ose largest disk slice is
600 megabytes. A simp le solution is to use sym -
bolic links to make d irectories app ear in a single
subtree, even thou gh they ph ysically reside on
different moun t points. Figure 3 shows the
symbolic link required to enable the Oracle
General Ledger software to live on a separate
moun t p oint from the other a pplications soft-
ware, yet appear to live in/u02/app/applmgr.All applmgr files are still identifiable as resi-
dents of subtrees whose names match the
pattern /*/app/applmgr.
Different va lues ofh in ru le OFA 2 enable sys-
tem adm inistrators to simp lify their backup
procedures by using d ifferent hom e directory
roots for different types of users. For examp le,
Oracle Server software files might be own ed by
a UN IX login called oracle, jus t like th e file r-
sum.tex might be ow ned by a login called
cmillsap. However, the ad ministrator of the
UNIX system h ousing both users may w ish to
back up the tw o types of files represented here
on d ifferent tapes or d ifferent sched ules. To
par tition a systems users into the tw o classes
(1) app lications ow ners and (2) interactive log-
ins, the adm inistrator could choose home
directory su btree names with, for example,
h chosen from th e list {app , home}. For exam-
ple, you might use the following UN IX
comm and to back up your ap plications soft-
ware directories:
find /*/app/* -print | \
bar cvf /dev/rst0
And this UNIX command to back up your
login user home directories:
find /*/home/* -print | \bar cvf /dev/rst0
$ ln -s /u03/app/applmgr/gl /u02/app/applmgr/gl$ ls -l /u02/app/applmgr-rw-r--r-- 1 applmgr 1119 Jul 5 01:16 AOL.envdrwxrwxr-x 2 applmgr 2048 Jul 5 01:16 alrdrwxrwxr-x 2 applmgr 2048 Jul 5 01:16 fndlrwxrwxrwx 1 applmgr 5 Jul 5 01:16 gl -> /u03/app/applmgr/gl...$ ls -l /u03/app/applmgr
drwxrwxr-x 1 applmgr 2048 Jul 5 01:16 gl
Figure 3. In this figure, we use a symbolic link to distribute the applmgr logins files across disks. The gl
directory in /u02/app/applmgris actually a nam ed (symbolic) link referring to a directory subtree th at is
ph ysically located on the/u03 moun t point. Thus w e can treat the gl directory as if it were a p art of/u02 in
our adm inistrative programm ing.
8/7/2019 Oracle Ofa Whitepapaer
6/23
6 Cary V. Millsap
Oracle System Perform ance Grou p Technical Paper , Septem ber 24, 1995
1.3 User Profi les
Oracle Server is designed well to enable user s to
choose which of several simultaneou sly active
versions of server software to run against any of
several databases, without sophisticated pro-
gramm ing and without complicated user
profiles. An Oracle database user s profile
shou ld (1) assign a UN IX path value so that th e
users shell can execute Oracles program s for
setting up the environm ent; (2) define an in-
stance nam e (SID) for planned da tabase
connections; and (3) execute the program that
sets the UNIX path for running Oracle software.
Insert the following lines into your users
.profile to accomplish these tasks:2
# set UNIX pathPATH=/bin:/usr/bin:/var/opt/bin
# set default instance
ORACLE_SID=sab
# set ORACLE_SID, ORACLE_HOME,# and PATH without askingORAENV_ASK=NO. oraenvORAENV_ASK=
By ensuring th at oraenv, coraenv, and dbhome
reside in/var/opt/bin,3 independ ent of any Ora-
cle software home directory, you remove all
dependence on Oracle versions from your login
profiles.
The steps shown here should be executed for
each user conn ecting to an Oracle Server in-stance. A user may w ant to perform add itional
setup steps in the profile, such as assigning
terminal settings, inserting additional software
directories in the UNIX path , assigning ORA-
CLE_PATH and ad ditional environment
variables, or selecting among v arious instan ces
for connection.
1.4 Zero Maintenance Administration
Oracle Services still occasionally visits an un for-
tunate client wh ose backup programs d idnt
keep pace w ith the file system changes m ade
2 The examp le shown here is what you will need for
Bourn e shell or KornShell users. For C Shell users,
you w ill need to m ake functionally equivalent entries
into the .cshrc file for each u ser.3 The standar d d irectory for site local prog ram s is
called /usr/local/bin or /usr/lbin on most systems
before UN IX System V Release 4.
wh en someone cured an I/ O bottleneck or fer-
reted out free space to feed a grow ing
app lication. We have been asked to visit several
sites at w hich a routine I/ O balancing exercise
that should have consumed ten m inutes actu-
ally consumed hou rs of database dow ntime
because ad ministrative p rograms containedhard -coded r eferences to path nam es that were
no longer valid after the su rgery. These kind s of
problems m otivate the following r equirement.
Requirement 6. It must be p ossible to
add or move login hom e directories
without having to revise programs that
refer to them.
Conforming to the following ru le satisfies re-
quirement 6.
OFA 3 Refer to explicit path names only in files
designed specifically to store them, such as the
UNIX/etc/passwdfile and the Oracle oratab file;
refer to group memberships only in/etc/group.
Hard -coded references to a files path nam e
must be systematically identified and modified
if it ever becomes necessary to relocate that file
to a new directory. Fortunately, it is comp letely
unn ecessary to record a path n ame in an y file
other th an a central reference file, because a
users home directory nam e can be derived.
C Shell and KornShell users can u se ~login to
refer to the hom e directory for login; and al-
thou gh th e Bourn e shell has no bu ilt-in ability to
calculate hom e directory names, it is easy to
construct a program to d o it. Such a p rogram is
given later in this d ocum ent (lhd, section 9).
Similarly, group memberships shou ld never be
recorded in an ad ministrative program , because
group m ember names can be compu ted from
/etc/group, as is also shown later (grpx, sec-
tion 9). By always using p rogram s like lhd
(or ~) and grpx instead of explicit references,
your ad ministrative tools will not require m odi-
fication w hen you move u ser home directoriesor change group mem berships.
8/7/2019 Oracle Ofa Whitepapaer
7/23
OFA Standard 7
Oracle System Perform ance Group Technical Paper, Septem ber 24, 1995
Figure 4 illustra tes programm ing that exploits
the ability to r efer to classes of objects with
simple patterns that remain constant when you
add data, users, databases, or disks; even wh enyou m ove files around you r system. Consider
the change you would have to make to the one-
line backup program shown h ere if you were to
change th e ph ysical location of the applmgr
users login home d irectory. How w ould ad d-
ing a new user to the dba or clerk grou p affect
the behavior of the second or third example?
The OFA Standa rd ensu res that no m aintenance
on these programs wou ld be required to ac-
commodate these changes. You w ill see later
(Figure 7) that u sing the OFA also gives a zero
maintenance wa y to manip ulate all the files as-sociated with a given Oracle database as a u nit,
even though the files might be distributed u ni-
formly across m any d isks.
2. Oracle Files
Before the original OFA recommen dat ions were
published, many people placed database files in
$ORACLE_HOME/dbs [Millsap 1993]. How -
ever, pu tting control files, red o log files, or da ta
files in a subtree of the d irectory holding Ora cle
software caused p roblems: having all database
files on a single d isk bottlenecked the server ;
and having long-term d atabase data in the Ora-
cle software subtree mad e upgrad es
unnecessarily difficult because administrators
had to spend time and m oney to carefully pre-
serve and move the d ata. A goal of the original
OFA was to solve these difficult problems w ith
a flexible set of recomm end ations that a llowed
files to be distributed across multiple disk
drives w ithout d isorganization, yet pr evented
software an d d ata from interfering with each
other du ring software u pgrad es. The separationof data from software is just one sp ecific case of
a broader requirement:
Requirement 7. Categories of files must
be separated into independ ent directory
subtr ees so that files in one category are
minimally affected by operations upon
files in the other categories.
The following classification of Oracle files en-
ables us to build a stand ard th at meets this
requirement:
Product files consist of Oracle Server soft-
ware and tools that are supplied on the
Oracle Corporation d istribution med ia.
Administrative files are files containing d ata
about the database or instance, including
archived r edo log files, server p rocess diag-
nostic output, d atabase creation scripts,
online exports, instance pa ram eter files, etc.
Local software is software u sed w ith Oracle
that is written on site or purchased sepa-
rately from the Oracle distribution
software.
Database files consist of control files, redo
log files, and da ta files.
This classification partitions Oracle files along
the bou nd aries of different lifespans, mainte-
nan ce sched ules, and secur ity privileges. The
following sections d escribe a mod el that fu lfills
requ irement 7 by placing each of these four
# Back up all files in login home subtrees of the applmgr userfind /*/app/applmgr -print | tar cvf /dev/rst0
# Propagate a centrally administered .profile to clerk usersfor user in `grpx clerk` ; do
f=`lhd $user`/.profileln -s `lhd applmgr`/.profile.clerk $fchown applmgr $f ; chgrp oaa $f ; chmod 644 $f
done
Figure 4. This figure shows an example of zero maintenance programming. Regardless of the
phy sical location of the applmgr subtrees on th e system, the first find comm and will find them
because of the w ildcard in the m ount p oint directory nam e component of the p ath. The second
UNIX comm and will create a prop erly protected file into each mem ber of the clerk group. Nei-
ther of these programs require modification if login home directories are added, moved, or
deleted. (Sour ce code for th e grpx an d lhd program s used h ere is supplied later in this paper.)
8/7/2019 Oracle Ofa Whitepapaer
8/23
8 Cary V. Millsap
Oracle System Perform ance Grou p Technical Paper , Septem ber 24, 1995
types of files in subtr ees indep end ent of the
other types.
2.1 Oracle Software and Administrative Data
Figure 5 is a grap hical representation of the
OFA Standards that will be detailed below for
storing Oracle p rodu ct, administrative, and lo-
cal software files. All Oracle software an d
adm inistrative data reside in su btrees of the
Oracle Server ow ners login hom e directory.
The name of this directory is the value to wh ich
Oracle advises that you set the environment
variable ORACLE_BASE.
Product Files Mature p rodu ction sites require
means to test a new version of Oracle software
without impacting daily operations. Staging
up grad es has been a d ifficult challenge for
many Oracle sites because the focus of a default
installation is that there is exactly one central
repository of Oracle software. An inexperienced
technician try ing to complete an Oracle installa-
tion will rarely consider th e requirem ents of an
upgrade that isnt even planned yet. Building a
structure to make up grades easy is simple
work, but it requires foresight and a complete
understanding of the Oracle version switching
mechan ism d iscussed briefly in section 1.3.
Requirement 8. It must be p ossible toexecute m ultiple versions of applica-
tions software simultaneously. Cutover
after up grade m ust be as simple for the
adm inistrator and as transp arent for the
user comm unity as possible.
Conforming to the following rule yields a struc-
ture that helps fulfill requirem ent 8:
OFA 4 Store each version of Oracle Server distribu-
tion software in a directory matching the pattern
h/product/v, whereh is the login home directory of
the Oracle software owner, andv represents the ver-
sion of the software.
Most OFA for UNIX imp lementa tions use val-
ues ofv like 7.0.16. Oracle Server p atches
involving changes only to version numbers
right of the th ird d ecimal point (e.g., from
6.0.36.3 to 6.0.36.5) usu ally take p lace withou t
elaborate staging, and thu s most sites do n ot
use values ofv significant beyond th e third
decimal point.
An Oracle upgrad e at an OFA compliant site
then u nd ertakes the following steps: (1) a new
version directory is created in product; (2) thenew Oracle Server ver sion is installed in th at
directory; (3) a test dat abase is created for con-
firmation of the n ew softw are; (4) after
confirmation, the home directory column of
oratab is upd ated for the row associated w ith
the pr odu ction instan ce; and (5) to cut over to
the new version, all users exit and r e-enter
UNIX. Executing a fresh login (norm ally ac-
complished by leaving work one afternoon to
return th e next morning) causes the oraenv call
in a u sers .profile4 to set the UN IX environ-
ment p roperly for operation with the newly
validated software.
After an upgrade is judged successful, the next
step becomes removal of the old version sub-
tree, so that the space it consum es can be
reclaimed. The safety with which the old ver-
sion directory can be removed varies inversely
4 Or a coraenv call in a C shell users .cshrc.
/u01/app/oracle
product admin local
7.0.16 TAR sab sabt6.0.37 aps6intl aps7
Figure 5. This is a grap hical representation of the Oracle softwar e owner 's home d irectory structure. In this
example, ORACLE_BASE would be set to the value /u01/app/oracle, and ORACLE_HOME would be set
to either/u01/app/oracle/product/6.0.37 or /u01/app/oracle/product/7.0.16.
8/7/2019 Oracle Ofa Whitepapaer
9/23
OFA Standard 9
Oracle System Perform ance Group Technical Paper, Septem ber 24, 1995
with the am ount of custom ma terial stored
there. The Oracle adm inistrator should ensure
that the only files permitted to reside within the
product subtree either are either copied or me-
chanically derived from the Oracle distribution
med ia (such as executables created by linking
distributed object files). Following this policygreatly simp lifies up grade cutover and cleanup
by eliminating th e need for intricate file-copy
surg ery to preserve original work. The lifespan
of the product/v subtree matches the lifespan of
a ver sion of Oracle. Dont p ut files there if they
will outlive version v of the software.
Administrative Files A key Oracle adm inistra-
tor skill is the ability to manage large am oun ts
of data aboutan Oracle system. In the normal
course of opera tion, for example, installers store
programs that create databases; Oracle Server
itself produces trace files; and administrators
save structural records, instance param eters,
per forman ce statistics, backup s, archives, and
general logbook entries on each d atabase. The
volume of data to be ad ministered increases as
the num ber of databases on the system in-
creases. These facts motivat e the following
requirement:
Requirement 9. Adm inistrative informa-
tion about one database must be
separated from that of others; there
mu st be a reasonable structure for or-ganization and storage of
adm inistrative data.
In exclusive mode environments,5 conforming
to the following ru le fulfills requ irement 9.
OFA 5 For each database withdb_name=d, store
database administration files in the following subdi-
rectories ofh/admin/d:
adhocad hoc SQL scripts for a given database
adumpaudit trail trace files
archarchived redo log files
bdumpbackground process trace files
cdumpcore dump files
createprograms used to create the database
expdatabase export files
5 For sites using Oracle Parallel Server, see section 5.
logbookfiles recording the status and history
of the database
pfileinstance parameter files
udumpuser SQL trace files
whereh is the Oracle software owners login home
directory.
Figure 5 shows theh/admin/ddirectories for
three databases in a sample system; because
space is limited, the picture d oes not show the
adhoc, adump, etc. directories that r eside be-
neath each named database directory.6 The
simp le classification nam ed her e gives the ad-
ministrator su fficiently m any file folders to
store the necessary data abou t a given database.
By keeping all original work per tinent to a spe-
cific database in the administrative subtree
instead of in the p rodu ct subtree, as so man y
peop le have implicitly done in the past by stor-
ing files in th e dbs or rdbms/admin subtrees of
$ORACLE_HOME, the ad ministrator accom-
plishes the goal of keeping the product subtree
free from files that mu st be carefully preserved
at Oracle up grade time.
Some administrative directories, such as arch
an d exp , are typically too large to store on the
disk slice housing th e Oracle owners login
hom e directory. These directories can be con-
nected easily into the administrative subtree
with sym bolic links similar to the one show nearlier in Figure 3. Using symlinks gives a sim -
ple mechan ism for storing a file anyw here you
need w ithout sacrificing the organ ization of
your file system to ph ysical size constraints.
Local Software UNIX is an esp ecially open en-
vironment d esigned to enable addition of new
capabilities into the operating system . General
pu rpose ad ministrative u tilities like those listed
in section 9 are typ ically executed from a d irec-
tory created exclusively for site-specific utilities,
such as/var/opt/bin. The OFA Stand ard simi-
larly enables the Or acle ad ministrator to addsite-specific Oracle cap abilities into the system
in the local subtr ee of the Oracle own ers login
6 The TAR directory show n in Figure 5 is created at
some sites to enable site staff to record information
about technical assistance requ ests (TARs) logged
with Oracle Worldwide Supp ort. The upp er-case
name distinguishes this directory from that of a da-
tabase nam ed tar, if one were to exist.
8/7/2019 Oracle Ofa Whitepapaer
10/23
10 Cary V. Millsap
Oracle System Perform ance Grou p Technical Paper , Septem ber 24, 1995
hom e directory. During Core Technologies on-
site engagements, for example, an Oracle con-
sultant will populate this subtree with
administrative utilities.
2.2 Oracle Database Files
Intuition tells most installers that Oracle data-
base files should be sep arated from other files
on a system . There are concrete reason s for do-
ing so, amon g w hich: database files lifespan s
differ from all other files on your system; and
da tabase files will require a d ifferent backup
strategy th an the oth er files on your system. A
thoughtful naming strategy for database files
eliminates a wh ole class of ad ministrative
problems. Experience yields the following re-
quirement:
Requirement 10. Database files shou ld be
nam ed so tha t (a) da tabase files are eas-
ily distinguishable from other files;
(b) files of one d atabase a re easily d is-
tinguishable from files of another ;
(c) control files, red o log files, and da ta
files are easily distinguishable from one
another; and (d) the association of data
file to tablespace is easily identifiable.
The following ru le meets requirem ent 10:
OFA 6Name Oracle database files using the fol-
lowing patterns:
/pm/q/d/control.ctlcontrol files
/pm/q/d/redon.logredo log files
/pm/q/d/tn.dbfdata files
wherepm is a mount point name, q is a string de-
noting the separation of Oracle data from all other
files,dis thedb_name of the database,n is a distin-
guishing key that is fixed-length for a given file type,
andt is an Oracle tablespace name. Never store any
file other than a control, redo log, or data file associ-
ated with databasedin/pm/q/d.
In section 1.1 we d iscussed selection of mou ntpoint nam es, to wh ich w e refer here as/pm . The
two d irectory layers beneath the m ount p oint
level are valuable agen ts of organization. The
q layer fulfills requ irement 10.a. It is hom olo-
gous to the home layer d iscussed in section 1.2,
as it serves the same pu rpose of enabling an
adm inistrator to refer to a collection of I/ O bal-
anced files as a unit, in a zero mainten ance way.
Many p eople will choose q=ORACLE, as in the
original OFA p aper [Millsap 1993], or oth er ob-
vious valu es like q=oradata. Thedlayer satisfies
requ irement 10.b. It elimina tes confusion about
the d atabase association of a given file, because
the nam e of the database will always be a com-
pon ent of the fully qualified p ath nam e of thefile. For example, it is easy to see to which da ta-
base/u03/oradata/sab/system01.dbfbelongs.
Figure 6 is a graphical representa tion of a sam-
ple OFA compliant directory structure for
storing I/ O balanced d atabase files that are in-
depen dent of the Oracle software and
ad ministrative files. In this example, q=oradata
on a system w ith three databases. The figure
shows only the specific mount points/u08,/u09,
an d /u10, but the OFA administrator replicates
this structure on every/u[0-9][0-9] mount p oint
in the file system. It is a good idea to bu ild the
q/dstructure for every database and every
moun t point, even if you do n ot intend to put
dat abase files on every m oun t point. The cost is
only a few inodes,7 and the benefit is that in an
emergency, any free disk space on your system
will be ready to h ouse a file from any database
that could require more space.
This structure m akes it easy to distinguish Ora-
cle database files of one database from Oracle
da tabase files of another. Using d istinct suffixes
for different typ es of database files makes it
easy to distingu ish one type of file from an-
other, fu lfilling r equirem ent 10.c.
7 The cost is n(k+1) inodes, wh ere n is the number of
user data m ount points on your system, and kis the
num ber of databases on your system.
8/7/2019 Oracle Ofa Whitepapaer
11/23
8/7/2019 Oracle Ofa Whitepapaer
12/23
12 Cary V. Millsap
Oracle System Perform ance Grou p Technical Paper , Septem ber 24, 1995
does not d ictate wh ether da tabase files are best
kept four layers deep in the file tree or six.
How ever, the requirements listed in this paper
app ear generally indisputable, and there seems
to be unanimous agreement among thinkers
about tw o assertions on storing Oracle data:
The directorys actual name doesnt matter,
as long as it is both (a) consistent with th e
nam es of other similar d irectories, and
(b) chosen carefully to not misrepresent the
contents of the directory.
The level at which any typ e of I/ O balanced
files are stored d oesnt ma tter, as long as
its the same level on every mou nt point.
The OFA Stand ard uses an algebraic-looking
regu lar expression notation in the data base file
nam ing recomm endation so that adm inistrators
are free to exploit the freedom of individ ual
tastes, as long as the tw o und erlying basis
points expressed above are honored. Today, the
site naming standard s represented by the fol-
lowing nam es lie comp letely within th e
boun daries of OFA comp liance:
/u01/ORACLE/sab/gld01.dbf/disk04/oradata/pdnt/gld01.dbf/db016/ora/mail/gld01.dbf/mars/data/disk31/bnr1/gld01.dbf/u08/app/oracle/data/pfin/gld01.dbf
Other standar ds are also approp riate in special
circumstances. Responsible site administrators
mu st consider the important points outlined in
section 4 before deciding to implem ent Oracle
on UN IX raw dev ices. Section 6 add resses
nam ing standard s appr opriate for consideration
by very large database sites.
2.3 Exploiting the OFA Structure for Oracle
Files
Figure 7 show s several useful UNIX pat terns
identifying classes of files that can be manipu -lated by a find command like the ones shown
earlier in Figure 4. Figure 8 is a comp lete picture
of the relationship s amon g the Oracle for UNIX
files in our familiar samp le three-database sys-
tem. In this example, the Oracle own ers login
hom e directory is in/u01/app, and the files for
this systems three databases are I/ O balanced
throughout subtrees named /*/oradata.
/u[0-9][0-9] user-data directories/*/home/* user h ome d irectories/*/app/* user application software directories/*/app/applmgr Oracle app s software subtrees/*/app/oracle/product Oracle Server software subtrees/*/app/oracle/product/6.0.37 Oracle Server 6.0.37 distribution files
/*/app/oracle/admin/sab sab database ad ministrative subtrees/*/app/oracle/admin/sab/arch/* sab da tabase archived log files/*/oradata Oracle database directories/*/oradata/sab/* sab da tabase files/*/oradata/sab/*.log sab da tabase red o log files
Figure 7. These file nam e patterns ar e useful in an OFA comp liant environmen t.
8/7/2019 Oracle Ofa Whitepapaer
13/23
OFA Standard 13
Oracle System Perform ance Group Technical Paper, Septem ber 24, 1995
3. Oracle Tablespaces
Tablespace is a name that was introduced in
Oracle Version 6 for an entity that r elates mu l-
tiple database segments to m ultiple operating
system files.
Segment Partitioning The tablespace forms the
interface through w hich the logical database can
be par titioned into d ifferent p hysical files in the
opera ting system . Factors that a ffect decisions
about separating Oracle segments into different
tablespaces include:
/ root mount pointu01/ user d ata mou nt p oint #1
app/ subtree for app lication softwareoracle/ login home for the Oracle Server software ow neradmin/ subtree for databa se adm inistrative files
TAR/ subtree for Support logsintl/ adm inistrative subtree for intl data basesab/ adm inistrative subtree for sab data basesabt/ adm inistrative subtree for sabt data base
local/ subtree for local Oracle softwar eaps6/ an Oracle6 admin istrative software p ackageaps7/ an Oracle7 adm inistrative software package
product/ Oracle Server distribution files6.0.37/ ORACLE_HOME for 6.0.37 instances7.0.16/ ORACLE_HOME for 7.0.16 instances
home/ subtree for login hom e directoriessbm/ home for a user
oradata/ subtree for Oracle dataintl/ subtree for intl database filessab/ subtree for sab database files
sabt/ subtree for sabt database filesu02/ user d ata mou nt p oint #2
app/ subtree for app softwareapplmgr/ hom e for the Oracle App lications owneralr/ Oracle Alertfnd/ App lication Object Librarygl/ -> /u03/app/applmgr/gl symbolic link to General Led ger files... more applications
home/ subtree for login hom e directoriesmlm/ home for a user
oradata/ subtree for Oracle dataintl/ subtree for intl database filessab/ subtree for sab database filessabt/ subtree for sabt database files
u03/ user d ata mou nt p oint #3app/ subtree for app lications softwareapplmgr/ auxiliary directory for Ora cle Applicationsgl/ Oracle General Ledger
home/ subtree for login hom e directoriesvrm/ home for a user
oradata/ subtree for Oracle dataintl/ subtree for intl database filessab/ subtree for sab database filessabt/ subtree for sabt database files
... more m ount p oints, etc.
Figure 8. This is a hierarchical directory listing for a sam ple OFA compliant system. Inden tation show s the
relationships amon g directories and the files and d irectories contained w ithin.
8/7/2019 Oracle Ofa Whitepapaer
14/23
14 Cary V. Millsap
Oracle System Perform ance Grou p Technical Paper , Septem ber 24, 1995
Fragmentation character. Dropp ing of seg-
ments causes tablespace free space
fragmentation that can lead you to the
doorstep of people who hope to d e-
fragmen t your d atabase in exchange for a
few thousand s of your dollars. Free space
fragmen tation is preventable. By separa tingsegmen ts with d ifferent lifespan s into dif-
ferent tablespaces, the database creator
prevents the p roblems associated w ith ta-
blespace free space fragmen tation.
I/O distribut ion . Only at the ta blespace level
can the adm inistrator determine w hat set of
opera ting system files a segment w ill oc-
cupy. By separa ting segments w ith
competing I/ O requirements into different
tablespaces, the database creator can make
it possible to ensure w ell-balanced I/ O
loads across hardw are components.
Administrative needs . Only at the tablespace
level can th e ad ministra tor sp ecify a collec-
tion of segments for backup , or restrict a
users privilege to consume database space.
By separating segments with different ad-
ministrat ive characteristics into d ifferent
tablespaces, the database creator can make
give the adm inistrator an ap propriate level
of control over collections of segmen ts.
The following requirement motivates decisions
about tablespace creation:
Requirement 11. Tablespace contents
mu st be separated to (a) minimize ta-
blespace free space fragmen tation,
(b) minimize I/ O request contention;
and (c) maximize ad ministrative flexi-
bility.
The next ru le fulfills requ irement 11.
OFA 7 Separate groups of segments w ith different
lifespans, I/O request demands, and backup frequen-
cies among different tablespaces. For each Oracle
database, create the following special tablespaces in
addition to those needed for applications segments:
SYSTEMdata dictionary segments only
TEMPtemporary segments only
RBSrollback segments only
TOOLSgeneral-purpose tools only
USERSmiscellaneous user segments
This standard has proven to ha ve several tre-
men dou s benefits. For examp le, because
dictionary segments are never drop ped, and
because no other segments that can be dropp ed
are allowed in the SYSTEM tablespace, this
scheme guarantees that the SYSTEM tablespace
will never require a rebuild d ue to tablespacefree space fragm entation. Because no rollback
segment is stored in any tablespace holding ap-
plications data, the administrator is never
blocked from taking an a pplications data ta-
blespace offline for maintenance. Because
segments are partitioned physically by type, the
adm inistrator can record and pred ict data vol-
um e growth rates without complicated tools.
Tablespace N ames The OFA standa rd of em-
bedding the n ame of a tablespace in the
basenam e of its associated d ata files (OFA 6)
means that UNIX file nam e length restrictions
also restrict tablespace name lengths. Although
Oracle tablespace names can be thirty charac-
ters long, portable UN IX file names are
restricted to four teen characters. Recall that th e
recommend ed stand ard for a data file ba-
sename istn.dbf, wh eret is a tablespace name
an d n is a tw o-digit string. The six-character
n.dbfsuffix leaves eight characters remaining
for t . The recomm ended naming stand ard for
tablespaces is thus:
OFA 8 Name tablespaces connotatively with eight
or fewer characters.
Eight-character tablespace nam es not only sim-
plify data file nam ing, they also make
adm inistrative reports about tablespaces mu ch
more 80-colum n friend ly. The total nu mber of
tablespaces in a database is generally on the
ord er of 100 or less, so inventing connotative
nam es with eight characters is usually easy.
Connotation enables the ad ministrator to divine
the p urp ose of a tablespace by looking at its
name. It is sometimes useful to encode informa-
tion about w hat type of segment a tablespace is
designed to store into the tablespace nam e. For
example, the names GLD an d GLX might con-
note that these tablespaces are designed to store
Oracle General Ledger data and indexes, re-
spectively. Figure 9 illustrates tablespace and
file nam ing in an OFA comp liant system.
8/7/2019 Oracle Ofa Whitepapaer
15/23
OFA Standard 15
Oracle System Perform ance Group Technical Paper, Septem ber 24, 1995
Resist the temptation to embed rem inders of the
word tablespace in your tablespace names. Ta-
blespaces are distinguishable as tablespaces bycontext, and their nam es do not need to convey
information about their type. A competent Ora-
cle ad ministrator would not confuse a
tablespace with another d atabase object, so
names like TEMP_TABLESPACE are patently
unn ecessary. Administrators learn as they
gather experience that em bedding type infor-
mation into an objects nam e is usually a waste
of motion.8
8 People who, after the sermon, insist upon continu-
ing to embed type information into the n ames of new
things are of course free to do so. However, I am also
free to fantasize that the gram mar p olice will make
these people use their own naming convention at
hom e until they see how ridiculous it is. The parents
of Billy the Kid, Attila the Hu n, Winnie the Pooh,
and Frosty the Snow man were evid ently afflicted
with such a curse.
4. Raw Devices vs. Buffered I/O
The term raw device is an informal synonym for
character special file, which is an unmou nted d isk
slice that Oracle can read an d w rite without
incurring the overhead of UNIX I/ O buffer-
ing [Bach 1986, Leffler et a l 1990]. A char acter
special file has a fixed size because it is allo-
cated an entire disk slice. Oracle Corpora tion
uses raw devices extensively in TPC bench-
marks to increase the nu mber of transactions
per second that Oracle can p erform. As temp t-
ing as a p otential performance gain sounds, use
of raw I/ O bears und eniable costs. The follow-
ing sections identify some of the benefits and
costs of using raw d evices.
Benefits of Using Raw Devices The following
factors weigh in favor of using raw d evices:
If you intend to use Oracle Parallel Server
on a UN IX cluster, with mu ltiple UNIX
nodes m anipulating a single database on a
File Type or
Tablespace Name
File Name Size (KB)
control /u01/oradata/sab/control.ctl
control /u02/oradata/sab/control.ctl
control /u03/oradata/sab/control.ctl
redo group 1/u03/oradata/sab/redo0101.log
5,120redo group 1 /u05/oradata/sab/redo0102.log 5,120redo group 1 /u07/oradata/sab/redo0103.log 5,120redo group 2 /u04/oradata/sab/redo0201.log 5,120redo group 2 /u06/oradata/sab/redo0202.log 5,120redo group 2 /u08/oradata/sab/redo0203.log 5,120SYSTEM /u02/oradata/sab/system01.dbf 65,536TEMP /u04/oradata/sab/temp01.dbf 131,072RBS /u03/oradata/sab/rbs01.dbf 65,536TOOLS /u07/oradata/sab/tools01.dbf 16,384USERS /u07/oradata/sab/users01.dbf 32,768AOL /u05/oradata/sab/aol01.dbf 98,304GLD /u02/oradata/sab/gld01.dbf 524,288GLD /u04/oradata/sab/gld02.dbf 524,288GLX /u05/oradata/sab/glx01.dbf 524,288
Figure 9. This is a file map of a sam ple OFA compliant da tabase. Note the
ease with w hich you can d iscern each files mou nt point, its app lication, its
datab ase, and its tablespace. Note also th at each files typ e (control file,
redo log file, or d ata file) is app arent by v iewing its nam e.
8/7/2019 Oracle Ofa Whitepapaer
16/23
16 Cary V. Millsap
Oracle System Perform ance Grou p Technical Paper , Septem ber 24, 1995
shared d isk subsystem, you m ust use raw
devices. UNIX vendors have not yet im-
plemented a way for nodes in a cluster to
simultaneously moun t a shared d isk sub-
system.
Some platforms offer the capability for
asynchronous I/ O to boost outpu t perform-
ance. Asynchronous I/ O is normally
available only with character sp ecial de-
vices, outsid e the UNIX file system. Ask
your hard ware vend or or Oracle World-
wide Supp ort for more d etails about your
particular implementation.
Using raw devices will in some cases in-
crease throughput if either your processes
frequently wait for I/ O, or your system
state CPU tim e is persistently excessive.9
If you h ave variable disk pa rtitioning,10 us-
ing raw devices for redo log files is
par ticularly attractive, because: Raw d e-
vices benefit you m ost for write-intensive,
sequentially accessed data; and online redo
log files are not included in norm al operat-
ing system backup procedures.
Costs of Using Raw D evices The following
factors weigh against using raw devices:
Raw d evices are m ore costly to ad minister
than files in the UN IX file system. Op era-
tions that become more difficult are backupand recovery, I/ O load balancing, and ad di-
tion of files to the d atabase. If you do not
have the ability to thorough ly practice da -
tabase recovery before taking you r project
9 An interesting exception to the perform ance benefit
trad itionally attributed to raw d evice configura tions
occurs with ap plications tha t rely on table scans for
data access. These applications actually perform
better on moun ted file systems than on raw devices.
Improving the performance of an ap plication that
does frequen t table scans begins with an alysis of the
app lications data access methods, not with sw eep-ing changes to the underlying operating system
configuration.10 Variable disk partitioning is a capability offered by
many UNIX vendors logical volume management
software. With this capability, an adm inistrator can
mak e any d isk slice any size at all; withou t variable
disk partitioning, an administrator must choose from
a limited (usually small) number of ways to cut a
disk into slices.
live, then do not u se raw devices. If you do
not hav e sufficient d isk volum e that you
can leave two or more large un formatted
disk slices available for da tabase grow th or
I/ O balancing, then do not use raw d evices.
Raw I/ O improves throughput in only a
small percentage of production site situa-
tions. Applications in wh ich I/ O or I/ O-
related p rocessing is not the bottleneck will
not deliver better throughpu t by improving
the performance of I/ O and I/ O-related
processing. If I/ O is your bottleneck, then
before choosing to use raw devices, ensure
that you h ave taken full advan tage of per-
formance optimization techniques that are
less costly to you :
Carefully constru ct your app lication to
minimize I/ O.
Configure your operating system and
instance param eters so that the Oracle
Server op erates as efficiently as possi-
ble.
Balance your I/ O load across enough
disks that each d rives data transfer rate
is within the manufacturers recom-
mend ed limits for the drive and its
controller.
After these optimizations, you are likely to
find that I/ O and th e CPU overhead associ-ated w ith I/ O is no longer your bottleneck,
at w hich p oint moving to a raw device con-
figuration will not improve throughp ut.
If your UNIX imp lementat ion does not offer
variable disk partitioning, a raw device
Oracle configuration requires more disk
volume than a similarly configured d ata-
base using buffered I/ O. Fixed partitioning
constraints make it difficult to find en ough
suitably sized d isk slices for red o logs and
small data files. A dangerous consequence
of any raw d evice configuration is that
having on ly a few large slices tempts th e in-
experienced configuration planner to
combine da tabase segments that shou ld be
separated among Oracle tablespaces. The
benefits of raw devices are not enou gh to
overcome the u ser performance and server
8/7/2019 Oracle Ofa Whitepapaer
17/23
OFA Standard 17
Oracle System Perform ance Group Technical Paper, Septem ber 24, 1995
adm inistrator workload costs of a poor
fundamental configuration decision.
If your s is a big site with a sophisticated Or acle
for UNIX ad ministra tion staff with tim e for re-
search, enough budget for several d isk drives,
and enough p atience to leave some of your diskspace unused but reserved for unanticipated
growth an d load balancing, then using raw d e-
vices may be economically feasible for you . If
you u se raw devices, you w ill need to m eet the
following requirement:
Requirement 12. It must be p ossible to
tune d isk I/ O load across all drives, in-
cluding drives storing Oracle data in
character special files.
The following rule enables the ad ministrator to
remed y a persistent I/ O imbalance in a raw d e-
vice configuration, because tw o character
special files can tr ade places on d isk only if they
are pr ecisely the same size.
OFA 9 Choose a small set of standard sizes for all
character special files that may be used to store Ora-
cle database files.
The Verdict Use of raw I/ O does not necessar-
ily increase a sites throu ghp ut, so a resp onsible
adm inistrator will study the issues before using
them. Simp ly stated, if you are not ru nning
Oracle Parallel Server and testing shows there
to be no performance improvement by u singraw devices in your specific environmen t, then
using them w ould be all cost and n o gain for
you. If testing show s raw devices to impr ove
performance by an amount that outw eighs the
cost of administering them, then u se raw de-
vices. If you lack the time or expertise to invest
in construction of a test to determine w hether
or not to use raw devices, then you probably
also lack the time or expertise to adm inister
them effectively.
When determ ining w hether or not to use raw
dev ices, do not ignore the p ossibility of using
them only for some database files. Hybrid sys-
tems that use unbu ffered I/ O for sequential
write-intensive files (e.g., redo log files in highly
active OLTP environments) and bu ffered I/ O
for other files (e.g., control and da ta files that
have to be backed up by a UN IX adm inistrator)
can offer the best m ixture of low cost and high
gain.
5. Oracle Parallel Server
Administrative Files
Using Oracle Parallel Server (OPS) add s chal-lenges to the database ad ministrative task,
because the OPS environm ent highlights the
distinction between instan ce (a collection of
processes and mem ory) and d atabase (a collec-
tion of files). For examp le, assume th at the sab
database is simu ltaneously held open by tw o
OPS instan ces on two UN IX nod es, sab1 on
node node1 an d sab2 on node node2. Regard -
less of which instance hosts the conn ection, a
report on a d ata d ictionary table (or view, such
as dba_users) will provide a consistent answ er.
How ever, a report produ ced on a dynam ic per-forman ce table (or view, such as v$parameter)
will give an answer wholly dependent up on
wh ich instan ce hosts the connection. Hence the
motivation for the following requirement:
Requirement 13. (a) Database specific
adm inistrative data mu st be stored in a
central p lace accessible to all instan ce
ad ministrators; and (b) instan ce specific
adm inistrative data mu st be distin-
guishable as associated with a given
instance by file nam e.
In other word s, you m ust never have to search
mu ltiple directories to find a ll the reports on
dba_users for a given database, and you mu st
never have to look through a list of
v$parameter reports to find the ones related to
the instance you are inspecting.
We can refine our un derstand ing of how to ful-
fill requirem ent 13 by observing the following
features ab out OFA 5: the d irectories arch, cre-
ate, and exp are database ad ministrative
directories; adump, bdump, cdump, pfile, and
udump are instance administrative directories;an d adhoc an d logbook are curious m ixtures of
both.
8/7/2019 Oracle Ofa Whitepapaer
18/23
18 Cary V. Millsap
Oracle System Perform ance Grou p Technical Paper , Septem ber 24, 1995
One w ay of structuring the adm inistrative di-
rectory for the sab database is dep icted in
Figure 10. In th is example, each ad ministrative
subtree that must contain information specific
to two or more instances uses another directory
layer to den ote the d istinction in the file nam e.
For example, consider th e admin/sab/logbook
directory. Operationally, an Oracle administra-
tor wou ld use this as the w orking directory for
a SQL*Plus , SQL*DBA, or Server Manager ses-sion while adm inistering th e sab database. A
data dictionary table report like users.lst would
be spooled to the current working d irectory,
regardless of whether the a dm inistrator is con-
nected to sab1 or sab2, to meet r equirem ent 13.
But a dynamic performance table report like
params.lst wou ld be spooled to the directory
nam ed for the instance to which the ad ministra-
tor run ning the report is connected. In ad dition
to flexibly accomm odat ing the storage of data-
base and instance report h istory, the Figure 10
arrangement enables ad ministrators to quickly
find trace files created by a given instance.
Therefore, the stru cture show n here fulfills re-
quirem ent 13.b.
Further OPS environment complication derives
from the fact that any instance can be adm inis-
tered from any node in the cluster. An
ad ministrator is equally likely to have logged
into node2 to adm inister the sab database as
node1, and , throu gh SQL*Net, the node2 user
can adm inister the sab1 instance as sab2. How-
ever, to fulfill requ iremen t 13.a, the
adm inistrator mu st use a single central adminis-
trative directory to store database r eports. A
mechanism for accomm odating this require-
/u01/app/oracle/admin/sab/ administrative directory for sab databaseadhoc/ directory for miscellaneous scriptsadump/ directory for audit file du mp s
sab1/ aud it file d est for sab1 instan cesab2/ aud it file d est for sab2 instan ce
arch/ log archive dest for a ll instan ces
redo0001.arc archived r edo log filebdump/ directory for background du mp files
sab1/ background dump dest for sab1 instancesab2/ background dump dest for sab2 instance
cdump/ directory for core dump filessab1/ core du mp dest for sab1 instancesab2/ core du mp dest for sab2 instance
create/ directory for creation scriptsexp/ directory for exports
930920full.dmp Sep 20 full export d um p fileexport/ directory for export pa rfilesimport/ directory for import parfiles
logbook/ directory for sab logbook entriessab1/ directory for sab1 instance rep ortsparams.lst v$parameter repor t for sab1 instance
sab2/ directory for sab2 instance rep ortsparams.lst v$parameter repor t for sab2 instanceusers.lst dba_users report
pfile/ directory for instance parameter filessab1/ directory for sab1 instance pa ram eterssab2/ directory for sab2 instance pa ram eters
udump/ directory for user d um p filessab1/ user d um p d est for sab1 instancesab2/ user d um p d est for sab2 instance
Figure 10. Administrative directory structure for dual instance OPS
8/7/2019 Oracle Ofa Whitepapaer
19/23
OFA Standard 19
Oracle System Perform ance Group Technical Paper, Septem ber 24, 1995
men t is to choose exactly one nod e to act as
ad ministrative h ome for maintena nce of a
database. Each node h ousing an instance that
connects to that d atabase may have a distinct
product directory, but the admin/ddirectory
for a given d atabase must be a remotely
mou nted link to the admin/ddirectory on theadm inistrative home nod e. Thus, when an ad -
ministrator logged onto node2 sets
~oracle/admin/sab as the sessions curren t
working directory, the w orking directory
ph ysically becomes th e central
node1:/u01/app/oracle/admin/sab , fulfilling
requirement 13.
From this discussion, we can ind uce the fol-
lowing rule:
OFA 10 If you are using Oracle Parallel Server,
select exactly one nodeNto act as Oracle admin is-trative home for the cluster to house the
administrative subtree defined in rule OFA 5. Leth
be the Oracle software owners login home directory
on nodeN. Create a directory named for each in-
stance accessing databasedwithin theadump,
bdump,cdump, logbook,pfile, andudump direc-
tories ofN:h/admin/d. On every noden in the
cluster exceptN, mount the remote directory
N:h/admin/das the administrative directory for
databased(i.e., asn:h/admin/d).
6. Mount Points for VLDB SitesThere are at least tw o very different correct so-
lutions to the moun t point nam ing challenge,
one for sites wh o can relax requiremen t 4 to
satisfy requirement 2 economically, and on e for
sites able to afford massive disk farms. Most
sites should u se OFA 1. Only a hand ful of very
large da tabase (VLDB) sites world wid e should
consider the following stra tegy.
OFA 11 If you can afford enough hardware that:
1. You can guarantee that each disk drive11 will
contain database files from exactly one applica-tion; and
11 This is imp ortant: each diskdrive, not diskslice.
You violate requ irement 4 if you place two ap plica-
tions on the sam e disk, even if theyre stored in two
different slices.
2. You can dedicate sufficient ly many drives to
each database to ensure that there will be no I/O
bottleneck.
Then name mount points matching the pattern/qdm
where q is a string denoting that Oracle data and
nothing else is to be stored there,dis the value of the
db_name init.ora parameter for the single database
that will be stored there, andm is a unique fixed-
length key that distinguishes one mount point for a
given database from another.
Mount p oint names like/ora/intl01 connote a
commitment to putting only control, redo log,
and data files from the single Oracle database
called intl on a given disk slice.12 If you ad opt
this standard, you commit never to need to use
your Oracle data m ount p oints for anything
else. Only a v ery small percentage of all Oracle
customers worldw ide can make this comm it-ment, and you shou ld not adopt this particular
VLDB compon ent of the OFA Stand ard if there
is a risk that you cannot.
7. Quick Reference Summary
The following sections are intend ed for use as a
reference guide that su mm arizes the system
requirements and OFA Standard recomm enda-
tions discussed in this paper.
7.1 System Requirements
1. The file system mu st be organized so tha t it
is easy to administer growth from: adding
data into existing d atabases, add ing users,
creating databases, and ad ding hardw are.
2. It must be possible to distribute I/ O load
across sufficiently many d isk drives to pre-
vent a performance bottleneck.
3. It may be necessary to minimize hard ware
cost.
4. It may be n ecessary to isolate the impact of
dr ive failure across as few app lications aspossible.
5. It must be possible to distribu te across two
or m ore d isk drives both (a) the collection
of home directories and (b) the contents of
an individual hom e directory.
12 In this example, q=ora/,d=intl , and m=01.
8/7/2019 Oracle Ofa Whitepapaer
20/23
20 Cary V. Millsap
Oracle System Perform ance Grou p Technical Paper , Septem ber 24, 1995
6. It must be p ossible to add or move login
home directories without having to revise
program s that refer to them.
7. Categories of files mu st be separated into
independ ent d irectory subtrees so that files
in one category are m inimally affected by
opera tions upon files in the other catego-
ries.
8. It mu st be possible to execute mu ltiple ver-
sions of applications software
simultaneously. Cutover after u pgrad e
mu st be as simp le for the adm inistrator and
as transparent for the user commu nity as
possible.
9. Administrative information about one da-
tabase must be separated from that of
others; there mu st be a reasonable structure
for organization and storage of adm inistra-
tive data.
10. Database files should be nam ed so that
(a) database files are easily distinguishab le
from oth er files; (b) files of one d atabase a re
easily distinguishable from files of another;
(c) control files, redo log files, and data files
are easily distingu ishable from on e another;
and (d) the association of data file to ta-
blespace is easily identifiable.
11. Tablespace contents mu st be separated to
(a) minimize tablespace free space fragm en-tation, (b) minimize I/ O request contention;
and (c) maximize ad ministrative flexibility.
12. It mu st be possible to tune d isk I/ O load
across all dr ives, including d rives storing
Oracle da ta in character special files.
13. (a) Database sp ecific ad ministrat ive data
mu st be stored in a centr al place accessible
to all instance ad ministrator s; and
(b) instance specific adm inistrative da ta
mu st be d istinguishable as associated w ith a
given instance by file nam e.
7.2 OFA Standard Recommendations
1. Nam e all mount points that w ill hold site-
specific data to match th e pattern /pm
wherep is a string constan t chosen not to
misrepresent the contents of any moun t
point, and m is a uniqu e fixed-length key
that d istinguishes one mount p oint from
another.
2. Nam e home d irectories matching the pat-
tern/pm/h/u, wherepm is a mount p oint
name,h is selected from a small set of stan-
dard directory names, and u is the name of
the own er of the directory.
3. Refer to explicit path nam es only in files
designed specifically to store them , such as
the UNIX/etc/passwd file and the Ora cle
oratab file; refer to group memberships
only in/etc/group.
4. Store each version of Oracle Server d istribu-
tion software in a d irectory matching the
pattern h/product/v , whereh is the login
home directory of the Oracle software
owner, and v represents the version of the
software.
5. For each da tabase with db_name=d, store
da tabase ad ministration files in the follow-
ing subd irectories ofh/admin/d:
adhocad h oc SQL scripts for a given
database
adumpaud it trail trace files
archarchived red o log files
bdumpbackground process trace files
cdumpcore du mp files
createprograms used to create the da-
tabase
expdatabase export files
logbookfiles record ing the statu s and
history of the database
pfileinstan ce param eter files
udumpuser SQL trace files
whereh is the Oracle software owners
login home directory.
6. Name Oracle database files using the fol-
lowing patterns:
/pm/q/d/control.ctlcontrol files
/pm/q/d/redon.logredo log files
/pm/q/d/tn.dbfdata files
wherepm is a moun t point name, q is a
string denoting the separation of Oracle
da ta from all other files,dis the db_name
8/7/2019 Oracle Ofa Whitepapaer
21/23
OFA Standard 21
Oracle System Perform ance Group Technical Paper, Septem ber 24, 1995
of the database,n is a distinguishing key
that is fixed-length for a g iven file typ e, and
t is an Oracle tablespace name. Never store
any file other than a control, redo log, or
data file associated w ith database din
/pm/q/d.
7. Separate group s of segmen ts with different
lifespans, I/ O request demand s, and
backup frequencies among different ta-
blespaces. For each Oracle database, create
the following special tablespaces in ad dition
to those needed for ap plications segments:
SYSTEMdata d ictionary segments
only
TEMPtemporary segments only
RBSrollback segmen ts only
TOOLSgeneral-pu rpose tools only USERSmiscellaneous user segments
8. Nam e tablespaces connotatively with eight
or fewer characters.
9. Choose a sma ll set of stand ard sizes for all
character special files that m ay be used to
store Oracle database files.
10. If you are u sing Ora cle Para llel Server, se-
lect exactly one nod eNto act as Oracle
adm inistrative home for the cluster to
house the ad ministrative subtree defined in
rule OFA 5. Leth be the Oracle softwareowners login home d irectory on n ode N.
Create a d irectory nam ed for each instance
accessing databasedwithin the adump,
bdump, cdump, logbook, pfile, and
udump directories ofN:h/admin/d. On
every noden in the cluster exceptN, moun t
the rem ote directoryN:h/admin/das the
adm inistrative directory for d atabased(i.e.,
as n:h/admin/d).
11. If you can afford enou gh hard ware that:
1. You can guarantee tha t each disk drivewill contain d atabase files from exactly
one ap plication; and
2. You can ded icate sufficiently man y
drives to each d atabase to ensure that
there will be no I/ O bottleneck.
Then name mou nt points matching the pat-
tern /qdm where q is a string denoting that
Oracle data an d n othing else is to be stored
there,dis the value of the db_name init.ora
param eter for the single database that w ill
be stored there, and m is a unique fixed-
length key th at d istinguishes one m ount
point for a given d atabase from an other.
8. References
BACH , M. 1986. The Design of the UNIX Operating
System . Englewood Cliffs, New Jersey: Pren-
tice Hall.
FRISCH, A. 1991.Essential System A dministration .
Sebastopol, California: OReilly & Associ-
ates.
LEFFLER, S.; MCKUSICK, M.; KARELS, M.;
QUARTERMAN, J. 1990. The Design and Im-
plementation of the 4.3BSD UNIX OperatingSystem. Reading, Massachusetts: Addison-
Wesley.
LOUKIDES, M. 1991. System Performance Tuning.
Sebastopol, California: OReilly & Associ-
ates.
MILLSAP, C. 1993. An opt imal flexible architec-
ture for a growing Oracle database. In
Oracle Magazine, vol. VII no. 1 (Winter
1993): 4146. Published originally as an
Oracle Corporation w hite paper, 1990. Also
pu blished as Configuring a growing Ora-
cle V6 da tabase for optimal perform ance in
1991International Oracle User Week Proceed-
ings, pap er 513.
NEMETH , E; SNYDER, G; SEEBASS, S. 1989. UNIX
System Administration Handbook. Englewood
Cliffs, New Jersey: Prentice Hall.
9. UN IX Utilities
UNIX site adm inistrators are always on the
lookout for useful utilities that ease the burd en
of adm inistering complex app lications. Thepages at the end of this pap er give you portable
utilities that are typical of the small, reliable
tools used by OFA comp liant Oracle sites. Local
general-pu rpose u tilities such as these should
norm ally be stored in th e directory called
/var/opt/bin. Enjoy.
8/7/2019 Oracle Ofa Whitepapaer
22/23
22 Cary V. Millsap
Oracle System Perform ance Grou p Technical Paper , Septem ber 24, 1995
LHD(L) Oracle Services Utilities LHD(L)
NAME
lhd print login hom e directory name for a given u ser
SYNOPSIS
lhd [login]
DESCRIPTION
lhd print s the nam e of the login home d irectory for a given UNIX login, to allow the ad ministra-
tor to refer to a u sers login h ome d irectory without hard -coding the p ath na me. Using `lhd
login` in the Bourne shell is the equ ivalent of~login in the C shell or KornShell. lhd enables
creation of zero-maintenance administration programs that can survive file system changes
without modification.
EXAMPLES
example$ . `lhd applmgr`/AOL.env
This example show s a line typical to that executed to set up a UN IX environm ent for Oracle
App lications. The .profile containing this line of code wou ld not requ ire mod ification if thelogin home d irectory for applmgr were to change.
AUTHOR
Cary V. Millsap, Oracle Services
SOURCE
#!/bin/sh## lhd - print login home directory name for a given user## Cary Millsap, Oracle Services# @(#)1.1 (93/05/17)
prog=`basename $0`
if [ $# -eq 0 ] ; thenlogin=`whoami`
elif [ $# -eq 1 ] ; thenlogin=$1
elseecho "Usage: $prog login" >$2exit 2
finawk -F: '$1==login {print $6}' login=$login /etc/passwd
8/7/2019 Oracle Ofa Whitepapaer
23/23
OFA Standard 23
GRPX(L) Oracle Services Utilities GRPX(L)
NAME
grpx print the list of users belonging to a given gr oup
SYNOPSIS
grpx group
DESCRIPTION
grpx pr ints the list of users belonging to a given group . grpx can be used to eliminate the need
for hard -coding group mem berships into administrative program s used to man ipulate (e.g.,
back up , prop agate files to) classes of users.
EXAMPLES
example$ for u in `grpx clerk` ; doexample> cp /etc/skel/.profile `lhd $u`example> done
This example shows h ow the adm inistrator can propagate a skeleton .profile to the home direc-
tory for each member of a group. This code would not require modification if the membership
list of the clerk group w ere to change.
AUTHOR
Cary V. Millsap, Oracle Services
SOURCE
#!/bin/sh## grpx - print the list of users belonging to a given group## Cary Millsap, Oracle Services# @(#)1.1 (93/07/04)
prog=`basename $0`if [ $# -ne 1 ] ; then
echo "Usage: $prog group" >&2exit 2
fig=$1# calculate group id of ggid=`nawk -F: '$1==g {print $3}' g=$g /etc/group`# list users whose default group id is gidu1=`nawk -F: '$4==gid {print $1}' gid=$gid /etc/passwd`# list users who are recorded members of gu2=`nawk -F: '$1==g {gsub(/,/," "); print $4}' g=$g /etc/group`# remove duplicates from the union of the two listsecho $u1 $u2 | tr " " "\012" | sort | uniq | tr "\012" " "echo