OFA Naming guidelines

As OFA should be a "flexible" architecture we provide only guidelines and best practices concerning the naming convention of the several database components.

Why the Change from /u00 to /u01 into Oracle base

Oracle still several years per default always install the ORACLE_HOME directories under /u01. Additionally, today Oracle has now many Engineered Systems (ODA/Exadata/etc.) where the software is always installed under /u01.

To have identical scripts into DMK for our installed system and for the Oracle Engineered systems we decided to change the based directory of Oracle from /u00 to /u01

ORACLE_HOME directories

The ORACLE_HOME directory naming convention changed during the last years. Because of the introduction of new Oracle products (Enterprise Manager, Agent software, Grid Infrastructure) the ORACLE_HOME directory had to be adapted in order to be easily identified. In addition, some solutions had to be introduced to allow the collaboration of several instances having the same Oracle release but different patch levels (11.2.0.3 and 11.2.0.4 for instance).

In the old OFA releases the ORACLE_HOMEs were created as below:

/u01/app/oracle/product/11.2.0

This directory contains the RDBMS software release: 11.2.0. However, this structure has several drawbacks. One of the main issues is that we cannot identify the patch level. If this installation is used by several databases, delivered by different software providers we have no chance to patch one database with 11.2.0.4 and the other one with 9.2.0.5. One can argue that as soon as a patch is available it should be installed, however the best practices coming from the ITIL framework show that the validation of a new patch can take more time than expected. In this case using a four digit naming would be the only solution:

/u01/app/oracle/product/11.2.0.3
/u01/app/oracle/product/11.2.0.4

Since 10g, Oracle proposes to use the following naming conventio

ORACLE_HOME (11g and newer for non-CDB and CDB)

Note that the historical structure as shown in 2.2. has a couple of drawbacks:

It does not allow identifying the Release Update which has been installed in newer releases.
It does not allow for naming the ORACLE_HOME in the inventory with the same name as we have in the directory.

The suggested strategy below follows an approach from Ludovico Caldara, who published this on http://www.ludovicocaldara.net/dba/oh-mgmt-5/

The idea is to have the same name of the ORACLE_HOME in the inventory as we have in the directory itself. E.g. the inventory-name is 12_1_0_2_BP170418_v0 and the associated ORACLE_HOME is

/u01/app/oracle/product/12_1_0_2_BP170418_v0

I.e. the name in the inventory should be the same as the output of

$ basename $ORACLE_HOME

REMARKS:

We do use _ (underscore) instead of . (dot) In the release-name, because dots are not allowed in the Oracle inventory name.
We name the OH in the inventory equal to the name in the directory to allow for automatic cloning from a master OH-copy through scripts.

There is no trailing db_1 or db_2 anymore. Possible names are e.g. 12_1_0_2_170418_v0 --> Bundle Patch 12.1.0.2.170418 without further one-off patches

12_1_0_2_170418_v1 --> Bundle Patch 12.1.0.2.170418 with one or more additional one-off patches

12_2_0_1_BASE_v0 --> 12.2.0.1-Base-Release without further patches 18_3_0_0_RU180717_v0 --> Release Update 18.3.0.0.180717 without further patches

If there is e.g. Java installed, then the OH may optionally be named

18_3_0_0_RU180717_JVM_v0 --> Release Update 18.3.0.0.180717 with Oracle JavaVM Component without further patches.

The directory structure of ORACLE_HOMEs for CDBs is the same as for non-CDBs. If you want to patch just a single PDB to a new patch-level (without touching other PDBs), then just unplug the PDB and plug it into another CDB running in a different ORACLE_HOME. As mentioned, the ORACLE_HOME- naming is not different than on a non-CDB. E.g. unplug the PDB from a CDB running on OH 18_3_0_0_RU180717_v0 and plug it in to a CBD running on OH 18_5_0_0_RU190115_v0.

ORACLE_HOME on ODA

We follow the given ORACLE_HOME-naming conventions as provided by the ODA utilities. E.g.

[root] % odacli create-dbhome -v 12.1.0.2

on an ODA-Light creates an ORACLE_HOME automatically in e.g.

/u01/app/oracle/product/12.1.0.2/dbhome_1

GRID_HOME

