1
Optimal Flexible Architecture on Oracle8

Optimal Flexible Architecture (OFA)

Oracle Corporation recommends the Optimal Flexible Architecture (OFA) standard for Oracle8. 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 like 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

Tuning of I/O Loads 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 Oracle8 for 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: Oracle8 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 1-1.

Table 1-1 Syntax for Naming Mount Points

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

For example, mount points named /u01/oradata/test01 and /u01/oradata/test02 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 1-2.

Table 1-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 installer) 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 Oracle8 Server software in a directory matching the pattern /pm/h/product/v, as explained in Table 1-3

Table 1-3 Syntax for Naming Oracle8 Server Software Directories

h	a standard directory name
v	the version of the software

For example: /u01/app/oracle/product/8.0.4 indicates the start of the directory structure where the Oracle8 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 to store database-specific administration files in subdirectories according with 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 1-4:

Table 1-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. This subdirectory should be 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/sab/admin/adhoc/

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

Table 1-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 1-6. These tablespaces are in addition to those needed for application segments.

Table 1-6 Special Tablespace

SYSTEM	data dictionary segments
TEMP	temporary segments
RBS	rollback segments
TOOLS	general-purpose tools
USERS	miscellaneous user segments

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 Oracle8 tablespace names can be thirty characters long, portable UNIX file names are restricted to fourteen 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 1-7 shows the syntax used for identifying classes of files.

Table 1-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.0.4`	Oracle Server 8.0.4 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 1-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 1-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.2/`	ORACLE_HOME for 7.3.2 instances
					`7.3.3/`	ORACLE_HOME for 7.3.3 instances
					`8.0.4/`	ORACLE_HOME for 8.0.4 instances
		`home/`				subtree for login home directories
			`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
		`home/`				subtree for login home directories
		`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, the striping should be done with a logical volume manager.

File Mapping for Multiple-Instance OFA Database

Multiple-instance databases (Oracle Parallel Server installations) have an additional guideline for file mapping.

Administrative Home for Oracle Parallel Server

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/. The admin directory for the administrative home should be mounted as the admin directory for every instance. An example is shown in Table 1-9.

Table 1-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
		`970920full.dmp`		Sept 20 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 1-10. When installing an OFA-compliant database using the Oracle Installer, ORACLE_BASE is by default, set to /pm/app/oracle.

Table 1-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 /mount_point/app/oracle/product/release_number. ORACLE_HOME directory structure and content is described in Table 1-11. Under UNIX, the ORACLE_HOME directory contains the following subdirectories, as well as a subdirectory for each Oracle product:

Table 1-11 ORACLE_HOME Directory Structure and Content

`bin`	binaries for all products
`ctx`	ConText cartridge
`dbs`	`init`sid`.ora`, `lk`sid
`jdbc`	JDBC drivers
`lib`	Oracle product libraries
`md`	Spatial cartridge
`mlx`	Xerox Stemmer (for ConText cartridge)
`network`	Net8
`nlsrtl`	NLS runtime loadable data
`ocommon`	common files for all products
odg	data gatherer
opsm	Parallel Server Manager Components
oracore	core libraries
`orainst`	master installation files and programs
`ord`	data cartridges
`otrace`	Oracle TRACE
`plsql`	PL/SQL
precomp	precompilers
`rdbms`	server files and libraries required for the database
`slax`	SLAX parser
`sqlplus`	SQL*Plus
`svrmgr`	Server Manager

Oracle Product Subdirectories

Product subdirectories may include those described in Table 1-12, depending on the Oracle products available on your system and the products you purchase.

Table 1-12 Oracle Product Subdirectories

`network`	Oracle Net8
`ocommon`	libraries and SQL messages. All products depend on this directory, which is installed automatically
`plsql`	PL/SQL version 2, procedural option
`sqlplus`	SQL*Plus
`svrmgr`	Server Manager

Contents of Product Subdirectories

Each product subdirectory contains the subdirectories described in Table 1-13:

Table 1-13 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
`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 1-14.

Table 1-14 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 1-15.

Table 1-15 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)
`dbms*.sql`	additional database packages
`utl*.sql`	creates tables and views for database utilities

Filename Extensions

A description of filename extensions is shown in Table 1-16.

Table 1-16 Filename Extensions

`.a`	object file libraries; Ada runtime libraries
`.ada`	Ada source files
`.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
`.dei`	ORCA de-installation script
`.dmp`	Export file
`.doc`	ASCII text file
`.env`	shell script file for setting environment
`.f`	FORTRAN source file
`.h`	C header file; also, `sr.h` is a SQL*Report Writer help file
`.ins`	ORCA installation script
`.l`	UNIX manual page
`.lis`	output of SQL*Plus scripts
`.log`	installation log files; Oracle Server redo log files
`.map`	Installer product component 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
`.pad`	Pro*Ada source file
`.pc`	Pro*C source file
`.pco`	Pro*COBOL source file
`.ppd`	printer driver file
`.pfo`	Pro*FORTRAN source file
`.prd`	product registration template file (for `orainst`)
`.res`	Toolkit II resource 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
`.us`	`orainst` message file
`.utd`	Uniform Terminal Definitions
`.vrf`	Installer Dependencies Verification Script

Default OFA Database

An OFA default database created using the Oracle Installer is shown in Figure 1-1.

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

1Optimal Flexible Architecture on Oracle8