| Oracle® Database Installation Guide 11g Release 2 (11.2) for Linux Part Number E24321-07 |
|
|
PDF · Mobi · ePub |
| Oracle® Database Installation Guide 11g Release 2 (11.2) for Linux Part Number E24321-07 |
|
|
PDF · Mobi · ePub |
This appendix describes the Optimal Flexible Architecture (OFA) standard. This standard is a set of configuration guidelines created to ensure well organized Oracle installations that are easier to maintain. It includes information about the following topics:
The Optimal Flexible Architecture standard helps you to organize database software and configure databases to allow multiple databases, of different versions, owned by different users to coexist. Optimal Flexible Architecture assists in identification of ORACLE_BASE with its Automatic Diagnostic Repository (ADR) diagnostic data to properly collect incidents.
All Oracle components on the installation media are compliant with Optimal Flexible Architecture. Oracle Universal Installer places Oracle Database components in directory locations, assigning the default permissions that follow Optimal Flexible Architecture guidelines.
Oracle recommends that you use Optimal Flexible Architecture, especially if the database is huge, or if you plan to have multiple databases.
When you install Oracle database, you are installing a large application that your computer can support. Using multiple Oracle homes and Optimal Flexible Architecture provides many advantages when administering large databases. The following advantages are important:
Structured organization of directories and files, and consistent naming for database files simplify database administration.
Distribution of I/O across multiple disks prevents performance bottlenecks caused by multiple read or write commands issued simultaneously to a single drive.
Distribution of applications across multiple disks safeguards against database failures.
Login home directories are not at risk when database administrators add, move, or delete Oracle home directories.
Multiple databases, of different versions, owned by different users can coexist concurrently.
Software upgrades can be tested in an Oracle home in a separate directory from the Oracle home where your production database is located.
This section describes the naming strategy recommended by the Optimal Flexible Architecture standard. It contains the following sections:
The following sections describe the conventions for mount points:
To fully implement the Optimal Flexible Architecture recommendations for a database stored on file systems that are not striped or mirrored, you require at least three file systems located on separate physical devices.
Name all file system 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.
The following sections describe the naming conventions for directories that are compliant with the Optimal Flexible Architecture standard:
Note:
Ensure that the paths you select for Oracle software, such as the Oracle home path and the Oracle base path, use only ASCII characters. Because installation owner names are used by default for some paths, this ASCII character restriction applies to user names, file names, and directory names.The Oracle Base directory is the top level directory that you can use to install the various Oracle software products. You can use the same Oracle base directory for multiple installations. If different operating system users install Oracle software on the same system, then each user must create a separate Oracle base directory.
Name Oracle base directories using the syntax /pm/s/u. Table D-1 describes the variables used in this syntax.
Table D-1 Syntax for Naming Oracle Base Directories
| Variable | Description |
|---|---|
|
|
A mount point name |
|
|
A standard directory name |
|
|
The name of the owner of the directory (the user running Oracle Universal Installer) |
For example, /u01/app/oracle is an Oracle base directory created by the oracle user and /u01/app/applmgr is an Oracle base directory created by the applmgr user.
Placing Oracle base directories at the same level in the UNIX file system is advantageous because it enables you to refer to the collection of Oracle base directories on different mount points using a single pattern matching string, /*/app/*.
If each disk drive contains database files from one application and there are enough drives for each database to prevent I/O bottlenecks, use the syntax /h/q/d for naming mount points. Table D-2 describes the variables used in this syntax.
Table D-2 Syntax for Naming Mount Points for Very Large Databases
| Variable | Description |
|---|---|
|
|
Oracle base directory |
|
|
A string denoting that Oracle data is stored in this directory, for example, |
|
|
The value of the initialization parameter |
For example, to allocate two drives exclusively for the test database, name the mount points /u01/app/oracle/oradata/test and /u02/app/oracle/oradata/test.
Refer to explicit path names only in files designed specifically to store them, such as the password file, /etc/passwd, and the Oracle oratab file. Refer to group memberships only in the /etc/group file.
To help fulfill the Optimal Flexible Architecture requirement of simultaneously running multiple versions of Oracle software, install the software in a directory matching the pattern /pm/s/u/product/v/type_[n].
Table D-3 describes the variables used in this syntax.
Table D-3 Syntax for Naming Oracle Home Directories
| Variable | Description |
|---|---|
|
|
A mount point name |
|
|
A standard directory name |
|
|
The name of the owner of the directory |
|
|
The version of the software |
|
|
The type of installation, for example Database ( |
|
|
An optional counter, which enables you to install the same product more than once in the same Oracle base directory |
For example:
/u01/app/oracle/product/11.2.0/dbhome_1 indicates the Oracle home directory for the first installation of Oracle Database on this system.
The ORACLE_HOME environment variable is set to the Oracle home directory.
To facilitate the organization of administrative data, Oracle recommends that you store database-specific administration files in subdirectories matching the pattern /h/admin/d/a/, where h is the Oracle base directory, d is the database name (DB_NAME), and a is a subdirectory for specific types of database administration files. Table D-4 describes the database administration file subdirectories.
Table D-4 Subdirectories for Database Administration Files
| Subdirectory | Description |
|---|---|
|
|
Archived redo log files |
|
|
Audit files (Set the |
|
|
Contains the data pump file |
|
|
Default directory for data pump operations. Scripts used to create the database |
|
|
Database export files |
|
|
Files recording the status and history of the database |
|
|
Instance parameter files |
|
|
Ad hoc SQL scripts |
For example, /u01/app/oracle/admin/orcl/scripts/ is the scripts subdirectory associated with the database named orcl.
In Oracle Database 11g, Automatic Diagnostic Repository (ADR) directories replace the bdump, cdump, and udump directories. The ADR diagnostic data goes into the /h/diag/rdbms/d/i/ directory.
where
h is Oracle Base
d is the database name
i is the instance name.
The ADR home has the trace, alert, and incident sub-directories. Table D-5 describes the ADR directories.
Table D-5 Locations for Diagnostic Traces
| Diagnostic Data | 10g Location | 11g Location |
|---|---|---|
|
Foreground Process traces |
|
|
|
Background Process traces |
|
|
|
Alert Log Data |
|
|
|
Core Dump |
|
|
|
Incident Dumps |
|
|
The following table lists the recommended file naming conventions for database files:
|
Note: Oracle Managed Files (OMF) and files stored in Oracle Automatic Storage Management disk groups use different naming conventions. For more information about these naming conventions, refer to the Oracle Database Administrator's Guide. |
| File Type | File Naming Convention |
|---|---|
| Control files | /h/q/d/control.ctl |
| Redo log files | /h/q/d/redon.log |
| Data files | /h/q/d/tn.dbf |
The following table describes this syntax:
| Variable | Description |
|---|---|
h |
Oracle base directory |
q |
A string (typically oradata) distinguishing Oracle data from all other files |
d |
The value of the DB_NAME initialization parameter (typically, the same as the instance SID for single-instance databases) |
t |
An Oracle tablespace name |
n |
A two-digit string |
Note:
Do not store files other than control files, redo log files, or data files associated with database
d in the path /h/q/d.Using this convention, it is easy to determine the database to which the /u01/app/oracle/oradata/sab/system01.dbf file belongs.
Separate groups of segments with different lifespans, I/O request demands, and backup frequencies across different tablespaces.
Table D-6 describes the special tablespaces that the Database Configuration Assistant creates for each Oracle database. If you manually create a database, you must create the required tablespaces. These tablespaces are in addition to those required for application segments.
See Also:
Oracle Database Administrator's Guide for information about creating databases manually| Tablespace | Required | Description |
|---|---|---|
|
|
No |
The |
|
|
Yes |
Auxiliary tablespace to the |
|
|
Yes |
Data dictionary segments |
|
|
Yes |
Temporary segments |
|
|
Yes |
Used by Oracle to store undo information |
|
|
No |
Miscellaneous user segments |
Creating these special tablespaces is effective because data dictionary segments are never dropped, and no other segments that can be dropped are allowed in the SYSTEM tablespace.
See Also:
"Reviewing Tablespaces and Data Files, Redo Log Files, and Control Files" for information about redo log, and control filesTable D-7 describes the syntax used for identifying classes of files.
Table D-7 Directory Structure Syntax for Identifying Classes of Files
| Directory Structure Syntax | Description |
|---|---|
|
|
User data directories |
|
|
User home directories |
|
|
User application software directories |
|
|
Oracle applications software subtrees |
|
|
Oracle software subtrees |
|
|
Oracle software subtree for release 11g products |
|
|
Oracle home directories for Oracle Database 11g |
|
|
Oracle home directory for Oracle Grid Infrastructure 11g for a standalone server, for user |
|
|
|
|
|
|
|
|
Oracle data directories |
|
|
|
|
|
|
Table D-8 shows a hierarchical file mapping of a sample Optimal Flexible Architecture-compliant installation with two Oracle home directories and two databases. The database files are distributed across three mount points, /u02, /u03, and /u04.
Note:
Oracle recommends that you use Oracle ASM to provide greater redundancy and throughput.Table D-8 Hierarchical File Mapping for an Optimal Flexible Architecture Installation
| Directory | Description |
|---|---|
|
|
Root directory |
|
|
User data mount point 1 |
|
|
Subtree for application software |
|
|
Oracle Base directory |
|
|
Subtree for database administration files |
|
|
Subtree for support log files |
|
|
|
|
|
|
|
|
Online documentation |
|
|
Subtree for recovery files |
|
|
Recovery files for db_name1 database |
|
|
Recovery files for db_name2 database |
|
|
Oracle data directory |
|
|
Distribution files |
|
|
Oracle home directory for Oracle Database, for user |
|
|
Oracle home directory for Oracle Grid Infrastructure for a standalone server, for user |
|
|
Oracle base directory for user |
|
|
Oracle base directory for user |
|
 Copyright © 2011, 2012, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|