A
Optimal Flexible Architecture

Optimal Flexible Architecture (OFA)

Oracle Corporation recommends the Optimal Flexible Architecture (OFA) standard for Oracle8i. The OFA standard is a set of configuration guidelines for fast, reliable Oracle databases that require little maintenance.

OFA is designed to:

organize large amounts of complicated software and data on disk to avoid device bottlenecks and poor performance
facilitate routine administrative tasks such as software and data backup functions, which are often vulnerable to data corruption
alleviate switching among multiple Oracle databases
adequately manage and administer database growth
help eliminate fragmentation of free space in the data dictionary, isolate other fragmentation, and minimize resource contention

Characteristics of OFA-Compliant Database

An OFA-compliant database provides the following benefits.

File System Organization

The file system is organized to allow easy administration and accommodate scalability for:

adding data into existing databases
adding users
creating databases
adding hardware

Distributed I/O Loads

I/O loads are distributed across enough disk drives to prevent performance bottlenecks.

Hardware Support

Hardware costs are minimized only when it does not conflict with operational considerations.

Safeguards Against Drive Failures

By spreading applications across more than one drive, drive failures impact as few applications as possible.

Distribution of Home Directories

The following items can be distributed across more than one disk drive:

the collection of home directories
the contents of an individual home directory

Integrity of Login Home Directories

It is possible to add, move, or delete login home directories without having to revise programs that refer to them.

Independence of UNIX Directory Subtrees

Categories of files are separated into independent UNIX directory subtrees so that files in one category are minimally affected by operations on files in other categories.

Supports Concurrent Execution of Application Software

It is possible to execute multiple versions of applications software simultaneously, allowing the user to test and use a new release of an application before abandoning the previous version. Transferring to a new version after an upgrade is simple for the administrator and transparent for the user.

Distinguishes Administrative Information for each Database

The ability to separate administrative information about one database from that of another ensures a reasonable structure for the organization and storage of administrative data.

Uses Consistent Database File Naming

Database files are named so that:

database files are easily distinguishable from all other files
files of one database are easily distinguishable from files of another database
control files, redo log files, and data files are identifiable as such
the association of data file to tablespace is clearly indicated

Separation of Tablespace Contents

Tablespace contents are separated to:

minimize tablespace free space fragmentation
minimize I/O request contention
maximize administrative flexibility

I/O Loads Tuning across all Drives

I/O loads are tuned across all drives, including drives storing Oracle data in raw devices.

Additional Benefits of OFA for Parallel Server

For Oracle Parallel Server Installations:

administrative data is stored in a central place, accessible to all database administrators
administrative data for an instance is associated with the instance by the file name

OFA Implemented on UNIX

A careful naming strategy for database files eliminates data administration problems. The OFA rules provided here correspond to the original OFA recommendations published in The OFA Standard: Oracle8i for Open Systems.

Naming Mount Points

Mount Point Syntax

Name all mount points using the syntax /pm, where p is a string constant and m is a unique fixed-length key (typically a two-digit number) used to distinguish each mount point. For example: /u01 and /u02, or /disk01 and /disk02.

Naming Mount Points for Very Large Databases (VLDBs)

If each disk drive contains database files from one application and there are enough drives for each database to ensure no I/O bottleneck, then use the syntax /q/dm for naming mount points, as explained in Table A-1.

Table A-1 Syntax for Naming Mount Points

q	a string denoting that Oracle data is stored here
dm	the value of the initialization parameter DB_NAME (synonymous with the instance sid for single-instance databases)

For example, mount points named /u01/oradata/test and /u02/oradata/test allocate two drives for the Oracle test database.

Naming Directories

Home Directory Syntax

Name home directories using the syntax /pm/h/u, as explained in Table A-2.

Table A-2 Syntax for Naming Home Directories

pm	a mount point name
h	a standard directory name
u	the name of the owner of the directory

For example, /u01/app/oracle is the Oracle server software owner home directory (also referred to as ORACLE_BASE and defaulted by the OUI) and /u01/app/applmgr is an Oracle applications software owner home directory.

