Oracle Exadata Patching Series — Part 1: Compute Node Patching Step-by-Step w/ output

Introduction

Oracle Exadata is the flagship engineered system for running mission-critical Oracle databases, and one of the key responsibilities of an Exadata Administrator is performing infrastructure patching. Unlike traditional database patching, Exadata updates involve coordinated patching of compute nodes, storage servers, networking components, and firmware while maintaining high availability.

In this blog series, we will explore the complete Exadata patching lifecycle through practical, real-world examples. We begin with patching Exadata Compute Nodes, followed by Storage Server patching and Exadata Live Update patching in subsequent articles.

Performing Exadata Database Server Updates

Updating Exadata database servers follows a similar process for bare-metal database servers, virtual machine (VM) hosts, and VM guest nodes. The patching activity is orchestrated using the patchmgr utility, which automates prechecks, rolling updates, validation, and post-patching tasks.

The high-level steps involved in updating Exadata database servers are:

1. Download the latest patchmgr utility from My Oracle Support and stage it on the driving system.

2. Download the target Exadata database server software image and copy it to the staging location.

3. Review the patch README and release notes to understand prerequisites, known issues, and supported upgrade paths.

4. Run the patchmgr precheck to validate the environment and resolve any reported issues.

5. Perform a rolling or non-rolling update of the database servers based on the planned maintenance strategy.

6. Verify the successful completion of the upgrade by validating the Exadata image version, Oracle Clusterware, ASM, database instances, and application services.

Why Rolling Patching?

In this article, the compute nodes are patched in a rolling manner. One compute node is taken out of the cluster, patched, validated, and returned to service before proceeding to the next node. This approach minimizes application downtime and maintains database availability throughout the maintenance window.

Environment

The demonstrations in this article are performed on an Oracle Exadata Database Machine X6–2 running Oracle Linux 8. The following patch bundles were downloaded from My Oracle Support (MOS) and staged on each of the compute nodes before initiating the patching activity.

Patch 21634633: DBSERVER.PATCH.ZIP — Exadata Database Server Patch Orchestrator (patchmgr) and dbnodeupdate.sh utilities

Patch 38618607: Exadata Compute Node 24.1.19.0.0 Oracle Linux 8 Base Repository ISO Image (24.1.19.0.0.251214)

Patch stage location: /u01/patches/compute_node

[root@lrlupxa7dbadm01 ~]# ls -lrt /u01/patches/compute_node

-rw-r — r — 1 root root 4920471531 Dec 22 06:17 p38618607_241000_Linux-x86–64.zip

-rw-r — r — 1 root root 8686448 Dec 22 06:32 p21634633_252000_Linux-x86–64.zip

drwxr-xr-x 8 root root 4096 Dec 22 06:54 dbserver_patch_250708

Utility & Commands used in patching

patchmgr — Exadata patchmgr is Oracle’s centralized patch orchestration utility designed to simplify software updates across the Exadata infrastructure. It automates the patching of Exadata database servers (compute nodes), storage servers (cell nodes), and network fabric switches, reducing the complexity of maintaining an Exadata environment.

dbnodeupdate — This utility is the core Exadata database server patching tool responsible for updating individual Exadata compute nodes. It performs the actual software upgrade on each compute node.

Options available for dbnodeupdate

-a Allow dbnodeupdate.sh to run with active NFS/SMB mounts

-b Perform backup only.

-s Shutdown stack (domU’s for VM) before upgrading/rolling back.

-u Upgrade

-l Baseurl (http,https or zipped iso file for the repository)

-v Verify prereqs only. Only to be used in combination with -u and -l option

-M Allows removal of conflicting RPMs during prerequisite checks.

-n No backup will be created.

Compute Node Patching — Pre-Patching Health Checks

Before patching a compute node, perform a series of validation checks to ensure the environment is healthy and ready for maintenance. These checks help identify potential issues that could affect the patching process or cause unexpected downtime.

1. Validate Network Configuration

Verify the network routing configuration on all compute nodes to ensure there are no connectivity issues that could impact cluster communication during patching.

[root@chiexa01dbadm01 ~]# dcli -g dbs_group -l root ip route show

2. Verify Filesystem Utilization

