Running Systems

Imagine Omniback 4.x to Omniback 5.5 upgrade on HP-UX. Imagine you assume all existing backup procedure (and you were told there is license only for disk agent) is based on filesystem backup. Assume you know there’s Oracle installed on this server, but no relevant agent (again, filesystem only, no DB agents…)

You are cautious. You move the current /opt/omni to /opt/omni.old directory. You hash the line containing the relevant entry in /etc/inetd.conf. You are prepared.

You install the newer version by running the installer script with the flag -install da, so you would install only Disk Agent (after all, this is nothing but a client to this whole backup procedure).

You check everything, and it all seems to work correctly as far as you care or know. Suddenly, someone notices that Oracle Listener (TNS) does not listen anymore. Trying to bring it back up results in a message which seems like this:

/usr/lib/pa20_64/dld.sl: Unable to find library ‘libobk.sl’.

It doesn’t look good. You are in a little crisis. Restart to the Oracle Engine itself results in a shutdown, but it never starts back again. It doesn’t look good.

It appears that there was an Oracle Agent for Omniback installed there previously, and that you removed it uncleanly by your Disk-Agent-Only upgrade.

The solution could have been to install the Oracle Agent. It can be also related to recreating the required links, say from /opt/omni.old/lib/libbo2oracle8_64.sl or from $ORACLE_HOME/lib64/libobk.sl.backup (if there were any…) to $ORACLE_HOME/lib64/libobk.sl, the first is based on the older Omniback, the later is based on the assumption a backup was made.

The quickest solution was to install the newer agent, with the Oracle8i agent (called “oracle8”) and link: “ln -s /opt/omni/lib/libob2oracle8_64.sl ~oracle/lib64/libobk.sl” (assuming we’re running Oracle 8i on 64bit HP-UX PA-RISC).