Page 96
OFA Rule 3: Store each version of Oracle server distribution software in a directory matching the pattern h/product/v, where h is the application home directory of the Oracle software owner and v represents the version of the software.
A sample implementation of this rule is given in the following directory template:
/[mount_point]/APP/[application_name]/PRODUCT/[version]/application home
In this example, we see that application home directories are stored in the APP subdirectory directly underneath our mount point. We next use a generic name to identify the directory under which the application will be stored. The PRODUCT directory and version then follow.
A sample hierarchy using this naming convention is
/u01 app finance [...] qse [...] oracle admin product 7.1.6 [...] 7.3.3 [...] 8.0.3 [...]
While this method may seem more complicated than necessary, the resulting flexibility and ease of administration is well worth it. As you can see, under this mount point you have three applications installedfinance, QSE, and Oracle. Finance and QSE are third-party or homegrown applications, and the directory structures underneath the main directories follow the same format as shown in the Oracle hierarchy. In the Oracle application directory, you see the product and admin subdirectories. Within the product subdirectory are three versions of the Oracle software7.1.6, 7.3.3, and 8.0.3. Any change or new installation of Oracle software can be made to one version without fear of interaction with any other version.
Separating the versions in this manner is very important when performing testing and cutover of new Oracle versions. Obviously you need the ability to easily install a new version of the software without impacting your production installation. After your new version is tested, cutover to the new version is a simple matter of setting the correct environment variables to the new directory. The old version then can be deleted at your leisure.
One of the needs that necessitated the creation of the OFA guidelines was the difficulty DBAs faced when simultaneously administering many databases. A method to organize administrative information and data into a manageable and predictable format was needed. The admin directory we saw earlier is used to store files related to administering the database and goes a
Page 97
long way in improving the capability of a single person to keep track of many databases. Our next OFA rule is related to this structure:
OFA Rule 4: For each database with db_name=d, store database administration files in subdirectories of /h/admin/d, where h is the Oracle software owner's login home directory.
The following chart shows a sample admin directory structure:
/u01/app/oracle/admin PROD bdump udump cdump pfile sql create
The subdirectories in the admin directory are explained in Table 7.1.
Table 7.1 ADMIN Directories
Directory Name | Usage |
bdump | Background dump files (value of BACKGROUND_DUMP_DEST) |
udump | User dump files (value of USER_DUMP_DEST) |
cdump | Core files (UNIX only) |
pfile | init.ora and any other database initialization parameters |
sql | Database administration SQL files |
create | Scripts used to create the initial database and database objects |
init.ora files, trace and dump files, alert.log, and so forth are all stored in this central administrative directory. This eases administering the large amounts of data produced by an Oracle database. You can add directories to store other data as the need arises.
NOTE |
On UNIX platforms, create a link of the init.ora file from the $ORACLE_HOME/dbs directory to the admin/pfile directory. This ensures the Oracle default configuration is intact, while allowing you to benefit from the OFA structure. On Windows NT platforms, you will have to either specify the full pathname to the init.ora file when starting the database and create an OFA- compliant structure or store the init.ora files in the default $ORACLE_HOME/database directory to keep the default Oracle configuration intact. |
Page 98
When managing multiple databases on one database server, a file-naming convention is important. The OFA standard gives the following rule for naming database files:
OFA Rule 5: Name Oracle database files using the following patterns: /pm/q/d/control.ctl _ control files /pm/q/d/redon.log _ redo log files /pm/q/d/tn.dbf _ data files where: 1 pm is a mount-point name 1 q is a string denoting the separation of Oracle data from all other files 1 d is the db_name of the database 1 n is a distinguishing key that is fixed-length for a given file type 1 t is an Oracle tablespace name
Never store any file other than a control, redo log, or data file associated with a database d in /pm/q/d.
Deviation from this standard depends on your personal preference, but the naming convention ideas should not be ignored. Use a meaningful filename extension, include the tablespace name in datafile names, and keep all datafiles in their own exclusive directories.
A template for an alternative naming standard that keeps the original naming conventions could be tn_SID_n.ext, where tn is an abbreviation for the tablespace the datafile is for, SID is the database the datafile belongs to, and n is the datafile number.
Try to keep the tablespace abbreviation brief and, if possible, keep it a set number of letters. This will produce uniform reports. Also, the number portion for redo log files should indicate both the log group and memberusing a combination of numbers and characters, such as 01a (first log group, first member) and 02c (second log group, third member), works well. Names using the alternative notation are shown in Table 7.2.
Table 7.2 Database File Examples
File Name | Explanation |
syst_PROD_01.dbf | First SYSTEM tablespace datafile for the PROD database |
ctrl_TEST_02.ctl | Second controlfile for the TEST database |
redo_PPRD_01a.log | First member of first redo log group for database PPRD |
redo_PPRD_02c.log | Third member of second redo log group for database PPRD |
data_PROD_02.dbf | Second data tablespace datafile for the PROD database |
initTEST.ora | Initialization parameter file for the TEST database |