It is the time of year to apply critical patches. This time round we have some databases at version 19c. We tend to install a new oracle home for each patch, as we find this helps us manage the migration. It also reduces downtime, especially if you have not yet taken advantage of pluggable databases as we haven’t.
I notice from the documentation that there is an
applyRU parameter that can be passed
to the installer to apply the patch. The documentation is quite poor though because
it doesn’t specify what should be passed after that. Even more annoying is that if the
patch attempt fails, it will leave the home in an intermediate state and it will have
to be deleted and recreated.
After much trial and error with a combo patch I discovered the following procedure works:
- Unzip the installer zip file into the new
OPatchby unzipping the patch into the
- Unzip the combo patch somewhere convenient. I chose
The combo patch contains two patch directories, database roll-up and Java. It seems they need to be applied as follows:
ORACLE_HOME is unset. I prefer to log out and in again and don’t set an environment,
I like to make sure
PATH don’t contain anything under an oracle home in
case it causes problems.
applyRU parameter specifies the database release update patch, and
applyOneOff specifies the java patch. This
is also a release update, but only one release update can be specified in the
applyRU parameter. Any number of
applyOneOff patches can be supplied, they are comma delimited.
It takes a few minutes to run each patch in, but it does work! Then the installer window appears. I picked the following options:
- Set up software only
- Single instance database installation
- Enterprise Edition
- Oracle base: I chose
dbagroup for all groups apart from osoper which was left blank.
- Left automatically run configuration scripts unticked.
- Ticked Ignore all on the prequisite checks (We have a smaller swap than Oracle would like but we have masses of RAM.
- On the summary page I chose to save the response file.
- I ran the
- The registration was successful! I clicked close.
Armed with the response file generated above, I can use the following to run the installer in silent mode using the response file I generated above:
We still need to run
root.sh afterwards, as prompted by the standard output. Note that the behaviour is slightly different
coraenv are copied to
/usr/local/bin, where if it is run interactively and the defaults
taken these files are not copied to
Switching Options with chopt
Once the home is installed, I make a habit of switching off cost options we haven’t licensed to prevent accidental usage. Some Oracle scripts check and use the options if they are switched on, so I think it is worth doing. We don’t use any options, so we do:
It is general good practice to check whether something needs doing before doing it, especially when
using languages like Ansible. Looking at the
Makefile called by the
chopt script I can see
that it manges the
libknlopt.a file. This is an archive file, which is kind of like a
zip file, but it is controlled using the Unix
ar command to list, add and remove files from the
ar commands are similar to
tar commands, so
t lists the contents of the archive.
The options supported by
chopt end up with the following objects being included in the archive:
dmwdm.oOracle Advanced Analytics is on.
dmndm.oOracle Advanced Analytics is off.
xsyeolap.oOracle OLAP is on.
xsnoolap.oOracle OLAP is off.
kkpoban.oOracle Partitioning is on.
ksnkkpo.oOracle Partitioning is off.
kecwr.oOracle Real Application Testing is on.
kecnr.oOracle Real Application Testing is off.
There are other options in here such as RAC which is set during installation (
kecwr.o is on,
kecnr.o is off)
and unified auditing which is controlled by another script (
kzaiang.o is on,
kzanang.o is off)
Armed with this information we can tell Ansible whether it needs to switch options on or off.