# Zero Downtime Monitoring in OEM 24ai: Patching Your OMS Without Going Blind If you've run OEM long enough, you know the drill. Release Update ships, you schedule a maintenance window, you take the OMS down, you patch it, and for however long that takes — twenty minutes, two hours, whatever your environment's patch history looks like — you're flying blind. No alerts. No incidents. No notifications. If a RAC node evicts or a tablespace fills up at 2:47 AM during that window, OEM simply isn't watching. Most shops manage that risk with a change window nobody schedules on a Friday, a manual "watch it closely for the next hour" from whoever owns the on-call phone, and a little bit of hope. That's not a knock on anyone — it's just been the reality of patching the tool that watches everything else. EM 24ai changes that equation with something Oracle calls Zero Downtime (ZDT) Monitoring, and it's been maturing steadily across the Release Update cadence through 2026 — RU07 in January, RU08 in April, RU09 in May, RU10 in June. If you're still planning your RU upgrades around a monitoring blackout, this is the feature that makes that planning obsolete. ## The Problem ZDT Monitoring Actually Solves Patching an OMS has always meant two things happen at once: the console goes away, and — critically — the event and notification pipeline goes away with it. Alerts stop being received, incident rule sets stop firing, notifications stop going out. For a single mission-critical database or a small footprint, that's tolerable. For an estate with a few hundred targets and a 24x7 SLA, a multi-hour blackout during every RU cycle is a real exposure, and it's the reason plenty of customers I've worked with simply stop patching OEM as often as they should. ## What ZDT Monitoring Actually Is The Zero Downtime Monitoring Service is a separate component of the OMS, introduced in EM 24ai, dedicated to exactly one job: keeping event management, incident management, and notifications running regardless of what's happening to the rest of the OMS stack. Per Oracle's documentation, it handles: - Receiving alerts from Management Agents - Executing everything defined in your Incident Rule Sets — incident creation, event compression, incident property changes, notification dispatch - Event compression via your Event Compression Policies - Notification delivery across email, SNMP traps, OS command, webhooks, and Slack - Ticket creation through your Ticketing connectors - Sending events out to external systems via Event Connectors - Priority processing based on target Lifecycle Status The key architectural point: this runs as a separate service from the core OMS. When you patch one OMS in a multi-OMS deployment, the ZDT Monitoring Service on the other OMS keeps the lights on for event processing while the first one is being worked on. Nothing gets missed, nothing queues up waiting for the OMS to come back — it's actively processing the whole time. One thing worth flagging up front: this only works if you have two or more OMS instances. Single-OMS deployments don't get this benefit — patching still means a monitoring gap, same as before. If you've been putting off the multi-OMS conversation because your estate "isn't that big," ZDT Monitoring is one more reason to have it. ## How the Patching Workflow Actually Works ZDT Patching uses the `omspatcher` utility, and under the hood it leans on Oracle Database Edition-Based Redefinition (EBR) to update the EM repository schema in a separate edition while the database keeps serving the live edition. That's what lets the repository stay usable mid-patch instead of locking everything for a schema upgrade. The workflow breaks into four stages: Analyze, Deploy, Update, Verify. > **Note:** EM CLI syntax below is representative. Exact parameter names vary by OEM version and job type. Always validate against your environment: `emcli help ` and Oracle's official EM CLI reference. The commands below are `omspatcher` invocations, not `emcli`, but the same caveat applies — confirm exact syntax and options against your specific RU's patch README before running anything in production. ```plaintext # Analyze stage — check for patch conflicts before touching anything omspatcher deploy-analyze -phBaseDir # Deploy stage — stages the patch artifacts on OMS and repository # while OMS stays up and continues monitoring omspatcher deploy -phBaseDir # Update stage — applies the update; console is briefly unavailable here omspatcher update -phBaseDir # Check progress or completion status at any point omspatcher status # If something fails mid-patch, resume rather than starting over omspatcher resume # If you need to back out the deploy stage omspatcher rollback deploy -phBaseDir ``` The one moment where you do lose the console is during the Update stage itself — users hitting the EM console at that exact point get a "maintenance in progress" message. That's expected and brief. Monitoring, alerting, and notification keep running on the other OMS the entire time; it's only the UI that pauses. In a multi-OMS setup, OEM patches nodes in a rolling fashion — one OMS at a time — which is exactly what keeps the monitoring gap from ever opening in the first place. ## Checking Your ZDT Monitoring Posture Before You Patch Before you schedule your next RU cycle, confirm two things: how many OMS instances you're actually running, and whether your load balancer is set up to route around whichever node is mid-patch. Neither of those is a ZDT Monitoring setting — there's nothing to "turn on" — but both determine whether you get the benefit. > **Note:** EM CLI syntax below is representative. Exact parameter names vary by OEM version and job type. Always validate against your environment: `emcli help ` and Oracle's official EM CLI reference. ```plaintext # Confirm OMS topology and host/port details for each management server emctl status oms -details # From the OEM console: Setup -> Manage Cloud Control -> Management Servers # shows the same topology view plus per-OMS status and load ``` If that command comes back with a single OMS listed, ZDT Monitoring isn't going to help you on your next patch cycle — you're still looking at a blackout window, and the conversation to have internally is whether a second OMS is worth the license and hardware cost against the SLA risk you're carrying today. For most estates north of a couple hundred targets, that math works out in favor of the second OMS pretty quickly. ## Where This Fits With Always-On Monitoring (AOM) If you've used Always-On Monitoring before, don't confuse the two. AOM is specifically for the 13.5-to-24ai upgrade path — it sends email notifications for critical alerts during that one-time migration, when ZDT Monitoring isn't available yet because you're not on 24ai. Once you're running EM 24ai and applying RU after RU, you're on ZDT Monitoring and you no longer need AOM. Different tool, different phase of the lifecycle. I've seen teams keep AOM configured well past their 24ai cutover out of habit — worth checking whether that's still buying you anything now. Also worth knowing: ZDT Patching covers standard Release Updates. Holistic patching — the broader out-of-cycle patch bundle some environments use — is not a ZDT operation, though it can still be applied in a rolling manner across OMS nodes to shrink the window. Don't assume every patching path gets the zero-downtime treatment; check which one you're running before you set expectations with your stakeholders. One more edge case: targets already in a blackout stay in blackout through the patch cycle. ZDT Monitoring isn't overriding your blackout windows — it resumes normal monitoring for those targets once the blackout ends, same as it always would. ## What Good Looks Like A well-run RU cycle on EM 24ai with ZDT Monitoring looks like this: you run `omspatcher deploy-analyze` a few days ahead to catch conflicts early, you schedule the deploy and update stages in a normal (not heroic) maintenance window, your incident rule sets and notification channels never stop firing, and the only visible impact to your team is a short console outage during the update stage itself — no blackout, no manual "watch it closely" hand-off, no gap in your incident history when you go back and review what happened during the patch window. A few markers I look for when I'm reviewing a customer's patching posture: - Two or more OMS instances behind a load balancer that can route around a node mid-patch - Incident rule sets and notification methods tested independently of a patch cycle, so you know they work before you're relying on them during one - AOM configuration retired once the 13.5-to-24ai migration is behind you — it has no job left to do - A documented rollback point (`omspatcher rollback deploy`) before every Deploy stage, not just when something looks risky - Blackout windows reviewed ahead of the patch so you're not surprised by targets that silently stayed dark If your last few RU cycles didn't hit those markers, the gap is almost always a single-OMS deployment or an AOM habit that never got retired. ## The Bottom Line ZDT Monitoring is one of those features that doesn't show up in a demo as impressively as an AI-driven dashboard, but it directly fixes an operational pain every OEM admin has lived with: patching the thing that watches your estate used to mean nobody was watching your estate. If you're on EM 24ai and still scheduling monitoring blackouts for your RU cycles, that's a configuration gap, not a product limitation — check your OMS count and your incident rule sets before your next patch window.