Read-Only Oracle Home

Since Oracle 18 (with some restrictions) it’s possible to set the Oracle software installation directory <ORACLE_HOME> into read only.  And with Version 21 this will be the default. So it’s time to get used with it – not with version 18c of course but with 19c and the patch set from october 2020 (19.9).

There might be some missunderstanding as read only is not hundered percent accurate naming. It would be better to call it software only as the oracle kernel and other processes do no longer write logs, traces or other files into the ORACLE_HOME and subdirectories. But it’s still possible to write or change files or add symbolic links.

How can we change the installation?

You should make all changes before you create the first database with that ORACLE_HOME. Best immediately after installing the software.

This is the command and output:

[oracle@mccartney dbhome_1]$ $ORACLE_HOME/bin/roohctl -enable
Enabling Read-Only Oracle home.
Update orabasetab file to enable Read-Only Oracle home.
Orabasetab file has been updated successfully.
Create bootstrap directories for Read-Only Oracle home.
Bootstrap directories have been created successfully.
Bootstrap files have been processed successfully.
Read-Only Oracle home has been enabled successfully.
Check the log file /u01/app/oracle/cfgtoollogs/roohctl/roohctl-210108AM103914.log for more details.

Now the change has been done and there are new directories in <ORACLE_BASE>: better to say: there has been  new directory structure named <ORACLE_BASE_HOME> created. This is the command and coreesponding output:

[oracle@mccartney dbhome_1]$ $ORACLE_HOME/bin/orabasehome
/u01/app/oracle/homes/OraDB19Home1

[oracle@mccartney dbhome_1]$ tree /u01/app/oracle/homes/OraDB19Home1
/u01/app/oracle/homes/OraDB19Home1
├── assistants
│   └── dbca
│       └── templates
├── dbs
├── install
├── network
│   ├── admin
│   ├── log
│   └── trace
└── rdbms
    ├── audit
    └── log

12 directories, 0 files

What is the advantage of a read only Oracle Home?

First of all it’s of course easier to maintain multiple Oracle Homes as network files or spfiles are now stored in a location which is independant of the oracle software installation.

Unfortunately all files are still stored with an association to the software installation (e.,g. OraDB19Home1). With every new installation like for out-of-place patchnig the files must be moved or renamed. This behaviour is a bit cumbersome in my eyes.

An other idea is to use one software installation with multiple servers. This might not be the optimal solution from the standpoint of high availability but for test and development environments that might be sufficient.

In the following example I created multiple virtual machines with one single software installation:

Installation Server 1

Server one (mccartney) will be installed as usual. Except that the directory /u01/app/oracle/product is an NFS mount.

The installation will be done using a Golden Image with Version 19.9. The first step is to unpack that image into the target directory:

[oracle@mccartney ~] mkdir -p /u01/app/oracle/product/19.0/dbhome_1
[oracle@mccartney ~] cd /u01/app/oracle/product/19.0/dbhome_1
[oracle@mccartney dbhome_1]$ unzip /mnt/oracle/db/19/Goldimage/db_home_2021-01-06_04-42-47PM.zip
...

[oracle@mccartney dbhome_1]$ ${ORACLE_HOME}/runInstaller -silent \
-responseFile ${ORACLE_HOME}/install/response/db_install.rsp \
oracle.install.option=INSTALL_DB_SWONLY \
UNIX_GROUP_NAME=oinstall \
INVENTORY_LOCATION=/u01/app/oraInventory \
ORACLE_BASE=/u01/app/oracle \
oracle.install.db.InstallEdition=EE \
oracle.install.db.OSDBA_GROUP=dba \
oracle.install.db.OSOPER_GROUP=oper \
oracle.install.db.OSBACKUPDBA_GROUP=dba \
oracle.install.db.OSDGDBA_GROUP=dba \
oracle.install.db.OSKMDBA_GROUP=dba \
oracle.install.db.OSRACDBA_GROUP=dba 
...

[oracle@mccartney dbhome_1]$ sudo su -

[root@mccartney ~]# /u01/app/oraInventory/orainstRoot.sh
...
[root@mccartney ~]# /u01/app/oracle/product/19.0/dbhome_1/root.sh
...

… done. The software has been installed successfully on the first server. BTW: the usage of clone.pl for the installation is no longer supported with 19c. Instead we need to use runInstaller instead.

It’s time to activate the Read Only Oracle-Home:

 [oracle@mccartney dbhome_1]$ $ORACLE_HOME/bin/roohctl -enable
...

With the successful installation we are no able to “install” or better to say “activate” the software on the other servers. The requirement is to use the same NFS device and mount it accordingly on the other servers. Now the software is available and unzip or installation is not necessary. We only need to attach the software to make it available for the installer.

[oracle@lennon ~]$ cd /u01/app/oracle/product/19.0/dbhome_1/oui/bin
[oracle@lennon bin]$ ./attachHome.sh
Starting Oracle Universal Installer...

Checking swap space: must be greater than 500 MB.   Actual 16379 MB    Passed
The inventory pointer is located at /etc/oraInst.loc
You can find the log of this install session at:
 /u01/app/oraInventory/logs/AttachHome2021-01-07_02-07-00PM.log
Please execute the '/u01/app/oraInventory/orainstRoot.sh' script at the end of the session.
'AttachHome' was successful.

[oracle@lennon bin]$ sudo su -

[root@lennon ~]# /u01/app/oraInventory/orainstRoot.sh
...
[root@lennon ~]# /u01/app/oracle/product/19.0/dbhome_1/root.sh
...
exit

[oracle@lennon bin]$ cd $ORACLE_HOME/bin
[oracle@lennon bin]$./roohctl -enable
...

This installation can be done in seconds.

There is only on open issue: like in the example I had to run both root.sh as well as roohctl -enable. Im not hundered percent certain if this has any implications on a running database using that same Oracle Home because it touches every database server.

Instead of using native Read-Only directories which is not supported by Oracle (see also the blog from Markus Flechner: “Oracle 18c/19c: Running a “read-only-Oracle-home” on a read-only-filesystem”) this approach should be supported by Oracle because the Oracle 19c documentation says explicitly. “Simplifies patching and mass rollout as only one image needs to be updated to distribute a patch to many servers.”

The creation of the database is not different to former installations so I won’t describe it here.

If it could ease your installations please give it a trial and let me know about your experiences.