Check the available disk space on all compute nodes. Adequate free space is required to stage the patch files and create temporary working directories during the upgrade.

[root@chiexa01dbadm01 ~]# dcli -g dbs_group -l root df -h

3. Verify Operating System Information

Confirm the operating system version and kernel details to ensure the compute nodes are running the expected platform before applying the new image.

[root@chiexa01dbadm01 ~]# dcli -g dbs_group -l root uname -a

chiexa01dbadm01: Linux chiexa01dbadm01.server.com 5.4.17–2136.343.5.6.el8uek.x86_64 #3 SMP Tue Sep 23 05:49:58 PDT 2025 x86_64 x86_64 x86_64 GNU/Linux

chiexa01dbadm02: Linux chiexa01dbadm02.server.com 5.4.17–2136.343.5.6.el8uek.x86_64 #3 SMP Tue Sep 23 05:49:58 PDT 2025 x86_64 x86_64 x86_64 GNU/Linux

4. Verify Current Exadata Image Version

Record the currently installed Exadata image version. This provides a baseline for validating the upgrade after patching.

[root@chiexa01dbadm01 ~]# dcli -g dbs_group -l root imageinfo -version

chiexa01dbadm01: 24.1.17.0.0.251012.1

chiexa01dbadm02: 24.1.17.0.0.251012.1

5. Capture Oracle Clusterware Status

Capture the status of all Oracle Clusterware resources before stopping the cluster. This serves as a reference during post-patching validation.

[root@chiexa01dbadm01 ~]# /u01/app/23.0.0.0/grid/bin/crsctl status resource -t > /u01/patches/cluster_status_before_yum_patch.txt

[root@chiexa01dbadm01 ~]# ls -lrt /u01/patches/cluster_status_before_yum_patch.txt

-rw-r — r — 1 root root 5826 Dec 22 07:37 /u01/patches/cluster_status_before_yum_patch.txt

[root@chiexa01dbadm01 ~]# cat /u01/patches/cluster_status_before_yum_patch.txt

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — -

Name Target State Server State details

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — -

Local Resources

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — -

ora.LISTENER.lsnr

ONLINE ONLINE chiexa01dbadm01 STABLE

ONLINE ONLINE chiexa01dbadm02 STABLE

ora.chad

ONLINE ONLINE chiexa01dbadm01 STABLE

ONLINE ONLINE chiexa01dbadm02 STABLE

ora.helper

OFFLINE OFFLINE chiexa01dbadm01 STABLE

OFFLINE OFFLINE chiexa01dbadm02 IDLE,STABLE

ora.net1.network

ONLINE ONLINE chiexa01dbadm01 STABLE

ONLINE ONLINE chiexa01dbadm02 STABLE

ora.ons

ONLINE ONLINE chiexa01dbadm01 STABLE

ONLINE ONLINE chiexa01dbadm02 STABLE

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — -

Cluster Resources

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — -

ora.ASMNET1LSNR_ASM.lsnr(ora.asmgroup)

1 ONLINE ONLINE chiexa01dbadm01 STABLE

2 ONLINE ONLINE chiexa01dbadm02 STABLE

ora.DATAC1.dg(ora.asmgroup)

1 ONLINE ONLINE chiexa01dbadm01 STABLE

2 ONLINE ONLINE chiexa01dbadm02 STABLE

ora.LISTENER_SCAN1.lsnr

1 ONLINE ONLINE chiexa01dbadm01 STABLE

ora.LISTENER_SCAN2.lsnr

1 ONLINE ONLINE chiexa01dbadm01 STABLE

ora.LISTENER_SCAN3.lsnr

1 ONLINE ONLINE chiexa01dbadm02 STABLE

ora.RECOC1.dg(ora.asmgroup)

1 ONLINE ONLINE chiexa01dbadm01 STABLE

2 ONLINE ONLINE chiexa01dbadm02 STABLE

ora.asm(ora.asmgroup)

1 ONLINE ONLINE chiexa01dbadm01 Started,STABLE

2 ONLINE ONLINE chiexa01dbadm02 Started,STABLE

ora.asmnet1.asmnetwork(ora.asmgroup)

1 ONLINE ONLINE chiexa01dbadm01 STABLE

2 ONLINE ONLINE chiexa01dbadm02 STABLE

