Updating database servers using dbnodeupdate.sh - part 1

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

Exclusion/Obsolete list 


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

Example:

[root@mynode u01]# cat /etc/exadata/yum/exclusion.lst
java-*-openjdk


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 11.2.3.3.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.


Rene Kundersma

Comments:

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

Posted by guest on January 14, 2014 at 07:15 PM PST #

Post a Comment:
  • HTML Syntax: NOT allowed
About

Blog of Rene Kundersma, Principal Member of Technical Staff at Oracle Development USA. I am designing and evaluating solutions and best practices around database MAA focused on Exadata. This involves HA, backup/recovery, migration and database consolidation and upgrades on Exadata. Opinions are my own and not necessarily those of Oracle Corporation. See http://www.oracle.com/technology/deploy/availability/htdocs/maa.htm.

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today