8.4.3.2 Patchmgr Syntax for Database Servers

You can use patchmgr to update software for Oracle Exadata database 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. If patchmgr is run from an Oracle Exadata database server, then that database server cannot be a target of the patchmgr command.

Patchmgr Syntax for Database Servers 

./patchmgr --dbnodes database_node_file
{ --backup --repo { base_URL | zipped_iso_file } [--rolling] [--unkey] |
  --precheck --repo { base_URL | zipped_iso_file } --target_version version [ --unkey ]
    [ --live-update-target { highcvss | allcvss | full } ]
    [ { --additional-rpms { rpm_spec[,rpm_spec]... | rpm_dir } | 
        --additional-rpms-list rpm_list } 
      [ --additional-rpms-from-repo ] ] |
  --upgrade --repo { base_URL | zipped_iso_file } --target_version version [ --rolling ] [ --unkey ]
    [ --live-update-target { highcvss | allcvss | full } [ --live-update-schedule-outstanding-work { timestamp | never }] ] 
    [ { --additional-rpms { rpm_spec[,rpm_spec]... | rpm_dir } | 
        --additional-rpms-list rpm_list } 
      [ --additional-rpms-from-repo ] ] |
  --complete [ --target_version version ] [--unkey] |
  --rollback [--rolling] [--unkey] |
  --cleanup  [--unkey] |
  --live-update-schedule-outstanding-work { timestamp | never | reset } |
  --live-update-list-outstanding-work }
[ --log_dir { log_directory | auto } ]
[ --scp-bin path-to-scp ]
[ --ssh-bin path-to-ssh ]

Main Arguments

Argument Description
--dbnodes database_node_file

The database_node_file is a text file identifying the database servers that are the target of the patchmgr operation.

The file must exist and contain one target database server host name or IP address on each line. The server running patchmgr cannot be included in the file.
--backup

Perform backup for the database nodes specified in the host list.

Specify the --rolling option to perform the backup in a rolling manner (one node at a time).

--precheck Runs the pre-upgrade validation checks in the database nodes specified in the host list in non-rolling fashion.
--upgrade

Updates the database nodes specified in the host list.

Specify the --rolling option to perform the update in a rolling manner (one node at a time).

Specify the --live-update-target option to perform the update using Exadata Live Update.

--complete Runs 'completion-steps' only. In normal cases there is no need to run this separately as this already runs as part of --upgrade. Note: If the database stack or user domains are up, they will be shut down and restarted.
--rollback

Rollback the database nodes specified in the host list.

Specify the --rolling option to perform the rollback in a rolling manner (one node at a time).

--cleanup Cleans up all temporary content on the database servers specified in the host list in non-rolling fashion.

Options for Updating Exadata Database Servers

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

Table 8-3 Patchmgr Options for Exadata Database Servers

Option Description

--allow_active_network_mounts

Allows dbnodeupdate to run with active NFS or SMB mounts.

This is equivalent to the dbnodeupdate.sh -a command.

--allow_non_signed_repo

Allow dbnodeupdate to run with a non-signed repository. (Oracle Exadata System Software release 19.2 and later)

--dbnode_patch_base

User preferred location on target database servers where patch iso image and dbnodeupdate archive files are to be unzipped.

Note: Provided location must be an absolute path of local file system and it should have sufficient amount of free space and inodes.

--force_remove_custom_rpms

Remove any custom RPMs when the database server update includes a major operating system update. For example, from Oracle Linux 7 to Oracle Linux 8.

--ignore_alerts Ignore any active hardware alerts on the Exadata server and proceed with the patching.

--log_dir ( log_directory| auto )

The absolute path to the log directory, or you can specify auto to use a log directory that is based on the directory you started patchmgr from 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.

--no_connection_draining

Disables database connection draining for Fleet Patching and Provisioning, formerly known as Rapid Home Provisioning (RHP). The connection draining availability depends on the Oracle Grid Infrastructure release. This option is applicable to only rolling updates.