For the grid home we use the default Oracle Rule to are compliant with the Oracle Engineered Systems (ODA/Exadata)

/u01/app/11.2.0.1/grid: Grid home directories for Grid Infrastructures 11.2.0.1.0

/u01/app/11.2.0.4/grid: Grid home directories for Grid Infrastructures 11.2.0.4.0

Database files

As for the ORACLE_HOME directories, the purpose of this document is not to force any strict naming convention but only to propose best practices which have been validated by the experienced dbi services consultants.

Database File names

As a best practice we should keep the name of the database (db_name) in the database file names. Indeed, as soon as some offline database backups have been performed directly to a media manager, it will be easier to identify to which database those backups’ files belong:

system${db_name}.dbf
For instance: systemDB1.dbf

Database File extension

All database files should have ".dbf" as suffix. In this case they cannot be mixed up with operating system files. For instance:

redog1m1${db_name}.dbf instead of redog1m1.log (.log is a log file, not a redo log file) temp01${db_name}.dbf instead of temp01.tmp (.tmp is a temporary file on O.S level) control01${db_name}.dbf instead of control01.ctl (.ctl is an SQL loader control file) Alternatively setup Oracle with Oracle Managed Files (OMF), i.e. use the DB-parameter db_create_file_dest.

Redo log files

As a best practice, dbi services advices to use the following convention to name the redo log files: redogGmM.dbf where G is the Redo Log Group Number and M is the Member Number.

Alternatively setup Oracle with Oracle Managed Files (OMF), i.e. use the DB-parameters db_create_online_log_dest_1, db_create_online_log_dest_2, etc.

spfile

The spfile has usually another file extension (.ora) it makes sense to keep this well-know and widely used standard:

spfile${db_name}.ora
For the database instance DB1: spfileDB1.ora

Mount points

It is important to consider that each mount point represents a separate filesystem. In some cases, it should even be a filesystem stored of different disks (i.e filesystems for different redo log members). Below a list of components which should be separated over different physical disks:

Strongly advised:

Oracle software / Oracle databases
Database admin files / Oracle databases
Redo log members of a same group
Oracle database / Oracle backup files (included Flash recovery Area)

Advised:

Data and Indexes tablespaces (depending on you disk layout and architecture)

The usual naming convention for OFA mount points is /u[0-1][0-1] on UNIX. On Windows each mount point is a drive identified by a letter as D: E:.

dbi services advices to use the mount points named according to this pattern /u9[0 -1] to store the following components :

backup directories
archive locations
datapump directories
flashback recovery area

Using /u9[0-1] directories allows to have a clear separation from the database files usually stored under the following mount points (/u01, /u02, /u03, ...). If the database currently uses /u01 and /u02, the next filesystem available is /u03. /u03 has not been reserved by the backup components (because it is stored under /u9[0-1]).

Automatic Storage Management

Automatic Storage Management is another key feature requiring adaptations in the OFA standards. ASM is only used to store Oracle database components like database file, RMAN backup files, aso ... but no Oracle software. Moreover, ASM is automatically managed by Oracle which means that the administrator has almost no control over the directory structure and naming convention inside ASM (ASM is combined with Oracle Managed Files – OMF providing an automatic naming strategy).

This document only provides advices concerning the ASM disk groups, failure groups and disks naming convention. It also presents how many ASM disk groups should be created:

Disk Group

Failure Group

Disks

Content

+U01

U01FG1

Database files

Control copy 1

Redo Log Files Member 1

U01FG1

Database files

Control copy 1

Redo Log Files Member 1

U01FG2

Database files

Control copy 1

Redo Log Files Member 1

U01FG2

Database files

Control copy 1

Redo Log Files Member 1

+U02

U02FG1

Control copy 2

Redo Log Files Member 2

U02FG2

Control copy 2Redo Log Files Member 2

+U90

U90FG1

Flash Recovery Area

+CRS

CRDFG1

OCR and Voting disks ( only with 11.2)

CRSFG2

CRDFG2

OCR and Voting disks ( only with 11.2)

CRSFG3

CRDFG3

OCR and Voting disks ( only with 11.2)

PreviousIntroduction NextOFA directory structure

Last updated 1 year ago