Exadata Update Utilities: patchmgr and dbnodeupdate.sh

1. Introduction

Oracle Exadata Database Machine is a high-performance, optimized platform for Oracle Database workloads. Regularly updating the software components of this platform—including the operating system, Exadata system software, device drivers, and firmware—is crucial for addressing security vulnerabilities, fixing bugs, and leveraging new features. Oracle provides specialized utilities to manage these update processes. Two of the most commonly used tools are patchmgr and dbnodeupdate.sh. This document aims to provide a detailed technical comparison of these two utilities, explaining their functions, key differences, use cases, and parameters for effective Exadata patching.

2. The patchmgr Utility

2.1. Definition and Purpose

patchmgr is a centralized utility designed to orchestrate and simplify software updates for Oracle Exadata infrastructure components. It allows administrators to update multiple components—database servers, storage servers, and network switches—using a single command structure, streamlining the Exadata update process.  

2.2. Scope and Capabilities

• Broad Component Coverage:patchmgr can update various Exadata components :
  • Oracle Exadata Storage Servers (Cells)
  • Oracle Exadata Database Servers (Compute Nodes)
  • RDMA Network Fabric Switches (RoCE Switches)
  • InfiniBand Network Fabric Switches
  • Management Network Switch (specific models)  
• Orchestration: It manages the update sequence across multiple targets, supporting both rolling and non-rolling updates.
  • Rolling Update: Updates components sequentially (one by one) to maintain overall system availability, ideal for RAC clusters or storage server grids.  
  • Non-Rolling Update: Updates all specified components concurrently, which is faster but requires a complete system outage.  
• Automation: For database server updates, patchmgr automates numerous steps, including stopping/starting databases and Grid Infrastructure, managing VMs, handling Oracle Enterprise Manager agents, taking OS backups, relinking Oracle Homes, and applying best practice configurations.  
• Centralized Execution: patchmgr can be executed from a database server within the Exadata system being patched or from a separate, central server (the “driving system”) running Oracle Linux or Oracle Solaris. This facilitates managing multiple Exadata systems from one location.  
• User and Concurrency: Can be run by root or a non-root user (requires -log_dir). Multiple patchmgr instances can run concurrently from the same software directory (using distinct -log_dir values) to patch different systems simultaneously.  

2.3. Platform Support

• Target Systems: The Exadata components updated by patchmgr (database servers, storage servers) typically run Oracle Linux.
• Driving System: The patchmgr utility itself can be executed from a server running either Oracle Linux or Oracle Solaris. This means you can initiate and manage the patching of Linux-based Exadata components from a Solaris management server.  

2.4. Key Parameters and Usage

The general syntax for patchmgr is: ./patchmgr -<component> <component_list_file> -<action> <required_arguments> [optional_arguments]  

• -<component>: Specifies the component type:
  • -cells: For Storage Servers.
  • -dbnodes: For Database Servers.
  • -ibswitches: For InfiniBand Switches.
  • -roceswitches: For RoCE Switches.
• <component_list_file>: A text file listing the hostnames of the components to be updated.  
• -<action>: Specifies the operation:
  • -upgrade: Performs a software upgrade to a specified version.  
  • -rollback: Rolls back to the previous software version.
  • -precheck: Runs prerequisite checks before an upgrade or rollback.  
  • -backup: Performs a backup (typically for DB nodes).
• [optional_arguments]: Modifies the action or behavior:
  • --rolling / -rolling: Perform the action in a rolling fashion.  
  • --iso_repo <path_to_iso> / -iso_repo <path_to_iso>: Specifies the path to the patch ISO file.  
  • --target_version <version> / -target_version <version>: Specifies the target software version.  
  • --modify_at_prereq: Allows removal of conflicting RPMs during precheck to resolve dependencies (for DB nodes).  
  • --force_remove_custom_rpms: Forces removal of custom (non-Exadata) RPMs during an OS upgrade (for DB nodes).
  • --log_dir <directory|auto>: Specifies a directory for log files or uses automatic naming. Required for concurrent execution or non-root users.  
  • --allow_active_network_mounts: Allows patching to proceed even if active network mounts (like NFS) are detected.  
  • --dbnode_patch_base <path>: Specifies the directory on target DB nodes where patch files will be extracted.  
  • --ignore_alerts: Proceeds with patching despite active hardware alerts.  
  • --sequential_backup: Backs up each node immediately before updating it during a rolling update (default is to back up all nodes first).  
  • --update_type <type>: Selects security-only (allcvss) or full (full) update.  
  • --live-update-target: Utilizes Exadata Live Update (on supported versions).  

3. The dbnodeupdate.sh Utility

