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 in the file that lists the servers to patch.

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 } ] |
  --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 }] ] | 
  --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 } ]

Main Arguments

Argument Description
--dbnodes database_node_file The database_node_file is a text file containing the host names of the database servers to update. The file contains one database server host name or IP address per line. The database server patching will fail if the list file is not specified.
--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.

Supported Options

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

Table 8-3 Patchmgr Options for 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.

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.

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