Placing home directories at the same level in the UNIX file system is advantageous for the following reason: it allows the collection of applications owner login home directories on different mount points, to be referred to with the single pattern matching string, /*/app/*.

Referring to Pathnames

Refer to explicit pathnames only in files designed specifically to store them, such as /etc/passwd and the Oracle oratab file. Refer to group memberships only in the /etc/group file.

Software Directories

In order to help fulfill the OFA requirement that it be possible to simultaneously execute multiple versions of application software, store each version of the Oracle8i Server software in a directory matching the pattern /pm/h/product/v, as explained in Table A-3.

Table A-3 Syntax for Naming Oracle8i Server Software Directories

h	a standard directory name
v	the version of the software

For example: /u01/app/oracle/product/8.1.5 indicates the start of the directory structure where the Oracle8i Server files are located. Set the ORACLE_HOME environment variable to this directory.

Naming Files

Administration Files

To facilitate the organization of administrative data, it is recommended that you store database-specific administration files in subdirectories according to h/admin/d/a/, where h is the Oracle software owner's home directory, d is the database name (DB_NAME), and a is a subdirectory for each of the following database administration files described in Table A-4:

Table A-4 Subdirectories for Database Administration Files

`adhoc`	ad hoc SQL scripts for a given database
`arch`	archived redo log files
`adump`	audit files (Set AUDIT_FILE_DEST in `config`db_name`.ora` to point here. Clean this subdirectory cleaned out periodically).
`bdump`	background process trace files
`cdump`	core dump files
`create`	programs used to create the database
`exp`	database export files
`logbook`	files recording the status and history of the database
`pfile`	instance parameter files
`udump`	user SQL trace files

As an example, the subdirectory adhoc would have the following pathname, /u01/app/oracle/admin/sab/adhoc/ if it were part of the database named sab.

Database Files

The following naming convention for database files ensures that they are easily identifiable:

for control files, use /pm/q/d/control.ctl
for redo log files, use /pm/q/d/redon.log
for data files use, /pm/q/d/tn.dbf

This syntax is explained in Table A-5.

Table A-5 Syntax for Naming Database Files

pm	a mount point name described earlier in this chapter
q	a string distinguishing Oracle data from all other files (usually named ORACLE or oradata)
d	the DB_NAME of the database
t	an Oracle tablespace name
n	a two-digit string

Note:
Do not store files other than a control, redo log, or data file associated with database d in the path /pm/q/d.

Following this convention could produce, for example, a data file with the name /u03/oradata/sab/system01.dbf, making it easy to see to which database the file belongs.

Separate Segments with Different Requirements

Separate groups of segments with different lifespans, I/O request demands, and backup frequencies across different tablespaces.

For each Oracle database, create the special tablespaces described in Table A-6. These tablespaces are in addition to those needed for application segments.

Table A-6 Special Tablespace

SYSTEM	data dictionary segments
TEMP	temporary segments
RBS	rollback segments
USERS	miscellaneous user segments
INDX	index associated with data in USERS tablespace
OEM_REPOSITORY	repository for Oracle Enterprise Manager
DRSYS	Oracle interMedia segment

This method is effective because dictionary segments are never dropped, and no other segments that can be dropped are allowed in the SYSTEM tablespace. This ensures that the SYSTEM tablespace does not require a rebuild due to tablespace free space fragmentation.

Because rollback segments are not stored in tablespaces holding applications data, the administrator is not blocked from taking an application's tablespace offline for maintenance. The segments are partitioned physically by type, and the administrator can record and predict data growth rates without complicated tools.

Naming Tablespaces

Name tablespaces descriptively using a maximum of eight characters. Although Oracle8i tablespace names can be 30 characters long, portable UNIX file names are restricted to 14 characters. The recommended standard for a data file basename is tn.dbf, where t is a descriptive tablespace name and n is a two-digit string. Because the extension plus the two-digit string occupy a total of six characters, only eight characters remain for the tablespace name.

Descriptive names allow the name of a data file to be associated with the tablespace that uses it. For example, the names GLD and GLX might be used for the tablespaces storing General Ledger data and indices, respectively.

Note:
Do not embed reminders of the word "tablespace" in your tablespace names. Tablespaces are distinguishable by context, and names do not need to convey information about type.

Exploiting OFA Structure for Oracle Files

Table A-7 shows the syntax used for identifying classes of files.

Table A-7 Directory Structure Syntax for Identifying Classes of Files

`/u[0-9][0-9]`	user data directories
`//home/`	user home directories
`//app/`	user application software directories
`/*/app/applmgr`	Oracle apps software subtrees
`/*/app/oracle/product`	Oracle Server software subtrees
`/*/app/oracle/product/8.1.5`	Oracle Server 8.1.5 distribution files
`/*/app/oracle/admin/sab`	`sab` database administrative subtrees
`//app/oracle/admin/sab/arch/`	`sab` database archived log files
`/*/oradata`	Oracle data directories
`//oradata/sab/`	`sab` database files
`//oradata/sab/.log`	`sab` database redo log files