ora.cdb1.cdb1_pdb1.svc

1 ONLINE ONLINE chiexa01dbadm01 STABLE

2 ONLINE ONLINE chiexa01dbadm02 STABLE

ora.cdb1.cdb1_pdb1_svc.svc

1 ONLINE ONLINE chiexa01dbadm01 STABLE

2 ONLINE ONLINE chiexa01dbadm02 STABLE

ora.cdb1.db

1 ONLINE ONLINE chiexa01dbadm02 Open,HOME=/u01/app/oracle/product/23.0.0.0/dbhome_1,STABLE

2 ONLINE ONLINE chiexa01dbadm01 Open,HOME=/u01/app/oracle/product/23.0.0.0/dbhome_1,STABLE

ora.cdb1.pdb1.pdb

1 ONLINE ONLINE chiexa01dbadm01 READ WRITE,STABLE

2 ONLINE ONLINE chiexa01dbadm02 READ WRITE,STABLE

ora.cdp1.cdp

1 ONLINE ONLINE chiexa01dbadm01 STABLE

ora.cdp2.cdp

1 ONLINE ONLINE chiexa01dbadm01 STABLE

ora.cdp3.cdp

1 ONLINE ONLINE chiexa01dbadm02 STABLE

ora.cvu

1 ONLINE ONLINE chiexa01dbadm01 STABLE

ora.chiexa01dbadm01.vip

1 ONLINE ONLINE chiexa01dbadm01 STABLE

ora.chiexa01dbadm02.vip

1 ONLINE ONLINE chiexa01dbadm02 STABLE

ora.rhpserver

1 OFFLINE OFFLINE STABLE

ora.scan1.vip

1 ONLINE ONLINE chiexa01dbadm01 STABLE

ora.scan2.vip

1 ONLINE ONLINE chiexa01dbadm01 STABLE

ora.scan3.vip

1 ONLINE ONLINE chiexa01dbadm02 STABLE

ora.ttaicdb.db

1 ONLINE ONLINE chiexa01dbadm01 Open,HOME=/u01/app/oracle/product/23.0.0.0/dbhome_1,STABLE

2 ONLINE ONLINE chiexa01dbadm02 Open,HOME=/u01/app/oracle/product/23.0.0.0/dbhome_1,STABLE

ora.ttaicdb.ttaipdb1.pdb

2 ONLINE ONLINE chiexa01dbadm01 READ WRITE,STABLE

3 ONLINE ONLINE chiexa01dbadm02 READ WRITE,STABLE

ora.ttaicdb.ttaipdb1_app.svc

2 ONLINE ONLINE chiexa01dbadm01 STABLE

3 ONLINE ONLINE chiexa01dbadm02 STABLE

ora.ttclone.clonepdb.pdb

1 OFFLINE OFFLINE STABLE

2 OFFLINE OFFLINE STABLE

ora.ttclone.db

1 ONLINE ONLINE chiexa01dbadm02 Open,HOME=/u01/app/oracle/product/23.0.0.0/dbhome_1,STABLE

2 ONLINE ONLINE chiexa01dbadm01 Open,HOME=/u01/app/oracle/product/23.0.0.0/dbhome_1,STABLE

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — -

Compute Node Patching — Perform Prerequisite tasks

1. Validate Readiness

Run the Exadata patch precheck utility to validate the environment, confirm software compatibility, and identify any issues that must be resolved before proceeding with the upgrade.

[root@chiexa01dbadm01 ~]# cd /u01/patches/compute_node/dbserver_patch_250708

[root@chiexa01dbadm01 dbserver_patch_250708]# ./patchmgr — dbnodes /root/dbs_group — precheck — repo /u01/patches/compute_node/p38618607_241000_Linux-x86–64.zip — target_version 24.1.19.0.0.251214

2025–12–22 07:42:17 -0600 :INFO : Checking hosts connectivity via ICMP/ping

2025–12–22 07:42:19 -0600 :INFO : Hosts Reachable: [chiexa01dbadm01 chiexa01dbadm02]

2025–12–22 07:42:19 -0600 :INFO : All hosts are reachable via ICMP/ping

2025–12–22 07:42:19 -0600 :Working: Verify SSH equivalence for the root user to node(s)