--nobackup

Do not backup the database servers before an update.

--repo { base_URL | zipped_iso_file }

Specifies the base URL for the Exadata update repository or the path to a zipped ISO file.

This option must be specified for --backup, --precheck, and --upgrade actions.

--rolling

Specifies that the update is to be done in a rolling fashion, one server at a time. 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.

--rolling_backups

Directs patchmgr to backup each node prior to updating that node in a rolling manner. If this option is not specified (default), then patchmgr completes the backups of all nodes in parallel before updating the first node.

This option can only be used in conjunction with the --rolling option. Otherwise, this option is ignored and the default backup method is used.

This option is ignored if --nobackup is included in the command.

--skip_gi_db_validation

Skip certification of Oracle Grid Infrastructure and Oracle Database home compatibility with Oracle Linux 7.

Only for updates from Oracle Linux 6 to Oracle Linux 7.

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

--target_version version

The full patch version as specified in the patch README file. For example: 23.1.8.0.0.231109

This option must be specified for --precheck and --upgrade actions.

--unkey Removes passwordless SSH access to the servers before exit.

--scp-bin path-to-scp

Specifies the absolute path to a customer-trusted SCP client. For example:

/path/to/scp

The target executable must be named scp. The path must be an absolute path, with no white space, control characters, or shell meta characters. The target must be a regular executable file. The target executable and every directory in its path must be owned by root and must not have group or world write permissions.

Note: The --scp-bin option is available only with Oracle Exadata System Software release 26.1.0 or later.

--ssh-bin path-to-ssh

Specifies the absolute path to a customer-trusted SSH client. For example:

/path/to/ssh

The target executable must be named ssh. The path must be an absolute path, with no white space, control characters, or shell meta characters. The target must be a regular executable file. The target executable and every directory in its path must be owned by root and must not have group or world write permissions.

Note: The --ssh-bin option is available only with Oracle Exadata System Software release 26.1.0 or later.

Exadata Live Update Options

Oracle Exadata System Software release 24.1.0 introduces Exadata Live Update, a suite of update enhancements for Exadata database servers.

Exadata Live Update uses online update capabilities. Depending on the specific contents of the update, the operation might be completed without interrupting databases or rebooting the server. If a reboot is required, it can be deferred to a later time.

Exadata Live Update also supports partial updates to address security issues.

Note:

Exadata Live Update may only be used for specific updates that it supports. For details, always refer to the release information associated with each update.

The following additional options support Exadata Live Update on Exadata database servers:

Table 8-4 Patchmgr Options for Exadata Live Update on Exadata Database Servers

Option Description

--live-update-target

Performs the operation using Exadata Live Update.

One of the following values must be specified after --live-update-target:

  • highcvss: Performs only critical security updates to address vulnerabilities with a Common Vulnerability Scoring System (CVSS) score of 7 or greater.

  • allcvss: Performs only security updates to address vulnerabilities with a CVSS score of 1 or greater.

  • full: Performs a full update, which includes all security-related updates and all other non-security updates.

--live-update-schedule-outstanding-work

Controls the schedule for outstanding work.

Outstanding work is any update items that cannot be completed online and require a system reboot. For example, Exadata Live Update can update the Linux kernel online using Ksplice but changing to a new Linux kernel version requires a system reboot.

To control outstanding work in conjunction with an Exadata Live Update operation, specify --live-update-schedule-outstanding-work together with --live-update-target. If you do not specify --live-update-schedule-outstanding-work together with --live-update-target, the outstanding work is automatically scheduled for the next graceful server reboot.

You can also use --live-update-schedule-outstanding-work without --live-update-target to change how you want to handle outstanding work left over from previous Exadata Live Update operations.

