ora-base

A ZDM host tends to get used in short, frequent bursts — check if the service is up, check a job’s status, tail a log, confirm a wallet credential exists — usually while something else is waiting on the outcome. Typing full zdmcli/zdmservice invocations every time adds friction that’s easy to eliminate with a properly built .bash_profile. This one is built around three things: an always-visible service status in the prompt, one-word shortcuts for the commands used constantly, and functions for the ones used occasionally but painfully without them. ...

The previous investigation had an abend and an error code to start from. This one is harder precisely because there isn’t one — Replicat is running, lag is zero, the report file is clean, and yet a nightly reconciliation job is flagging rows where the target’s EMAIL column contains what looks like a phone number. When replication looks completely healthy but the data is wrong, the investigation has to start from the data itself, not from a log. ...

The previous two posts walked through specific investigations. This one is the reference behind them — the Logdump commands worth knowing well, plus the tricks that separate a five-minute trail file check from an hour of scrolling through raw hex. 1. Session Setup: Get Readable Output First The default Logdump view is barely usable — raw hex with minimal structure. Every session should start the same way: Logdump 1 > OPEN ./dirdat/rt000412 Logdump 2 > GHDR ON Logdump 3 > DETAIL DATA Logdump 4 > USETOKEN ON Command What it does Skip it and you get GHDR ON Shows the record header — timestamp, RBA, operation type Records with no context on when/what DETAIL DATA Shows actual column values, decoded Raw hex offsets only DETAIL ON (without DATA) Shows column names/lengths but not values Structure without content — useful when scanning fast USETOKEN ON Decodes GoldenGate’s internal tokens (source DB type, CSN, transaction ID) Tokens print as unreadable hex Trick: if you’re scanning hundreds of records just to find where a table’s activity starts, use DETAIL ON without DATA — it’s faster to read and enough to spot the record you actually want, then flip to DETAIL DATA once you’re near it. ...

Classic GoldenGate has one entry point: GGSCI. Microservices has three — adminclient (a scriptable CLI purpose-built for MA), direct REST calls, and the Service Manager Web UI. This post covers the CLI and REST paths for the operations you’ll do constantly: connecting to a deployment, seeing what’s running, and setting up database connections that Extract and Replicat processes can reuse. 1. Connecting with Adminclient adminclient ships alongside the Microservices install and is the closest equivalent to opening GGSCI — except it talks to the Service Manager over REST instead of operating on local files directly. ...

GoldenGate replication has three stages, and each one fails differently under load: Extract can fall behind on redo mining, the Pump/Distribution path can saturate the network, and Replicat can bottleneck applying changes to the target. Tuning the wrong stage wastes time and rarely moves the needle — the first job is always figuring out where the lag actually is. 1. Locate the Bottleneck Before Touching Parameters Every tuning exercise starts with LAG and INFO, not with changing parameters blindly. ...

When Replicat abends, the error message tells you what failed, but rarely why. INFO REPLICAT and the report file point you at a table and an error code — to actually understand the data that caused it, you need to open the trail file itself with Logdump, GoldenGate’s trail-file inspection utility. This post walks through a real investigation end to end, from the initial abend to the actual root cause sitting inside the raw record bytes. ...

Zero Downtime Migration (ZDM) is Oracle’s orchestration engine for physical and logical database migrations into OCI — it doesn’t move data itself so much as drive Data Guard, RMAN, Data Pump, and GoldenGate through a coordinated migration workflow. Before any of that, though, ZDM needs its own service host set up correctly. This walks through that installation end to end. Prerequisites ZDM host placement. The ZDM service can run on an OCI compute instance, an on-premises server, or a VM in another cloud — the only hard requirement is network reachability to both the source and target database hosts. It does not need to sit on either database server itself, and in most real deployments it shouldn’t. ...

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

Run a ZDM migration job interactively and it will stop repeatedly to ask for passwords — source admin, target admin, GoldenGate admin, TDE keystore, and more, depending on the migration type. That’s fine for a one-off manual run, but it breaks entirely once ZDM is kicked off from a scheduler, a CI/CD pipeline, or an unattended runbook. The fix is wallet-based credential storage: ZDM reads passwords from an Oracle wallet instead of prompting for them. ...

This article picks up where the networking and storage setup left off. The Proxmox host (pve01.lab.example.com) is running with two VLAN-aware bridges, a ZFS mirror pool (vmpool), and shared ASM zvols already created. We now create all ten VMs using the qm CLI, configure shared storage for RAC, and verify each group before installing Oracle software. 1. VM Inventory and Resource Plan VM ID Hostname Role vCPU RAM OS Disk Notes 100 rac1-node1 RAC Cluster 1, Node 1 8 32 GB 80 GB Shared ASM 101 rac1-node2 RAC Cluster 1, Node 2 8 32 GB 80 GB Shared ASM 110 rac2-node1 RAC Cluster 2, Node 1 8 32 GB 80 GB Shared ASM 111 rac2-node2 RAC Cluster 2, Node 2 8 32 GB 80 GB Shared ASM 120 oms01 Enterprise Manager OMS 1 4 24 GB 80 GB + 200 GB data Primary OMS 121 oms02 Enterprise Manager OMS 2 4 24 GB 80 GB + 200 GB data Secondary OMS 130 okv01 Oracle Key Vault Primary 4 16 GB 80 GB TDE key store 131 okv02 Oracle Key Vault Secondary 4 16 GB 80 GB Paired node 140 ogg01 GoldenGate Microservices (Extract) 4 16 GB 80 GB + 200 GB trail OGG 23ai MA 141 ogg02 GoldenGate Microservices (Replicat) 4 16 GB 80 GB + 200 GB trail OGG 23ai MA Total: 56 vCPU / 240 GB RAM — host has 32 threads and 256 GB. vCPU is intentionally overcommitted (lab workloads are not all active simultaneously). RAM headroom: 16 GB for Proxmox host. ...