2025–12–22 07:42:21 -0600 :SUCCESS: Verify SSH equivalence for the root user to node(s)

2025–12–22 07:42:26 -0600 :Working: Initiate precheck on 2 node(s)

2025–12–22 07:42:29 -0600 :INFO : Preparing nodes: chiexa01dbadm01 chiexa01dbadm02

2025–12–22 07:42:29 -0600 :Working: Check for enough free space on node(s) to transfer and unzip files.

2025–12–22 07:42:36 -0600 :SUCCESS: Check for enough free space on node(s) to transfer and unzip files.

2025–12–22 07:43:29 -0600 :Working: dbnodeupdate.sh running a precheck for the conventional update on node(s).

2025–12–22 07:47:28 -0600 :INFO : Node chiexa01dbadm01 will not be Live Updated.

2025–12–22 07:47:38 -0600 :INFO : Node chiexa01dbadm02 will not be Live Updated.

2025–12–22 07:47:47 -0600 :SUCCESS: Initiate precheck on node(s).

2025–12–22 07:47:48 -0600 :SUCCESS: Completed run of command: ./patchmgr — dbnodes /root/dbs_group — precheck — repo /u01/patches/compute_node/p38618607_241000_Linux-x86–64.zip — target_version 24.1.19.0.0.251214

2025–12–22 07:47:48 -0600 :INFO : Precheck performed on dbnode(s) in file /root/dbs_group: [chiexa01dbadm01 chiexa01dbadm02]

2025–12–22 07:47:48 -0600 :INFO : Current image version on dbnode(s) is:

2025–12–22 07:47:48 -0600 :INFO : chiexa01dbadm01: 24.1.17.0.0.251012.1

2025–12–22 07:47:48 -0600 :INFO : chiexa01dbadm02: 24.1.17.0.0.251012.1

2025–12–22 07:47:48 -0600 :INFO : For details, check the following files in /u01/patches/compute_node/dbserver_patch_250708:

2025–12–22 07:47:48 -0600 :INFO : — <dbnode_name>_dbnodeupdate.log

2025–12–22 07:47:48 -0600 :INFO : — patchmgr.log

2025–12–22 07:47:48 -0600 :INFO : — patchmgr.trc

2025–12–22 07:47:49 -0600 :INFO : Exit status:0

2025–12–22 07:47:49 -0600 :INFO : Exiting.

[root@chiexa01dbadm01 dbserver_patch_250708]#

Note: This command performs a comprehensive readiness assessment by validating connectivity, software compatibility, disk space, system configuration, and other prerequisites required for a successful Exadata compute node upgrade.

2. Unmount Active NFS Filesystems

If any NFS filesystems are mounted, unmount them before patching. Active network filesystems may interfere with the update process and cause precheck failures.

3. Verify Oracle Clusterware Health

Ensure Oracle Clusterware is healthy before beginning the maintenance activity.

[root@chiexa01dbadm01 dbserver_patch_250708]# /u01/app/23.0.0.0/grid/bin/crsctl check crs

CRS-4638: Oracle High Availability Services is online

CRS-4537: Cluster Ready Services is online

CRS-4529: Cluster Synchronization Services is online

CRS-4533: Event Manager is online

4. Stop Oracle Clusterware

Disable automatic Clusterware startup and gracefully stop the Clusterware stack on the compute node before initiating the operating system upgrade.

[root@chiexa01dbadm01 dbserver_patch_250708]# /u01/app/23.0.0.0/grid/bin/crsctl disable crs

CRS-4621: Oracle High Availability Services autostart is disabled.

[root@chiexa01dbadm01 dbserver_patch_250708]# /u01/app/23.0.0.0/grid/bin/crsctl stop crs -f

CRS-2791: Starting shutdown of Oracle High Availability Services-managed resources on ‘chiexa01dbadm01’

CRS-2673: Attempting to stop ‘ora.crsd’ on ‘chiexa01dbadm01’

CRS-2790: Starting shutdown of Cluster Ready Services-managed resources on server ‘chiexa01dbadm01’

.

.

CRS-2677: Stop of ‘ora.gipcd’ on ‘chiexa01dbadm01’ succeeded

CRS-2677: Stop of ‘ora.diskmon’ on ‘chiexa01dbadm01’ succeeded