OFA File Mapping

Table A-8 shows an hierarchical file mapping of a sample OFA-compliant database, including each file's mount point, application, database, and tablespace. The file names indicate the file type (control, log, or data).

Table A-8 Hierarchical File Mapping for OFA Installation

`/`						root mount point
	`u01/`					'user data' mount point #1
		`app/`				subtree for app software
			`oracle/`			home for oracle software owner
				`admin/`		subtree for database admin files
					`TAR/`	subtree for Support logs
					`db_name1/`	admin subtree for db_name1 database
					`db_name2/`	admin subtree for db_name2 database
				`doc/`		online documentation
				`local/`		subtree for local Oracle software
					`aps6/`	an Oracle6 admin package
					`aps7/`	an Oracle7 admin package
				`product/`		distribution files
					`7.3.3/`	ORACLE_HOME for 7.3.3 instances
					`8.0.4/`	ORACLE_HOME for 8.0.4 instances
					8.1.5/	ORACLE_HOME for 8.1.5 instances
			`ltb/`			home for a user
			`sbm/`			home for a user
		`oradata/`				subtree for Oracle data
			`db_name1/`			subtree for db_name1 database files
			`db_name2/`			subtree for db_name2 database files
	`u02/`					'user data' mount point #2
		`home/`				subtree for login home directories
			`cvm/`			home for a user
			`vrm/`			home for a user
		`oradata/`				subtree for Oracle data
			`db_name1/`			subtree for db_name1 database files
			`db_name2/`			subtree for db_name2 database files
	`u03/`					'user data' mount point #3
		`oradata/`				subtree for Oracle data
			`db_name1/`			subtree for db_name1 database files
			`db_name2/`			subtree for db_name2 database files

Raw Device Sizes

Choose a small set of standard sizes for all raw devices that may be used to store Oracle database files. In general, standardizing on a single size is recommended. If a single size is used, raw files can be moved from one partition to another safely. The size should be small enough so that a fairly large number can be created but large enough to be convenient.

For example, a 2 GB drive could be divided into 10 partitions of 200 MB each--a good balance between size and number. Any tablespace using raw devices should stripe them across several drives. If possible, do the striping should be done with a logical volume manager.

File Mapping for Multiple-Instance OFA Database

When using the Oracle Parallel Server, select one node to act as the Oracle administrative home for the cluster. The administrative home contains the administrative subtree. Create subdirectories for each instance accessing the database within the bdump, cdump, logbook, pfile, and udump directories of ~/admin/d/. Mount the admin directory for the administrative home as the admin directory for every instance. An example is shown in Table A-9.

Table A-9 Administrative Directory Structure for Dual-Instance Oracle Parallel Server

`u01/`	`app/oracle/admin/sab/`			administrative directory for sab database
	`adhoc/`			directory for miscellaneous scripts
	`arch/`			log archive dest for all instances
		`redo001.arc`		archived redo log file
	`bdump/`			directory for background dump files
		`inst1/`		background dump dest for inst1 instance
		`inst2/`		background dump dest for inst2 instance
	`cdump/`			directory for core dump files
		`inst1/`		core dump dest for inst1 instance
		`inst2/`		core dump dest for inst2 instance
	`create/`			directory for creation scripts
		`1-rdbms.sql`		SQL script to create inst database
	`exp/`			directory for exports
		`19990120full.dmp`		January 20, 1999 full export dump file
		`export/`		directory for export parfiles
		`import/`		directory for import parfiles
	`logbook/`			directory for inst logbook entries
		`inst1/`		directory for inst1 instance reports
			`params.lst`	v$parameter report for inst1 instance
		`inst2/`		directory for inst2 instance reports
			`params.lst`	v$parameter report for inst2 instance
		`user.lst`		dba_users report
	`pfile/`			directory for instance parameter files
		`inst1/`		directory for inst1 instance parameters
			`init`	instance parameters for inst1 instance
		`inst2/`		directory for inst2 instance parameters
			`init`	instance parameters for inst2 instance
	`udump/`			directory for user dump files
		`inst1/`		user dump dest for inst1 instance
		`inst2/`		user dump dest for inst2 instance

Directory Structure

ORACLE_BASE Directory

ORACLE_BASE is the root of the Oracle directory structure. ORACLE_BASE directory structure and content is described in Table A-10. When installing an OFA-compliant database using the Oracle Universal Installer, ORACLE_BASE is by default set to /pm/app/oracle.

Table A-10 ORACLE_BASE Directory Structure and Content

