8.6.3 Update Utility for Oracle Exadata Storage Server

You use the patchmgr update utility for updating Oracle Exadata storage servers. For Exadata storage server updates the utility is packaged (and shipped) with the update itself and is available for download from My Oracle Support as storage server update.

Note:

The patchmgr used for updating Exadata storage servers is not the same as the patchmgr used for applying the Exadata database server software update.

Whether or not the utility supports the Exadata hardware you have depends on the Exadata storage server release you are trying to update to. The utility orchestrates the update process across the specified Exadata storage servers. The utility allows running the update in a rolling or non-rolling fashion. You can run the update utility from Exadata database servers or from other servers running Oracle Linux or Oracle Solaris.

The update utility performs the following tasks:

  • Automates the preparation, update, and validation steps

  • Automates rollbacks

The update utility supports multiple sessions: you can run multiple updates concurrently from the same server starting with release 12.1.2.3.2 for Exadata storage servers and starting with release 11.2.3.1.0 for Exadata database servers. This means multiple racks can be updated concurrently from the same server. The update utility can be run as root or as a non-root user. By default the update utility assumes it should run as the root user. If however you want to enable multiple session support or run as a non-root user, then you need to use the -log_dir flag. The -log_dir flag supports two types of arguments: either a location on disk or the keyword auto. If you specify auto, the update utility creates its own log directory based on the storage servers listed in the cell_group file. This behavior causes the update utility to create new directories for each run of updates in the same cluster where one or more clusters were added or removed from the cell_group file. In order to obtain (and reuse) such a directory, the update utility provides the -get flag to determine the log directory for your session. The-get flag scans the working directory for directories in the log directory and returns the directory for your cell_group. For example, the following command:

[oracle@nonExadataHost ]#./patchmgr -dbnodes ~/cell_group  -log_dir auto -get log_dir

The previous comment might return output similar to the following:

log_dir=/u01/test/patch_12.1.2.4.0.160802/log/dbm02celadm01_dbm02celadm02_9cfbc690

In a subsequent update session, you can re-use the log directory location:

[oracle@nonExadataHost ]# ./patchmgr -cells ~/cell_group -patch_check_prereq -log_dir /u01/test/patch_12.1.2.4.0.160802/log
/dbm02celadm01_dbm02celadm02_9cfbc690