8.6.6 Running the Update for Exadata Storage Servers

After performing the prerequisite steps in Preparing Exadata Storage Servers for Update, you can perform the actual update step.

Note the following when applying the update to the Exadata storage servers:

• Do not use the serial console or the ILOM web-based console to start the update utility.

  There is a known issue of a system halt on the serial console when a write is attempted to stderr or stdout. If an update is started from the serial console, then it may halt.

  You are using the serial console if the output from the following command is serial.

  [root@dm01 ]# ./echo $consoletype
  

• When needed, use the ILOM web-based console to monitor the storage server during the update. You will need to use the ILOM web-based console in case troubleshooting is required.

• To obtain ILOM and serial console access for the storage servers, use SSH to the ILOM host name or IP address as the root user. Do the following to start the serial console:

  start /SP/console
  

  To stop it press the Escape key (ESC) followed by (.

• Start a new login session for each update or rollback procedure. Do not run a rollback procedure from the same login session where an update was applied. Do not run an update from a login session where a rollback procedure was run.

• Do not interrupt the update process.

• If you must use a storage server as the patchmgr utility launch system, then do not use /opt/oracle as the staging area for the update. This causes the update to fail and corrupt the storage server. Use the /tmp directory as the staging area, that is, unzip the files for the update in /tmp.

• Storage servers automatically reboot, as needed, during the update process. Do not reboot or power cycle storage servers while applying updates.

• Do not edit or open log files in writable mode. You may use any of the following to view a log: view, less, more, or tail. You may cause the update process to be interrupted if you edit the log files during the update.

• At the end of the patchmgr session, the patchmgr.stdout log file is divided into individual storage server log files with names in the format of cell_name.log. In addition, the /var/log/cellos content from the inactive cell partition is copied to the /var/log/cellos/inactive_partition directory. To locate the inactive partition, use the following command:

  [root@dm01 ]# ./imageinfo -inactive -sys
  

Examples running update:

Running the update in a rolling fashion as root from an Exadata database server:

[root@dm01 ]# ./patchmgr -cells ~/cell_group -patch -rolling -smtp_from "[e-mail]" -smtp_to [e-mail]

Running the update in a non-rolling fashion as a non-root user from a non-Exadata database server:

[oracle@nonExadataHost ]$ ./patchmgr -cells ~/cell_group -log_dir auto -patch -smtp_from "[e-mail]" -smtp_to "[e-mail]"

After the update is done, clean up the storage servers using the -cleanup option to clean up all the temporary update or rollback files. This option cleans the stale update and rollback states as well as cleaning up to 1.5 GB of disk space on the storage server. Use this option before retrying a halted or failed run of the update utility. See step 8 for details.