Oracle Ofa Whitepapaer

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


2/23


3/23


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 .


5/23

OFA Standard 5


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.


6/23

6 Cary V. Millsap


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.


7/23

OFA Standard 7


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/23

8 Cary V. Millsap


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.


9/23

OFA Standard 9


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.


10/23

10 Cary V. Millsap


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.


11/23


12/23

12 Cary V. Millsap


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.


13/23

OFA Standard 13


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.


14/23

14 Cary V. Millsap


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.


15/23

OFA Standard 15


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



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.


16/23

16 Cary V. Millsap


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


17/23

OFA Standard 17


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.


18/23

18 Cary V. Millsap


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


19/23

OFA Standard 19


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.


20/23

20 Cary V. Millsap


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


21/23

OFA Standard 21


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.


22/23

22 Cary V. Millsap


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


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

Oracle Ofa Whitepapaer

Documents

Transcript of Oracle Ofa Whitepapaer