Exadata Patching Part Five.... Patching the Compute Nodes

In the previous blog post we talked about patching the cell servers. Now, let's talk a little bit about updating the Compute nodes. To begin with, when you look closer at the contents of the QFSDP bundle patch you will find this set of files is included:

- Infrastructure/
|      --ExadataStorageServer/
|          -11.2.3.2.1/
|               -p14522699_112321_Linux-x86-64.zip
|               -p16432033_112321_Linux-x86-64.zip
|               -README-14522699.html
|               -README-16432033.html

Instantly I think this can get confusing, so let me explain. If you goto MOS and look up the first patch p14522699, you will find that this is the Storage Server Software Patch that you will use to update the Storage Servers (which I call the cell servers for some insane reason that I won't try to explain).

So, what is this other patch? What is  p16432033? While you might think this patch has something to do with the storage server (since it sits in a directory called ExadataStorageServer!) in fact it is the ISO image that can be used to update the compute nodes! I know, it's confusing but that is the way things are.

So, what is this patch you ask:

      --ExadataDBNodeUpdate/
|          -dbnodeupdate.zip
|          -README.txt

As it's under a directory you might think that it's the ISO for the compute node. Well, it is, in fact, the database patch for the GRID_HOME (GH) and ORACLE_HOME (OH) directories. So you will be forgiven for being a little confused.

All of these patches are clearly documented (wink) in MOS note 888828.1 (make this note your friend).

To further confuse things, the preferred way to patch your database server operating systems is not through the application of the ISO that is contained in the patch. The preferred way is to use the Oracle Unbreakable Linux Network (ULN) and YUM to download the most current OS release for the compute nodes.

The manual steps for updating a compute node are pretty involved. In an effort to reduce the overall effort and possibility of mistake, Oracle has created a script called the DB Node Update Utility (dbnodeupdate.sh). You can find more information on this tool using MOS note 1553103.1.

Most of the Exadata patches that I do, for various reasons, have to be done manually installing the updates from the current ISO image. If this is something you are going to need to do, reference note 1473002.1 for more information on how to setup the YUM repository for local use.

The bottom line is that for updating the Database Nodes, you will use YUM to grab the needed files in a YUM repository (either the ULN repository or one you create yourself) and then update the compute nodes.

Finally, note 1553103.1 nicely summarizes the various steps that are involved in the update of a compute node. To quote from the note:


A shortened list of the functionality provided by the dbnodeupdate.sh utility as follows:

• Creates log file to track script execution and changes
• Creates diag file with 'before patching' situation
• Provides 'next steps'
• Includes checks and workarounds for known issues
• Creates and runs the backup utility 
• Checks space requirements of /boot filesystem
• Checks for left-over snapshots
• Checks for required files and utilities
• Includes 'check-only' option
• Includes 'quiet mode'
• Relinks all Database and Grid Infrastructure (GI) Homes
• Enables / disables GI to stop/start
• Checks for nfs/smbfs mounts and unmounts when possible
• Validates provided media (zip, ISO, http, file://)
• Validates user
• Provides rollback option
• Generates 'yum repo'-file
• Validates yum.conf-file
• Logs console history
• Stops OSwatcher before patching
• Unpacks media and helper zip-files
• Stops db console and em agent
• Checks for failed 'pvmove' actions
• Checks for left over snapshots and failed backups
• Supports multiple em agents
• Checks for 3GB free space in "/"

I vote for automation! More coming soon!