The following values may be specified after --live-update-schedule-outstanding-work:

  • timestamp: Schedules the outstanding work at the specified time.

    In this case, the outstanding work is completed only if a graceful server reboot is started within 10 minutes of the specified time (either before or after).

    If the scheduled time passes without a graceful reboot, the outstanding work must be rescheduled, either for another time or during the next graceful server reboot.

    The expected timestamp format is "YYYY-MM-DD HH24:MM:SS" or "YYYY-MM-DD HH24:MM:SS TZ". If you do not specify the timezone (TZ), the default timezone value is UTC. You must include the surrounding quotation marks.

  • never: Specifies that the outstanding work is not scheduled. This value effectively disables completion of the outstanding work.

    To complete outstanding work after using this setting, you must reschedule the outstanding work by using one of the other values.

  • reset: Reschedules outstanding work to occur during the next graceful server reboot (but not following an ungraceful shutdown due to a node eviction, power outage, or system crash).

    This value is only valid when using --live-update-schedule-outstanding-work without --live-update-target.

This option is only applicable for updates using Exadata Live Update.

--live-update-list-outstanding-work

Display information about any system reboot scheduled to complete outstanding work.

This option is only applicable for updates using Exadata Live Update.

Options for Updating Additional RPMs

For updates that do not change the major Oracle Linux version number, Oracle Exadata System Software release 25.1.0 introduces options to update additional non-Exadata software packages as part of an Exadata database server update operation. This integrated capability enables you to easily handle software package dependency issues that arise when additional non-Exadata software packages are installed on the system.

With this capability, you can iteratively run patchmgr with the --precheck option to find and resolve package dependency issues associated with any additional non-Exadata software packages installed on the system. After you understand the additional package updates required for a clean update, you can confidently perform the Exadata database server update and update the additional packages at the same time.

Note:

This capability is not available for updates that change the major Oracle Linux version number. For example, from Oracle Linux 7 to Oracle Linux 8.

To update additional non-Exadata software packages on Exadata database servers, you can use the specific patchmgr options for additional packages (--additional-rpm*), or specify a file on each target database server containing a list of additional packages.

By default, if you do not use any specific patchmgr options for additional RPMs during a pre-check or update operation, patchmgr automatically checks each target database server for a file at /etc/exadata/additional-packages.txt. If the file exists, or if it is a symbolic link to another file, its contents are treated as a list of additional packages to be included on that server. The listed packages must be accessible from the target database server itself, rather than from the driving system where the patchmgr command is initiated. In each file, specify each package on a separate line using one of the following formats:

  • Full file path. For example: /full/path/to/package1.rpm

  • HTTP(S) URL. For example: https://server.example.com/web/path/to/package1.rpm

  • Reference to an existing Yum or DNF repository defined in the server configuration. The format of the reference is repo:rpm_name. For example: repo:package1

Alternatively, you can use the patchmgr options outlined in the following table to update additional non-Exadata software packages. If you use any of the following options, patchmgr ignores the contents of /etc/exadata/additional-packages.txt on the target database servers.

Table 8-5 Patchmgr Options for Updating Additional RPMs

Option Description

--additional-rpms { rpm_spec[,rpm_spec]... | rpm_dir }

Optionally specifies additional packages (RPMs) to include during a pre-check or update operation.

You can specify the additional RPMs as a comma-separated list, or you can provide the name of a directory containing the additional RPMs.

If you specify this option without the --additional-rpms-from-repo option, the server running patchmgr needs to access the additional RPM files and transfer them to the target update server(s). In this case, you must identify each RPM using one of the following methods:

  • Full file path. For example: /full/path/to/package1.rpm

  • HTTP(S) URL. For example: https://server.example.com/web/path/to/package1.rpm

  • Reference to an existing Yum or DNF repository defined in the server configuration. The format of the reference is repo:rpm_name. For example: repo:package1

Alternatively, you can instruct the update target server(s) to download the RPMs directly from a Yum or DNF repository by adding the --additional-rpms-from-repo option. In this case, you can identify each RPM by name only.

