ZDM ships frequent one-off patches, and Oracle Support will generally ask for the current patch level before troubleshooting any migration issue — so keeping a ZDM host patched isn’t optional maintenance, it’s a prerequisite for getting help when something goes wrong mid-migration. This walks through patching an existing install from 21.6.0 to 21.6.3.

Prerequisites

  • At least 15 GB free storage — the patch process backs up the existing ZDM_HOME and ZDM_BASE before applying anything, and those backups land in the directory you run the patch from.
  • The zdmuser account needs write access to the path passed as ziploc.
  • No active migration jobs should be running against this ZDM host during the patch — check zdmcli query job first if you’re not sure.

Step 1: Check the Current Version

Always confirm the starting point before patching — it’s the only way to be certain the patch actually did something afterward:

$ZDM_HOME/bin/zdmcli -build

version: 21.0.0.0.0
full version: "21.6.0"
patch version: "21.6.0"
label date: 260112.10
ZDM kit build date: Feb 02 2026 14:11:03 UTC
CPAT build version: 26.1.0

patch version: "21.6.0" is the number that matters here — that’s what we’re changing.

Step 2: Check for Active Jobs

Patching mid-migration is asking for trouble — the ZDM service gets bounced as part of the process, which will interrupt anything currently orchestrating a Data Guard switch or a GoldenGate cutover:

$ZDM_HOME/bin/zdmcli query job

If anything shows EXECUTING, wait for it to reach a pausable state (or complete) before continuing.

Step 3: Download the Patch

Get the current ZDM patch from My Oracle Support — search for the ZDM patch conflict/current-patch note under the ZDM product family, since the patch number changes with every release train. Confirm the patch’s release notes explicitly state it targets your currently installed base version; applying a patch built for a different base version is a common and entirely avoidable mistake.

Step 4: Stage and Apply

mkdir -p /u01/zdm/zdmpatch
# transfer the patch zip here

su - zdmuser
cd /u01/zdm/zdmpatch
unzip p_zdm_21_6_3_patch.zip

Run the update from outside the current ZDM_HOME — this is a hard requirement, not a style preference, since the install script needs to replace files inside the home it’s updating:

./zdminstall.sh update oraclehome=$ZDM_HOME ziploc=$PWD/zdm_home.zip

The script writes two backup archives into the directory it’s run from before touching anything:

oldbase.zip
oldhome.zip

Keep these until you’ve verified the patch and run at least one test migration job successfully — they’re the rollback path if something goes wrong.

Step 5: Restart the Service

$ZDM_HOME/bin/zdmservice stop
$ZDM_HOME/bin/zdmservice start

Verifying the Patch

$ZDM_HOME/bin/zdmservice status

---------------------------------------
	Service Status
---------------------------------------

 Running: 	true
 Tranferport:
 Conn String: 	jdbc:mysql://localhost:8900/
 RMI port: 	8897
 HTTP port: 	8898
 Wallet path: 	/u01/zdm/zdmbase/crsdata/zdmhost/security

Then confirm the version actually moved:

$ZDM_HOME/bin/zdmcli -build

version: 21.0.0.0.0
full version: "21.6.0"
patch version: "21.6.3"
label date: 260112.14
ZDM kit build date: Mar 09 2026 08:40:51 UTC
CPAT build version: 26.3.0

patch version reads 21.6.3 — the patch applied cleanly. If it still shows the pre-patch version after a successful-looking run, the service almost certainly wasn’t restarted from the correct ZDM_HOME, or the update command was run from inside the home instead of outside it.

Rolling Back

If a patch causes problems, restore from the backups the update step created rather than trying to hand-fix files:

$ZDM_HOME/bin/zdmservice stop
cd /u01/zdm/zdmpatch
mv $ZDM_HOME ${ZDM_HOME}.broken
mv $ZDM_BASE ${ZDM_BASE}.broken
unzip oldhome.zip -d $(dirname $ZDM_HOME)
unzip oldbase.zip -d $(dirname $ZDM_BASE)
$ZDM_HOME/bin/zdmservice start

Confirm with zdmcli -build that the version reverted before resuming any migration work.