CRS-2793: Shutdown of Oracle High Availability Services-managed resources on ‘chiexa01dbadm01’ has completed

CRS-4133: Oracle High Availability Services has been stopped.

[root@chiexa01dbadm01 dbserver_patch_250708]#

[root@chiexa01dbadm01 dbserver_patch_250708]# /u01/app/23.0.0.0/grid/bin/crsctl check crs

CRS-4639: Could not contact Oracle High Availability Services

Compute Node Patching

After completing all prerequisite validations, apply the Exadata compute node image update.

1. Create System Backup

Create a backup of the current system configuration before starting the upgrade. This provides a recovery point if required.

[root@chiexa01dbadm01 dbserver_patch_250708]# lvdisplay

— — Logical volume — -

LV Path /dev/VGExaDb/LVDbSys1

LV Name LVDbSys1

VG Name VGExaDb

LV Status available

LV Size 30.00 GiB

— — Logical volume — -

LV Path /dev/VGExaDb/LVDbSys2

LV Name LVDbSys2

LV Status available

LV Size 30.00 GiB

[root@chiexa01dbadm01 dbserver_patch_250708]# ./dbnodeupdate.sh -b -s -a

(*) 2025–12–22 07:51:32: Initializing logfile /var/log/cellos/dbnodeupdate.log

Continue ? [y/n] y

(*) 2025–12–22 07:52:00: Performing filesystem backup to /dev/mapper/VGExaDb-LVDbSys2. Average 30 minutes (maximum of 120) depends per environment………………………………………………………………

(*) 2025–12–22 07:58:14: Backup successful

(*) 2025–12–22 07:58:16: Backup-only run finished.

You have new mail in /var/spool/mail/root

[root@chiexa01dbadm01 dbserver_patch_250708]#

Note: This backup can be used for recovery if the upgrade needs to be rolled back.

2. Apply the Exadata Image Update

Apply the target Exadata image using the dbnodeupdate.sh utility. The utility updates the operating system, Oracle Linux packages, drivers, and other supported components.

[root@chiexa01dbadm01 dbserver_patch_250708]# ./dbnodeupdate.sh -u -l /u01/patches/compute_node/p38618607_241000_Linux-x86–64.zip -t 24.1.19.0.0.251214 -a -v -M

(*) 2025–12–22 07:58:59: Initializing logfile /var/log/cellos/dbnodeupdate.log

Continue ? [y/n] y

(*) 2025–12–22 07:59:09: Analyzing system configuration.

(*) 2025–12–22 08:00:20: Validating system settings for known issues and best practices. This may take a while…

(*) 2025–12–22 08:00:21: Checking free space in /u01/patches/compute_node/iso.stage

(*) 2025–12–22 08:00:21: Unzipping /u01/patches/compute_node/p38618607_241000_Linux-x86–64.zip to /u01/patches/compute_node/iso.stage

(*) 2025–12–22 08:00:58: Adding Exadata repository info to /var/log/exadatatmp/dnf.221225075900.conf

(*) 2025–12–22 08:01:43: Validating the specified source location.

(*) 2025–12–22 08:01:46: Cleaning up the dnf cache.

(*) 2025–12–22 08:01:47: Performing dnf package dependency check for ‘exact’ dependencies. This may take a while…

(*) 2025–12–22 08:02:06: ‘Exact’ package dependency check succeeded.

(*) 2025–12–22 08:02:06: ‘Minimum’ package dependency check succeeded.

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — -

Running in prereq check mode.

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — -

Active Image version : 24.1.17.0.0.251012.1

Active Kernel version : 5.4.17–2136.343.5.6.el8uek

Active LVM Name : /dev/mapper/VGExaDb-LVDbSys1

Inactive Image version : 24.1.17.0.0.251012.1

Inactive LVM Name : /dev/mapper/VGExaDb-LVDbSys2

Current user id : root

Action : upgrade

Upgrading to : 24.1.19.0.0.251214 (to exadata-sun-computenode-exact)

Baseurl : file:///var/www/html/yum/unknown/EXADATA/dbserver/221225075900/x86_64/ (iso)

Iso file : /u01/patches/compute_node/iso.stage/exadata_ol8_base_repo_24.1.19.0.0.251214.iso

Create a backup : Yes