--additional-rpms-list rpm_list

Optionally specifies a text file containing a list of additional packages (RPMs) to include during a pre-check or update operation.

In the file, each RPM must be specified on a separate line.

If you specify this option without the --additional-rpms-from-repo option, the server running patchmgr needs to access the additional RPM files and transfer them to the target update server(s). In this case, you must identify each RPM using one of the following methods:

  • Full file path. For example: /full/path/to/package1.rpm

  • HTTP(S) URL. For example: https://server.example.com/web/path/to/package1.rpm

  • Reference to an existing Yum or DNF repository defined in the server configuration. The format of the reference is repo:rpm_name. For example: repo:package1

Alternatively, you can instruct the update target server(s) to download the RPMs directly from a Yum or DNF repository by adding the --additional-rpms-from-repo option. In this case, you can identify each RPM by name only.

--additional-rpms-from-repo

Optionally instructs the update target server(s) to download the RPMs directly from a Yum or DNF repository.

To use this option, a suitable repository must be configured on each target server and the configured repository must be accessible from each target server.

Examples

Example 8-7 Backup database servers then perform the update

The following commands backup the Oracle Exadata database servers, run the prerequisite checks for the database server update, and then update the database servers in a rolling manner. 

[root@pmserver ~]# ./patchmgr --dbnodes dbnode_group --backup --repo /var/stage/p35869377_231000_Linux-x86-64.zip --target_version 23.1.8.0.0.231109

[root@pmserver ~]# ./patchmgr --dbnodes dbnode_group --precheck --repo /var/stage/p35869377_231000_Linux-x86-64.zip --target_version 23.1.8.0.0.231109

[root@pmserver ~]# ./patchmgr --dbnodes dbnode_group --upgrade --nobackup --repo /var/stage/p35869377_231000_Linux-x86-64.zip --target_version 23.1.8.0.0.231109 --rolling

Example 8-8 Perform an update using Exadata Live Update

The following commands perform a full update using Exadata Live Update. The first command performs a precheck operation. The second command performs the update. The third command defers any outstanding work arising from the update. The fourth command displays information about the outstanding work arising from the update. The final command schedules the outstanding work for a specific time. 

[root@pmserver ~]# ./patchmgr --dbnodes dbs_group --precheck --repo /my/dir/exadata_ol8_24.1.0.0.0.240409_Linux-x86-64.zip --target_version 24.1.0.0.0.240409 --log_dir auto --live-update-target full

[root@pmserver ~]# ./patchmgr --dbnodes dbs_group --upgrade --repo /my/dir/exadata_ol8_24.1.0.0.0.240409_Linux-x86-64.zip --target_version 24.1.0.0.0.240409 --log_dir auto --live-update-target full

[root@pmserver ~]# ./patchmgr --dbnode dbs_group --live-update-schedule-outstanding-work never --log_dir auto

[root@pmserver ~]# ./patchmgr --dbnodes dbs_group --live-update-list-outstanding-work --log_dir auto

[root@pmserver ~]# ./patchmgr --dbnode dbs_group --live-update-schedule-outstanding-work "2024-12-31 23:10:10 PDT" -log_dir auto

Example 8-9 Perform a precheck including additional RPMs

This example shows a precheck including additional RPM files specified on the command line using the --additional-rpms option. In this case, the patchmgr command does not use the --additional-rpms-from-repo option, so patchmgr needs to access the additional RPM files and transfer them to each target server. 

[root@pmserver ~]# patchmgr --dbnodes dbs_group --precheck --repo /my/dir/exadata_ol8_25.1.0.0.0.241130_Linux-x86-64.zip --target_version 25.1.0.0.0.241130 --log_dir auto 
                      --additional-rpms /my/dir/rpms/elfutils-debuginfod-client-0.190-2.el8.x86_64.rpm,/my/dir/rpms/elfutils-libelf-devel-0.190-2.el8.x86_64.rpm,/my/dir/rpms/keyutils-libs-devel-1.5.10-9.0.1.el8.x86_64.rpm

