8.4.3.1 Patchmgr Syntax for Storage Servers

You can use patchmgr to update software for Oracle Exadata storage servers.

Prerequisites

Patchmgr is run on the "driving system", which is an Oracle Exadata database server or a non-Oracle Exadata system running Oracle Linux. This allows patchmgr to run from a central server to update multiple Oracle Exadata systems

Patchmgr Syntax for Storage Servers

./patchmgr --cells cell_host_file 
  { --patch_check_prereq [--rolling] [--unkey] [--ignore_alerts] [--ignore_date_validations] |
    --patch [--rolling [--partner_cell_stagger {true|false}]] [--unkey] [--ignore_alerts] [--ignore_date_validations] | 
    --rollback_check_prereq [--rolling] [--unkey] [--ignore_alerts] [--ignore_date_validations] | 
    --rollback [--rolling [--partner_cell_stagger {true|false}]] [--unkey] [--ignore_alerts] [--ignore_date_validations] | 
    --cleanup [--unkey] }
  [ --log_dir { log_directory | auto } ]

Main Arguments

Argument	Description
--cells cell_host_file	The cell_host_file is a text file containing the host names of the storage servers to update. The file contains one storage server host name or IP address per line. The storage server patching will fail if the list file is not specified. Note: Storage servers might not be updated in the same order as they are listed in the cell_host_file. By default, starting with the December 2023 Oracle Exadata System Software releases (22.1.18 and 23.1.9), patchmgr optimizes the order of storage server updates to maximize overall performance for rolling updates involving seven (7) or more storage servers. For further details, see the --partner_cell_stagger option.
--patch_check_prereq	Runs prerequisite check on all the storage servers to determine if the patch can be applied to the storage servers.
--patch	Apply the patch, including firmware updates, wherever possible (BIOS, Disk Controller and if possible disk drives) to all storage servers in the storage server list file.
--rollback_check_prereq	Runs prerequisite check on all the storage servers to determine if the storage servers can be rolled back for this specific patch.
--rollback	Rolls back the patch.
--cleanup	Cleans up all patch files and temporary content on all storage servers. Before cleaning up, collects logs and information for problem diagnostics and analysis. Cleaning up patch files can be done manually if patch fails by removing the directory /root/_cellupd_dpullec_ on each storage server.

Supported Options

The following options are supported for storage server patching and rollback:

Table 8-2 Patchmgr Options for Storage Servers

Option	Description
--get property	Get information about specific property. Property can be: log_dir - assigned directory for all log files.
--ignore_alerts	Ignore any active hardware alerts on the Exadata storage server and proceed with the patching.
--ignore_date_validations	Ignore date version validation. This allows upgrades to later releases with an earlier date stamp. For example, 22.1.14.0.0.230820 to 23.1.5.0.0.230818.
--log_dir ( log_directory| auto )	Specifies the absolute path to the log directory, or you can specify auto to use a log directory that is based on the launch directory and the content of the nodes list file. Specifying the -log_dir option enables you to run multiple patch manager invocations and also to run patch manager as a non-root user.
--partner_cell_stagger {true|false}	Determines the order in which the storage servers are updated during a rolling update. true: Optimizes the order of storage server updates to maximize overall performance. This is the default option starting with the December 2023 releases of Oracle Exadata System Software (22.1.18 and 23.1.9). Using this option, patchmgr ensures that the next storage server in the update order is not an ASM partner of the prior storage server. This ordering provides a post-update window allowing each storage server to restart and repopulate its flash cache before any partners are taken offline for their update. This option only applies when the cell_host_file contains seven (7) or more storage servers. Otherwise, patchmgr updates the cells in the order specified in the cell_host_file. false: Updates the cells in the order specified in the cell_host_file.
--rolling	Specifies that the update is to be done in a rolling fashion. If not specified, the update is done in a non-rolling fashion. Environment variable EXA_PATCH_ACTIVATE_TIMEOUT_SECONDS controls the timeout value waiting for the grid disks to be activated. The default is set to 36000 (10 hours). Note: Prerequisite checks and cleanups are always done in a non-rolling fashion, even if the -rolling option is specified.
--smtp_from "email_addr"	Specifies the from email address for the patchmgr notification.
--smtp_to "email_addr1 email_addr2 email_addr3 ..."	Specifies the to email addresses for the patchmgr notification.
--smtp_set_envelope_sender	Specifies that the same from address in Return-Path: mail header should be used.
--unkey	Removes passwordless SSH access to the cells before exit.

Usage Notes

• Starting with Oracle Exadata System Software release 19.3, the options are prefixed with --. Prior to this release, the options were prefixed with -.
• Multiple invocations of patchmgr may be run concurrently from the same software directory by using the --log_dir option. This allows patchmgr to update multiple Oracle Exadata systems concurrently from the same software directory.

• Patchmgr may be run as the root user or as a non-root user. The user running patchmgr must have root-level SSH equivalence configured to the servers or switches that patchmgr will update. To run patchmgr as a non-root user, the -log_dir option must be used.

Example 8-4 Run storage server update pre-requisite checks, then update storage servers

./patchmgr -cells cell_group -patch_check_prereq 
./patchmgr -cells cell_group -patch

Example 8-5 Update storage servers in a rolling manner

The following command updates storage servers in a rolling manner, receive email notifications as the update proceeds, and remove passwordless SSH access to cells after the update is complete.

./patchmgr -cells cell_group -patch -rolling -unkey -smtp_from "[e-mail]" -smtp_to "[e-mail],[e-mail]"

Example 8-6 Update multiple storage servers at one time

The following commands update storage servers on three Oracle Exadata systems simultaneously from the same software directory; one update using a rolling update, the others updates are non-rolling.

In this example:

• Each patchmgr command must be run from a separate terminal window.
• Each patchmgr execution uses a unique logging directory name automatically generated based on the content of the component_list_file.

(terminal1) ./patchmgr -cells cell_group_exa01 -patch -rolling -log_dir auto 
(terminal2) ./patchmgr -cells cell_group_exa02 -patch -log_dir auto 
(terminal3) ./patchmgr -cells cell_group_exa03 -patch -log_dir auto

To have a subsequent patchmgr execution use an altered component_list_file with different content, yet use the same logging directory as a prior patchmgr execution, use the -get log_dir option to obtain the logging directory. For example:

1. The logging directory for the initial patchmgr execution is generated automatically.

   ./patchmgr -cells cell_group -patch -log_dir auto

2. Assume the last cell failed to update and patchmgr will be re-run for the last cell only, using the same logging directory as the initial patchmgr execution. Use the -get log_dir option to obtain the logging directory using the original component_list_file.

   ./patchmgr -cells cell_group -patch -log_dir auto -get log_dir log_dir=/tmp/patch_12.2.1.1.1.170419/log/dm01cel01_dm01cel02_cacce4ee

3. Update the cell_group file to contain only the last cell, or use a different file that contains only the last cell. Specify the logging directory from the initial patchmgr execution so all logs for this group of cells are created in the same logging directory.

   ./patchmgr -cells cell_group -patch -log_dir /tmp/patch_12.2.1.1.1.170419/log/dm01cel01_dm01cel02_cacce4ee