`admin`	administrative files
`doc`	online documentation
`local`	subtree for local Oracle software
`product`	Oracle software

ORACLE_HOME Directory

If you install an OFA-compliant Oracle Server, the ORACLE_HOME directory is /pm/app/oracle/product/release_number. ORACLE_HOME directory structure and content are described in Table A-11. Under UNIX, the ORACLE_HOME directory contains the following subdirectories, as well as a subdirectory for each Oracle product selected. You will have directories only for the products you have installed.

Table A-11 ORACLE_HOME Directory Structure and Content

`assistants`	configuration Assistants
`bin`	binaries for all products
`ctx`	interMedia Text options
`dbs`	`init`sid`.ora`, `lk`sid
install	install related files
`lib`	Oracle product libraries
jlib	Java classes
`md`	Spatial options
`mlx`	Xerox Stemmer (for interMedia Text options)
`network`	Net8
`nlsrtl`	NLS runtime loadable data
`ocommon`	common files for all products
odg	data gatherer
opsm	Parallel Server Manager Components
oracore	core libraries
`ord`	data options
`otrace`	Oracle TRACE
`plsql`	PL/SQL
precomp	precompilers
`rdbms`	server files and libraries required for the database
`slax`	SLAX parser
`sqlplus`	SQL*Plus

Contents of Product Subdirectories

Each product subdirectory contains the subdirectories described in Table A-12:

Table A-12 Contents of Product Subdirectories

`admin`	administrative SQL and shell scripts (for example, `catalog.sql, catexp.sql,` and `demo.sql`)
`admin/*`	special directories for other products
`admin/resource`	resource files
`admin/terminal`	runtime terminal files
`demo`	demonstration scripts and datafiles
`doc`	README files (for example, `readmeunix.doc`)
`install`	product installation scripts
`jlib`	product Java classes
`lib`	product libraries and distributed makefiles
`log`	trace files and log files (for example, `orasrv.log` and *.`trc` files)
`mesg`	U.S. message files and Multilingual Option (formerly National Language Support) message text and binary files (for example, `oraus.msg` and `oraus.msb`)

Examples of Product Subdirectories

Examples of product subdirectories and their contents are shown in Table A-13.

Table A-13 Examples of Product Subdirectories

`rdbms`	install, lib, admin, doc, mesg, log
`sqlplus`	install, demo, lib, admin, doc, mesg

File Naming Conventions in the admin Directory

The rdbms/admin directory contains the SQL scripts shown in Table A-14.

Table A-14 admin Directory, File Naming Conventions

`cat*.sql`	Creates catalog and data dictionary tables and views. The following files are run automatically during installation: `catalog.sql` (for all installations) `catproc.sql` (for all installations) `catparr.sql` (for Parallel Server option installations) `catrep.sql` (for all installations) `catproc.sql` in turn runs the scripts for creating the standard PL/SQL packages, such as DBMS_SQL and DBMS_OUTPUT.
d*.sql	downgrade scripts
`dbms*.sql`	additional database packages
u*.sql	upgrade scripts
`utl*.sql`	creates tables and views for database utilities

Filename Extensions

A description of filename extensions is shown in Table A-15.

Table A-15 Filename Extensions

`.a`	object file libraries; Ada runtime libraries
`.aud`	Oracle audit file
`.bdf`	X11 font description file
`.bmp`	X11 bitmap file
`.c`	C source file
`.ctl`	SQL*Loader control file; Oracle Server control file
`.dat`	SQL*Loader datafile
`.dbf`	Oracle Server tablespace file
`.dmp`	Export file
`.doc`	ASCII text file
`.env`	shell script file for setting environment
`.h`	C header file; also, `sr.h` is a SQL*Report Writer help file
.`jar`	Java class archive
`.l`	UNIX manual page
`.lis`	output of SQL*Plus scripts
`.log`	installation log files; Oracle Server redo log files
`.mk`	`make` files
`.msb`	NLS message file (binary)
`.msg`	NLS message file (text)
`.o`	object module
`.ora`	Oracle configuration files
`.orc`	installation prototype files
`.pc`	Pro*C source file
`.pco`	Pro*COBOL source file
`.ppd`	printer driver file
`.sh`	Bourne shell script file
`.sql`	SQL* script files
`.sys`	Bourne shell script file
`.tab`	SQL* script file
`.trc`	trace files
`.tut`	Bourne shell script file
`.utd`	Uniform Terminal Definitions
.`zip`	Zip file

A Optimal Flexible Architecture