Example 8-10 Perform an update including additional RPMs

This example shows an update including additional RPM files specified as a list of local file names in a text file at /my/dir/additionalpackages1.txt. In this case, the patchmgr command does not use the --additional-rpms-from-repo option, so patchmgr needs to access the additional RPM files and transfer them to each target server. 

[root@pmserver ~]# cat /my/dir/additionalpackages1.txt
/my/dir/rpms/elfutils-debuginfod-client-0.190-2.el8.x86_64.rpm
/my/dir/rpms/elfutils-libelf-devel-0.190-2.el8.x86_64.rpm
/my/dir/rpms/keyutils-libs-devel-1.5.10-9.0.1.el8.x86_64.rpm
/my/dir/rpms/krb5-devel-1.18.2-28.0.1.el8_10.x86_64.rpm

[root@pmserver ~]# ./patchmgr --dbnodes dbs_group --upgrade --repo /my/dir/exadata_ol8_25.1.0.0.0.241130_Linux-x86-64.zip --target_version 25.1.0.0.0.241130 --log_dir auto --additional-rpms-list /my/dir/additionalpackages1.txt

Example 8-11 Perform an update using additional RPMs

This example shows an update including additional RPM files specified as a list of HTTPS URLs in a text file at /my/dir/additionalpackages1.txt. In this case, the patchmgr command does not use the --additional-rpms-from-repo option, so patchmgr needs to download the additional RPM files and transfer them to each target server. 

[root@pmserver ~]# cat /my/dir/additionalpackages2.txt
https://yum-mirror.example.com/repo/OracleLinux/OL8/baseos/latest/x86_64/getPackage/sssd-nfs-idmap-2.9.4-3.0.1.el8_10.x86_64.rpm
https://yum-mirror.example.com/repo/OracleLinux/OL8/baseos/latest/x86_64/getPackage/timedatex-0.5-3.el8.x86_64.rpm
https://yum-mirror.example.com/repo/OracleLinux/OL8/baseos/latest/x86_64/getPackage/zlib-devel-1.2.11-25.el8.x86_64.rpm

[root@pmserver ~]# ./patchmgr --dbnodes dbs_group --upgrade --repo /my/dir/exadata_ol8_25.1.0.0.0.241130_Linux-x86-64.zip --target_version 25.1.0.0.0.241130 --log_dir auto --additional-rpms-list /my/dir/additionalpackages2.txt

Example 8-12 Perform an update using additional RPMs

This example shows an update including additional RPM files specified in a text file at /my/dir/additionalpackages3.txt. The example uses the --additional-rpms-from-repo option, so the file identifying additional RPM files requires only the RPM names. In this case, patchmgr only propagates the RPM names to each target server, and each target server downloads the RPMs directly from a suitably configured Yum or DNF repository. 

[root@pmserver ~]# cat /my/dir/additionalpackages3.txt
elfutils-debuginfod-client-0.190-2.el8.x86_64.rpm
elfutils-libelf-devel-0.190-2.el8.x86_64.rpm
keyutils-libs-devel-1.5.10-9.0.1.el8.x86_64.rpm
krb5-devel-1.18.2-28.0.1.el8_10.x86_64.rpm
zlib-devel-1.2.11-25.el8.x86_64.rpm

[root@pmserver ~]# ./patchmgr --dbnodes dbs_group --upgrade --repo /my/dir/exadata_ol8_25.1.0.0.0.241130_Linux-x86-64.zip --target_version 25.1.0.0.0.241130 --log_dir auto --additional-rpms-list /my/dir/additionalpackages3.txt --additional-rpms-from-repo

Related Topics

Parent topic: Patchmgr Syntax