Oracle kernel relink on Linux: Are my options stored persistently?

I recently visited an Oracle presentation about the Oracle-kernel built-in directNFS (dNFS) driver. To use dNFS in the database you have to enable it:


cd $ORACLE_HOME/rdbms/lib
make -f ins_rdbms.mk dnfs_on


REMARK: In versions before 11gR2/12c the following manual steps were necessary:


cd $ORACLE_HOME/lib
mv libodm11.so libodm11.so_stub
ln –s libnfsodm11.so libodm11.so


In the context of make-commands, somebody in the audience asked the question how Oracle persistently stores the current link options, so that a future relink won’t undo previous settings. E.g. when relinking without the partitioning option, will another relink include the objects again? As nobody had a good answer, I thought I’ll check that on Linux.

REMARK: Below tests were done on 12.1.0.2.

If options are linked in to the Oracle kernel (e.g. OLAP or Partitioning) is actually stored in the archive $ORACLE_HOME/rdbms/lib/libknlopt.a.

I.e. if I do relink the Oracle kernel without OLAP with the commands


$ cd $ORACLE_HOME/rdbms/lib
$ make -f ins_rdbms.mk olap_off ioracle


I can see the following first steps:


/usr/bin/ar d $ORACLE_HOME/rdbms/lib/libknlopt.a xsyeolap.o
/usr/bin/ar cr $ORACLE_HOME/rdbms/lib/libknlopt.a $ORACLE_HOME/rdbms/lib/xsnoolap.o


The object xsyeolap.o is removed from $ORACLE_HOME/rdbms/lib/libknlopt.a and object $ORACLE_HOME/rdbms/lib/xsnoolap.o added to it. The link command $ORACLE_HOME/bin/orald contains then the following argument:


-lknlopt `if /usr/bin/ar tv $ORACLE_HOME/rdbms/lib/libknlopt.a | grep xsyeolap.o > /dev/null 2>&1 ; then echo "-loraolap12" ; fi`


I.e. if object xsyeolap.o is in $ORACLE_HOME/rdbms/lib/libknlopt.a then the argument -loraolap12 is added to the link command. As xsyeolap.o is no longer in $ORACLE_HOME/rdbms/lib/libknlopt.a (it has been replaced with xsnoolap.o), the current and future link-commands won’t link OLAP into the kernel.

Obviously adding OLAP again will include the xsyeolap.o to the library $ORACLE_HOME/rdbms/lib/libknlopt.a again:


$ make -f ins_rdbms.mk olap_on ioracle
/usr/bin/ar d $ORACLE_HOME/rdbms/lib/libknlopt.a xsnoolap.o
/usr/bin/ar cr $ORACLE_HOME/lib/libknlopt.a $ORACLE_HOME/rdbms/lib/xsyeolap.o
...
$ORACLE_HOME/bin/orald -o $ORACLE_HOME/rdbms/lib/oracle ... -lknlopt `if /usr/bin/ar tv $ORACLE_HOME/rdbms/lib/libknlopt.a | grep xsyeolap.o > /dev/null 2>&1 ; then echo "-loraolap12" ; fi` ...


What happens if the script $ORACLE_HOME/bin/relink with argument “all” is being used?

Actually the relink script uses a perl script $ORACLE_HOME/install/modmakedeps.pl which generates a file $ORACLE_HOME/install/current_makeorder.xml. At the beginning of modmakedeps.pl I can see the following command:


# initial hash populated with options from libknlopt
my %opts_hash = ( 'kcsm.o' => 'rac_off/rac_on',
'kzlilbac.o' => 'lbac_off/lbac_on',
'kzvidv.o' => 'dv_off/dv_on',
'kxmwsd.o' => 'sdo_off/sdo_on',
'xsyeolap.o' => 'olap_off/olap_on',
'kkpoban.o' => 'part_off/part_on',
'dmwdm.o' => 'dm_off/dm_on',
'kecwr.o' => 'rat_off/rat_on',
'ksnkcs.o' => 'rac_on/rac_off',
'kzlnlbac.o' => 'lbac_on/lbac_off',
'kzvndv.o' => 'dv_on/dv_off',
'kxmnsd.o' => 'sdo_on/sdo_off',
'xsnoolap.o' => 'olap_on/olap_off',
'ksnkkpo.o' => 'part_on/part_off',
'dmndm.o' => 'dm_on/dm_off',
'kecnr.o' => 'rat_on/rat_off',
'jox.o' => 'jox_on/jox_off' );


I.e. we have the following 2 lines in there:


'xsyeolap.o' => 'olap_off/olap_on',
'xsnoolap.o' => 'olap_on/olap_off',


What that means is that the script uses the list in %opts_hash to check what the current objects are in $ORACLE_HOME/rdbms/lib/libknlopt.a. Depending on the current objects in the archive it checks the original installation settings $ORACLE_HOME/inventory/make/makeorder.xml and generates a new file with the necessary changes in $ORACLE_HOME/install/current_makeorder.xml. E.g. if xsyeolap.o is in $ORACLE_HOME/rdbms/lib/libknlopt.a, but $ORACLE_HOME/inventory/make/makeorder.xml has olap_off then create a copy of $ORACLE_HOME/inventory/make/makeorder.xml in $ORACLE_HOME/install/current_makeorder.xml with olap_off changed to olap_on. If xsnoolap.o is in the archive but olap_on in $ORACLE_HOME/inventory/make/makeorder.xml then generate $ORACLE_HOME/install/current_makeorder.xml with olap_off. Finally the relink happens using the runInstaller:


$ORACLE_HOME/oui/bin/runInstaller -relink -waitForCompletion -maketargetsxml $ORACLE_HOME/install/current_makeorder.xml -logDir $ORACLE_HOME/install ORACLE_HOME=$ORACLE_HOME


If you want to see what options are currently set in your libknlopt.a you may do the following:


$ $ORACLE_HOME/perl/bin/perl $ORACLE_HOME/install/modmakedeps.pl $ORACLE_HOME $ORACLE_HOME/inventory/make/makeorder.xml > /tmp/currentmakeorder.xml
$ grep TARGETNAME /tmp/currentmakeorder.xml | grep -E "(_on|_off)" | cut -d""" -f4


On my ORACLE_HOME the output of the last command ablove looks as follows:


rat_on
part_on
dm_on
olap_on
sdo_on
rac_off
dnfs_off
ctx_on


In case you want to relink the Oracle kernel with the original installation settings then use


$ relink as_installed


The runinstaller will use the original $ORACLE_HOME/inventory/make/makeorder.xml as the argument for -maketargetsxml then.

So no worries if you have to relink the oracle kernel several times with different options. Previous settings are stored persistently in the archive $ORACLE_HOME/rdbms/lib/libknlopt.a. If you don’t remember what changes you have done and want to go back to the installation settings then use


$ relink as_installed