3.1. Definition and Purpose

dbnodeupdate.sh is a shell script specifically used to update, roll back, or back up the software on a single Oracle Exadata database server (compute node). Before patchmgr provided orchestration for database servers, updates often involved manually running dbnodeupdate.sh on each node sequentially.  

3.2. Scope and Capabilities

• Single Database Server Focus: dbnodeupdate.sh operates only on the database server where it is executed.  
• Core Update Engine: When patchmgr updates database servers, it essentially invokes dbnodeupdate.sh on each target node to perform the actual update, rollback, or backup tasks.  
• Operating System Updates: It handles updates for the Oracle Linux OS, device drivers, and firmware included in the Exadata system software patch. It supports major OS upgrades (e.g., OL6 to OL7, OL7 to OL8), although older dbnodeupdate.sh versions might be needed for older OS transitions.  
• Backup and Rollback: Automatically creates a backup of the root filesystem before starting an update. This backup enables rollback to the previous state using the -r option if the update fails or needs to be reverted.  
• Dependency Management: Includes the -M option to allow the removal of conflicting RPMs during the prerequisite check phase to resolve dependency issues.  

3.3. Platform Support

• dbnodeupdate.sh runs on the Exadata database server being updated. Modern Exadata database servers exclusively use Oracle Linux. While Solaris was supported on older Exadata compute nodes , dbnodeupdate.sh in current contexts targets Linux.  

3.4. Key Parameters and Usage

The basic usage is: ./dbnodeupdate.sh <options>

• -u: Initiates the update process.  
• -r: Initiates a rollback from the pre-update backup.  
• -b: Performs only the backup step.
• -c: Runs the post-reboot completion steps after an update or rollback.  
• -l <ISO_or_Repo_URL>: Specifies the path to the update ISO file or the YUM repository URL.  
• -s: Stops Cluster Ready Services (CRS) before the update/rollback and restarts it afterward.  
• -p: Runs the bootstrap phase (typically for upgrades from older versions).  
• -x <helper_script_dir>: Specifies the directory containing helper scripts (often used with -p).  
• -M: Allows removal of conflicting RPMs during prerequisite checks.  
• -v: Performs only the prerequisite check.  

4. patchmgr vs. dbnodeupdate.sh: Key Differences

Feature	patchmgr	dbnodeupdate.sh
Primary Purpose	Orchestration for Exadata infrastructure components	Single Exadata DB server update/rollback/backup
Scope	DB Servers, Storage Servers, Network Switches	DB Servers Only
Execution Mode	Manages multiple targets; invokes dbnodeupdate.sh for DB nodes	Runs on a single target node
Update Mode	Rolling or Non-Rolling	Affects only the single node it runs on
Run Location	DB Node or separate Linux/Solaris server	Only on the target DB Node being updated
Typical Use Case	Standard multi-component/multi-node patching	Single node update/rollback; invoked by patchmgr; patching last node in rolling update; recovery scenarios
Driving Platform	Linux, Solaris	Linux (on the target DB Node)

5. Which Tool Should Be Used When?

• Use patchmgr when:
  • Updating multiple storage servers, database servers, or network switches (standard and preferred method).
  • Choosing between rolling or non-rolling update strategies.
  • Managing the update process from a central server.
  • Leveraging automated orchestration steps (service stop/start, backup, relink).
• Use dbnodeupdate.sh when:
  • Updating or rolling back only one specific database server (e.g., testing on a single node).
  • Performing a rolling update with patchmgr and needing to patch the initial driving node last (by running dbnodeupdate.sh locally on it after other nodes are done).  
  • Recovering a system after a failed update/rollback by booting from a diagnostic ISO.  
  • As a manual alternative if patchmgr itself encounters issues or is unavailable.

As a general rule, patchmgr is the standard utility for routine Exadata infrastructure patching. dbnodeupdate.sh should be considered an underlying component used by patchmgr for database nodes or a tool for specific single-node scenarios.

6. Conclusion

patchmgr and dbnodeupdate.sh are essential tools for maintaining the currency and security of Oracle Exadata platforms. patchmgr serves as the primary orchestration utility, simplifying the update process across multiple Exadata components (database servers, storage servers, switches) and supporting both rolling and non-rolling strategies. It can be driven from Linux or Solaris systems. dbnodeupdate.sh is the core script that performs the actual update, rollback, or backup on individual Linux-based Exadata database servers, often invoked by patchmgr but also usable standalone for specific single-node tasks or recovery situations. Understanding the distinct roles and capabilities of each tool allows administrators to choose the appropriate method for their specific Exadata maintenance requirements, with patchmgr being the standard choice for most patching operations.