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:
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:
Since 10g, Oracle proposes to use the following naming conventio
/u01/app/oracle/product/11.2.0
Oracle software sub tree for release 11g products (11.2)
/u01/app/oracle/product/11.2.0/db*
Oracle home directories for Oracle Database 11g (11.2)
/u01/app/oracle/product/11.2.0/grid*
Oracle home directory for Oracle grid infrastructure 11gR2 installation on a standalone server only with the user oracle (OracleRestart)
/u01/app/oracle/product/10.2.0/agent10g
Oracle home directory for the Oracle Agent
/u01/app/oracle/product/11.1.0/agent11g
/u01/app/oracle/product/11.2.0/agent10g
/u01/app/oracle/agent/12.1.0.2
With Oracle Release 12c the new patching-concept of Release Updates (RU) and Release Update Revisions (RUR) was introduced. In addition the major release-numbering changed to include the year of the release (e.g. 18c or 18.5.0.0.0 for 2018).
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
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.
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:
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:
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:
+U01
U01FG1
U01FG1
Database files
Control copy 1
Redo Log Files Member 1
U01FG1
Database files
Control copy 1
Redo Log Files Member 1
U01FG2
U01FG2
Database files
Control copy 1
Redo Log Files Member 1
U01FG2
Database files
Control copy 1
Redo Log Files Member 1
+U02
U02FG1
U02FG1
Control copy 2
Redo Log Files Member 2
U02FG2
U02FG2
Control copy 2Redo Log Files Member 2
+U90
U90FG1
U90FG1
Flash Recovery Area
+CRS
CRDFG1
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)
Last updated