By Rene Kundersma-Oracle on Jan 14, 2014
In this and future posts I am planning to describe some new
functionality and background of dbnodeupdate.sh starting with Oracle Exadata Database Machine release
126.96.36.199.0. Some of this functionality will be directly available to the operator
via the interface and can actually be used via an argument, however, some of the recent changes are made to make patching even easier, reduce human error and downtime.
You may also find some of the 'new features' described in MOS 1553103.1 'Exadata Database Server Patching using the DB Node Update Utility'
With updates to Exadata 188.8.131.52.0 or later some packages on the database server will become obsolete. When updating a db server the dbnodeupdate.sh script will mention an 'RPM exclusion list' and an 'RPM obsolete list' in it's confirmation screen. The 'RPM obsolete list' will list the all packages that will be removed by default during the update to 184.108.40.206.0 (or later) when no action is taken by the operator.
As an example - click here
If you would like to find out first what obsolete packages will be
removed you have to choose 'n' when prompted to 'Continue ? [Y/n]'. This
will stop your current patching session. Then look at the contents of the freshly created 'obsolete list' (it
should have the runid of your dbnodeupdate session in it's header). Example here
All the packages listed in the '/etc/exadata/yum/obsolete.lst' file will be removed by default - this has multiple reasons, mainly this is because these packages are not required anymore for Exadata functioning or they are considered a security risk. In case you would like to keep for example the 'java' package, you should create an 'exclusion file' which is '/etc/exadata/yum/exclusion.lst' and put the 'java*openjdk' rpm name (or wildcard) in it.
[root@mynode u01]# cat /etc/exadata/yum/exclusion.lst
When dbnodeupdate.sh is restarted you would see that the 'exclusion file' is detected (an example here).
All packages you have put in the 'exclusion file' will still be listed in
the obsolete file, but will not be removed when the confirmation screen says 'RPM exclusion list: In use (rpms listed in /etc/exadata/yum/exclusion.lst)' with the
update to 220.127.116.11.0 or later.
Frequent releases of dbnodeupdate.sh - keep an eye on it:
dbnodeupdates.sh and it's MOS note were designed / made to be released frequently and quickly when needed.This way dbnodeupdate.sh can provide workarounds for known issues, emergency fixes, new features and best practices to the operator relatively quick.This reduces risk of people not keeping up to date with 'known issues' or not being sure it applies to them. Basically the same idea as with the patchmgr plugins.
Also, unlike to the storage servers some customization can be done on the db servers - best practices and lessons learned from this in regards to patching may also benefit your environment. For those engineers involved with upgrading Exadata database nodes, I'd like to emphasis to always check for the most recent release of dbnodeupdate.sh when doing a db server update. I have already seen some people watching the releases closely, which is definitely a good thing.