Exadata Product Development Blog

  • January 14, 2014

Updating database servers using dbnodeupdate.sh - part 1

Rene Kundersma
Software Engineer

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 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'

Exclusion/Obsolete list 

With updates to Exadata 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 (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 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.

Rene Kundersma

Join the discussion

Comments ( 5 )
  • guest Wednesday, January 15, 2014

    Cool. Thanks for explaining these Exclusion/Obsolete list features.

  • Ritesh Kumar Tuesday, November 12, 2019
    Are the customized packages also been taken care by /etc/exadata/yum/exclusion.lst file like telnet and sftp packages?
  • Rene Tuesday, November 12, 2019
    Ritesh: no customised packages are ignored. We will only remove custom package when doing a major OS updates (for example OL6-OL7) and the operator specifying the appropriate flag. For regular updates (OL7-OL7), we do identify any conflicts and provide you the syntax to remove, but we don't remove them ourselves.
  • Ritesh Kumar Thursday, November 14, 2019
    HI Rene,
    If the image update remains in only from OL6 to OL6 only, then can we ignore to remove custom package, actually backup agent is installed in on DBnode and we dont want to disturb that, what we can do in this case? and if possible then please let me know the way.
  • Rene Thursday, November 14, 2019
    Hi Ritesh - as long as the dbnu prereq check passes you can. We do a 'dry-run' of the yum-update. When that dry-run allows at least updating to 'exadata-sun-computenode-minimum' to be installed, you can proceed, even if there's conflicts.
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.