Shutdown EM agents : Yes

Shutdown stack : No (Currently stack is down)

Missing package files : Warning. See /var/log/cellos/dbnodeupdate_missing_package_files.221225075900.txt for details.

RPM obsolete lists : /etc/exadata/yum/obsolete_nodeps.lst, /etc/exadata/yum/obsolete.lst (lists rpms to be removed by the update)

: RPM obsolete list is extracted from exadata-sun-computenode-24.1.19.0.0.251214–1.noarch.rpm

Exact dependencies : No conflicts

Minimum dependencies : No conflicts

Logfile : /var/log/cellos/dbnodeupdate.log (runid: 221225075900)

Diagfile : /var/log/cellos/dbnodeupdate.221225075900.diag

Server model : ORACLE SERVER X6–2

dbnodeupdate.sh rel. : 25.250708 (always check MOS 1553103.1 for the latest release of dbnodeupdate.sh)

Exadata Live Update : No

Note : After upgrading and rebooting run ‘./dbnodeupdate.sh -c’ to finish post steps.

WARNING: Active image version is equal to inactive image version (backup already made).

Use -n to disable backup or let dbnodeupdate.sh overwrite.

Recommended : Keep the existing backup on the inactive lvm and skip the new backup, run :

./dbnodeupdate.sh -u -l /u01/patches/compute_node/p38618607_241000_Linux-x86–64.zip -n

Alternatively : Continue this run and have dbnodeupdate.sh overwrite the existing backup on the inactive lvm automatically

Prereq check finished successfully, check the above report for next steps.

(*) 2025–12–22 08:02:15: Cleaning up iso and temp mount points

3. Finalize the Update

Complete the remaining update tasks and prepare the compute node for reboot.

[root@chiexa01dbadm01 dbserver_patch_250708]# ./dbnodeupdate.sh -u -l /u01/patches/compute_node/p38618607_241000_Linux-x86–64.zip -t 24.1.19.0.0.251214 -a -n

(*) 2025–12–22 08:03:28: Initializing logfile /var/log/cellos/dbnodeupdate.log

Continue ? [y/n] y

(*) 2025–12–22 08:03:38: Analyzing system configuration.

(*) 2025–12–22 08:04:49: Validating system settings for known issues and best practices. This may take a while…

(*) 2025–12–22 08:04:50: Checking free space in /u01/patches/compute_node/iso.stage

(*) 2025–12–22 08:04:50: Unzipping /u01/patches/compute_node/p38618607_241000_Linux-x86–64.zip to /u01/patches/compute_node/iso.stage

(*) 2025–12–22 08:05:28: Adding Exadata repository info to /var/log/exadatatmp/dnf.221225080329.conf

(*) 2025–12–22 08:06:11: Validating the specified source location.

(*) 2025–12–22 08:06:14: Cleaning up the dnf cache.

(*) 2025–12–22 08:06:18: Performing dnf package dependency check for ‘exact’ dependencies. This may take a while…

(*) 2025–12–22 08:06:36: ‘Exact’ package dependency check succeeded.

(*) 2025–12–22 08:06:36: ‘Minimum’ package dependency check succeeded.

Active Image version : 24.1.17.0.0.251012.1

Active Kernel version : 5.4.17–2136.343.5.6.el8uek

Active LVM Name : /dev/mapper/VGExaDb-LVDbSys1

Inactive Image version : 24.1.17.0.0.251012.1

Inactive LVM Name : /dev/mapper/VGExaDb-LVDbSys2

Current user id : root

Action : upgrade

Upgrading to : 24.1.19.0.0.251214 (to exadata-sun-computenode-exact)

Baseurl : file:///var/www/html/yum/unknown/EXADATA/dbserver/221225080329/x86_64/ (iso)

Iso file : /u01/patches/compute_node/iso.stage/exadata_ol8_base_repo_24.1.19.0.0.251214.iso

Create a backup : No

Shutdown EM agents : Yes

Shutdown stack : No (Currently stack is down)

Missing package files : Warning. See /var/log/cellos/dbnodeupdate_missing_package_files.221225080329.txt for details.

RPM obsolete lists : /etc/exadata/yum/obsolete_nodeps.lst, /etc/exadata/yum/obsolete.lst (lists rpms to be removed by the update)

