# 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 | Directory | Purpose | | --------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------- | | /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 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 GroupFailure GroupDisksContent
+U01U01FG1U01FG1

Database files

Control copy 1

Redo Log Files Member 1

U01FG1

Database files

Control copy 1

Redo Log Files Member 1

U01FG2U01FG2

Database files

Control copy 1

Redo Log Files Member 1

U01FG2

Database files

Control copy 1

Redo Log Files Member 1

+U02U02FG1U02FG1

Control copy 2

Redo Log Files Member 2

U02FG2U02FG2Control copy 2Redo Log Files Member 2
+U90U90FG1U90FG1Flash Recovery Area
+CRSCRDFG1CRDFG1OCR and Voting disks ( only with 11.2)
CRSFG2CRDFG2OCR and Voting disks ( only with 11.2)
CRSFG3CRDFG3OCR and Voting disks ( only with 11.2)