OK, I really do not know what other title I should use for this post.
I have developed and presented a few times my personal approach to Oracle Home provisioning and patching. You can read more in this series.
With this approach:
- I install the software (either GI or RDBMS) with the option SW_ONLY once
- I patch it to the last version
- I create a golden image that I evolve for the rest of the release lifecycle
When I need to install it, I just unzip the golden image and attach it to the Central Inventory.
I have discovered quite longtime ago that, every time I was attaching the home to the inventory, the binaries were relinked with rac_off, disregarding the fact that the home that I zipped actually had RAC enabled. This is quite annoying at my work at CERN, as all our databases are RAC.
So my solution to the problem is to detect if the server is on a cluster, and relink on the fly:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
### EARLIER, IN THE ENVIRONMENT SCRIPTS if [ -f /etc/oracle/olr.loc ] ; then export CRS_EXISTS=1 else export CRS_EXISTS=0 fi ### LATER, AFTER ATTACHING THE ORACLE_HOME: pushd $ORACLE_HOME/rdbms/lib if [ $CRS_EXISTS -eq 1 ] ; then make -f ins_rdbms.mk rac_on else make -f ins_rdbms.mk rac_off fi make -f ins_rdbms.mk ioracle |
This is a simplified snippet of my actual code, but it gives the idea.
What causes the relink with rac_off?
I have discovered recently that the steps used by the runInstaller process to attach the Oracle Home are described in this file:
|
1 |
$ORACLE_HOME/inventory/make/makeorder.xml |
and in my case, for all my golden images, it contains:
|
1 2 3 4 5 6 7 8 9 10 11 |
<ohmd:MAKE MAKEPATH="/usr/bin/make" FILENAME="rdbms/lib/ins_rdbms.mk" > <ohmd:TARGET ACTIONTYPE="INSTALL" TARGETNAME="rac_off" > <ohmd:INPUT_LIST> <ohmd:INPUT VAL="ORACLE_HOME=%ORACLE_HOME%"/> </ohmd:INPUT_LIST> <ohmd:COMP_LIST> <ohmd:COMP NAME="oracle.rdbms" VERSION="18.0.0.0.0"/> </ohmd:COMP_LIST> </ohmd:TARGET> </ohmd:MAKE> |
So, it does not matter how I prepare my images: unless I change this file and put rac_on, the runInstaller keeps relinking with rac_off.
I have thought about changing the file, but then realized that I prefer to check and recompile at runtime, so I can reuse my images also for standalone servers (in case we need them).
Just to avoid surprises, it is convenient to check if a ORACLE_HOME is linked with RAC with this small function:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
$ type isRACoh isRACoh is a function isRACoh () { OH2CHECK=${1:-$ORACLE_HOME}; ar -t $OH2CHECK/rdbms/lib/libknlopt.a | grep --color=auto kcsm.o > /dev/null; if [ $? -eq 0 ]; then echo "Enabled"; else echo "Disabled"; false; fi } |
This is true especially for Grid Infrastructure golden images, as they have the very same behavior of RDBMS homes, with the exception that they might break out-of-place patching if RAC is not enabled: the second ASM instance will not mount because the first will be exclusively mounted without the RAC option.
HTH.
—
Ludovico
Latest posts by Ludovico (see all)
- New views in Oracle Data Guard 23c - January 3, 2024
- New in Data Guard 21c and 23c: Automatic preparation of the primary - December 22, 2023
- Does FLASHBACK QUERY work across incarnations or after a Data Guard failover? - December 13, 2023
Thanks for writing this post.
Not exactly the same, but I have a similar issue with dnfs.
It’s in my $ORACLE_HOME/inventory/make/makeorder.xml as “dnfs_on”, but after the SW_ONLY install, the file expected is not present in $ORACLE_HOME/rdbms/lib/odm
I’ll probably also have to run my own relink/make during provisioning.