: RPM obsolete list is extracted from exadata-sun-computenode-24.1.19.0.0.251214–1.noarch.rpm

Exact dependencies : No conflicts

Minimum dependencies : No conflicts

Logfile : /var/log/cellos/dbnodeupdate.log (runid: 221225080329)

Diagfile : /var/log/cellos/dbnodeupdate.221225080329.diag

Server model : ORACLE SERVER X6–2

dbnodeupdate.sh rel. : 25.250708 (always check MOS 1553103.1 for the latest release of dbnodeupdate.sh)

Exadata Live Update : No

Note : After upgrading and rebooting run ‘./dbnodeupdate.sh -c’ to finish post steps.

Continue ? [y/n] y

(*) 2025–12–22 08:09:59: Unmount of /boot successful

(*) 2025–12–22 08:09:59: Mount of /boot successful

(*) 2025–12–22 08:12:26: EM agent in /u01/app/oem/product/emagent/GoldImage_xa135r27_250826/agent_13.5.0.0.0 stopped

(*) 2025–12–22 08:12:26: Auto-start of EM agents disabled

(*) 2025–12–22 08:12:29: MS stopped successful

(*) 2025–12–22 08:12:29: Validating the specified source location.

(*) 2025–12–22 08:12:29: Cleaning up the dnf cache.

(*) 2025–12–22 08:12:34: Performing dnf update. Node is expected to reboot when finished.

Exadata post install steps started.

It may take up to 15 minutes.

(*) 2025–12–22 08:18:39: Waiting for post rpm script to finish. Sleeping another 30 seconds (60 / 900)

Exadata post install steps completed.

(*) 2025–12–22 08:19:09: Waiting for post rpm script to finish. Sleeping another 30 seconds (90 / 900)

(*) 2025–12–22 08:19:41: All post steps are finished.

(*) 2025–12–22 08:19:41: System will reboot automatically for changes to take effect

(*) 2025–12–22 08:19:41: After reboot run “./dbnodeupdate.sh -c” to complete the upgrade

(*) 2025–12–22 08:19:41: Cleaning up iso and temp mount points

(*) 2025–12–22 08:19:43: Rebooting in 30 seconds.

Rebooting.

Post-Reboot Validation

Once the compute node reboots, perform the following validation steps to ensure the patch was applied successfully.

1. Complete Post-Upgrade Configuration

Run the post-configuration utility to finalize the update and perform any remaining configuration tasks.

[root@chiexa01dbadm01 ~]# uptime

08:32:50 up 9 min, 1 user, load average: 0.31, 0.88, 0.69

[root@chiexa01dbadm01 ~]# cd /u01/patches/compute_node/dbserver_patch_250708

[root@chiexa01dbadm01 dbserver_patch_250708]# ./dbnodeupdate.sh -c

(*) 2025–12–22 08:35:01: Initializing logfile /var/log/cellos/dbnodeupdate.log

Continue ? [y/n] y

(*) 2025–12–22 08:35:14: Analyzing system configuration.

Active Image version : 24.1.19.0.0.251214

Active Kernel version : 5.4.17–2136.343.5.6.el8uek

Active LVM Name : /dev/mapper/VGExaDb-LVDbSys1

Inactive Image version : 24.1.17.0.0.251012.1

Inactive LVM Name : /dev/mapper/VGExaDb-LVDbSys2

Current user id : root

Action : finish-post cleanup and enable crs to auto-start)

Shutdown stack : No (Currently stack is down)

Logfile : /var/log/cellos/dbnodeupdate.log (runid: 221225083501)

Diagfile : /var/log/cellos/dbnodeupdate.221225083501.diag

Server model : ORACLE SERVER X6–2

dbnodeupdate.sh rel. : 25.250708 (always check MOS 1553103.1 for the latest release of dbnodeupdate.sh)

Exadata Live Update : No

Continue ? [y/n] y

(*) 2025–12–22 08:36:40: Running validations. Maximum wait time: 60 minutes.

(*) 2025–12–22 08:36:40: If the node reboots, re-run ‘./dbnodeupdate.sh -c’ after the node restarts..

(*) 2025–12–22 08:36:44: Service acpid enabled to autostart at boot

