Infrastructure at your Service

Clemens Bleile

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 dnfs_on

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

mv libodm11.so_stub
ln –s

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

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 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 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/ which generates a file $ORACLE_HOME/install/current_makeorder.xml. At the beginning of 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/ $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:


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


  • Ivor Oorloff says:

    As a matter of interest, we have just had an issue where DNFS was getting turned off whenever a “relink all” was done, even though it had been turned on. I found the only solution seemed to be to edit the $ORACLE_HOME/inventory/make/makeorder.xml which had dnfs_off from the original installation and change it to “dnfs_on” and then the relink all preserved the dnfs properly. Our binaries had been cloned and then had the dnfs activated with the make -f dnfs_on, so maybe this caused the problem.

    • Actually dnfs is special. dnfs is not checked in
      because there is no specific object (like xsnoolap.o) in a library. When doing
      make -f dnfs_on
      then $ORACLE_HOME/lib/ is copied to $ORACLE_HOME/lib/odm/
      make -f dnfs_off
      the file $ORACLE_HOME/lib/odm/ is just removed.
      Hence the setting of dnfs is always preserved, because the relink all does not modify
      However, that basically means that the commands
      $ $ORACLE_HOME/perl/bin/perl $ORACLE_HOME/install/ $ORACLE_HOME $ORACLE_HOME/inventory/make/makeorder.xml > /tmp/currentmakeorder.xml
      $ grep TARGETNAME /tmp/currentmakeorder.xml | grep -E “(_on|_off)” | cut -d”\”” -f4
      may not show the current setting of dnfs. It always shows the setting of the installation.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Clemens Bleile
Clemens Bleile

Technology Leader & Principal Consultant