(*) 2025–12–22 08:36:44: Not Relinking oracle homes

(*) 2025–12–22 08:36:46: Starting Grid Infrastructure (/u01/app/23.0.0.0/grid)

(*) 2025–12–22 08:37:52: Stack started

(*) 2025–12–22 08:37:53: TFA Started

(*) 2025–12–22 08:37:53: Enabling stack to start at reboot. Disable this when the stack should not be starting on a next boot

(*) 2025–12–22 08:37:53: Auto-start of EM agents enabled

(*) 2025–12–22 08:37:53: Retained the required kernel-transition package:

(*) 2025–12–22 08:38:07: All post steps are finished.

[root@chiexa01dbadm01 dbserver_patch_250708]#

2. Verify Oracle Clusterware and enable auto start

Confirm that Oracle Clusterware has started successfully and that all required services are online.

[root@chiexa01dbadm01 dbserver_patch_250708]# /u01/app/23.0.0.0/grid/bin/crsctl check crs

CRS-4638: Oracle High Availability Services is online

CRS-4537: Cluster Ready Services is online

CRS-4529: Cluster Synchronization Services is online

CRS-4533: Event Manager is online

3. Validate Cluster Resources

Verify that all Clusterware resources, databases, listeners, ASM instances, and VIPs have returned to their expected state.

[root@chiexa01dbadm01 dbserver_patch_250708]# ps -ef |grep -i d.bin

root 175574 1 0 08:37 ? 00:00:00 /u01/app/23.0.0.0/grid/bin/orarootagent.bin

grid 175743 1 0 08:37 ? 00:00:00 /u01/app/23.0.0.0/grid/bin/oraagent.bin

.

.

grid 178520 1 0 08:37 ? 00:00:00 /u01/app/23.0.0.0/grid/bin/crscdpd.bin

[root@chiexa01dbadm01 dbserver_patch_250708]# ps -ef |grep -i pmon

grid 177282 1 0 08:37 ? 00:00:00 asmpmon+ASM1

oracle 178819 1 0 08:37 ? 00:00:00 ora_pmon_cdb11

oracle 178820 1 0 08:37 ? 00:00:00 ora_pmon_ttaicdb1

oracle 178848 1 0 08:37 ? 00:00:00 ora_pmon_ttclone1

4. Verify Exadata Image Version

Confirm that the compute node is now running the target Exadata image version.

[root@chiexa01dbadm01 ~]# imageinfo

Kernel version: 5.4.17–2136.343.5.6.el8uek.x86_64 #3 SMP Tue Sep 23 05:49:58 PDT 2025 x86_64

Uptrack kernel version: 5.4.17–2136.349.3.1.el8uek.x86_64 #3 SMP Sat Nov 1 13:40:27 PDT 2025 x86_64

Image kernel version: 5.4.17–2136.343.5.6.el8uek

Image version: 24.1.19.0.0.251214

Image activated: 2025–12–22 08:25:32 -0600

Image status: success

Exadata software version: 24.1.19.0.0.251214

Node type: COMPUTE

System partition on device: /dev/mapper/VGExaDb-LVDbSys1

[root@chiexa01dbadm02 ~]# dcli -g dbs_group -l root imageinfo -version

chiexa01dbadm01: 24.1.19.0.0.251214

chiexa01dbadm02: 24.1.17.0.0.251012.1

Note: The output confirms that Compute Node 1 has been successfully upgraded to the target Exadata image version (24.1.19.0.0.251214), while Compute Node 2 is still running the previous image version (24.1.17.0.0.251012.1). This is the expected state during a rolling patching operation.

5. Validate Database Services

Verify that all database instances, listeners, and application services are running normally before proceeding to patch the next compute node.

Patch Compute Node 2 — chiexa01dbadm02

After successfully completing the patching and validation of Compute Node 1, repeat the same sequence of prechecks, patching tasks, reboot, and post-patching validation on Compute Node 2. Oracle recommends a rolling patching approach to maintain cluster availability and minimize application downtime.

What’s Next

In the next article of this series, we will explore how to perform rolling Exadata Storage Server (Cell) patching using patchmgr, including prerequisite validation, storage cell updates, and post-patching health checks. We will then cover Exadata Live Update, which enables security and kernel updates with minimal or no downtime.