Demo: Hyper-Automation of Oracle Database Change Requests

Here's the shape of it: OEM detects the problem and fires a webhook. ServiceNow turns that into a real incident, with real fields, in real time. A scheduled Ansible job — running every two minutes, unattended, forever — picks up that incident, logs in, runs the actual diagnostic SQL, checks whether it's safe to fix (more on this in a second, because this is the part that actually matters), fixes it, and writes down exactly what it did. Then OEM's own next monitoring cycle — not the robot patting itself on the back — confirms the fix actually worked, and that's what closes the ticket.

Not only automation did the work of a DBA while he was asleep, it did a better job. Usually, a sleepy Oracle DBA simply resizes the tablespace or adds a datafile. If he is an experienced professional, he will check if the storage mount where the datafile resides has enough free space for the additional space to grow. Usually. But automation is unusual. It is never sleepy. It never does a job half way. It knows nothing about the concept of "good enough". Here is what it does. It actually calculates the sum of MAXSIZE's of all datafiles in the Oracle container, all of its pluggable databases, and even all other databases mentioned in /etc/oratab. If it determines the mount will become more than 75% full once all datafiles grow to their maximum - even ten years from now - it immediately opens a ServiceNow change request with the storage team to add an additional disk space. At 3AM!

One more aspect to consider. Here is a pie chart of such OEM "Tablespace Full" alerts from an actual client (a monthly analysis).

When an administrator sees these 737 alerts, he has to act on all of them, one by one (or at least starting with the production alerts). But he lacks context. Out of the 737 alerts, 379 are related to the same issue (directly or not), but fired at different times - you resolve one you resolve them all, yet the DBA still has to sift through every single one of them! Moreover, another 233 are stale alerts because the alerting works one way, they will remain in the queue until someone manually checks whether they are still valid. It will take an inordinate amount of time for a large team to sort those out to get to the actual, actionable urgent alerts that matter. There are only 125 of those. Less than 17% of total work actually needed to be performed.

Now, lets take a look at a high level automation flowchart (OEM + Ansible + ServiceNow):

Everything this closed-loop automation does adheres to vendor's best practices, it is ITIL aligned, with cost-containment and risk management.

Ten steps. Zero humans. One very good night's sleep.

"But what if the robot breaks something?" — great question, we asked it too

This is the part I actually want you to read carefully, because it's the difference between "cool automation demo" and "thing I'd trust in production."

Before the automation touches anything, it doesn't just check "is there room to grow this one datafile." It reads /etc/oratab on the host, checks every single database living there, adds up their current footprint and their theoretical maximum footprint if every autoextensible datafile on that box decided to max out simultaneously — and only then decides whether it's actually safe to act.

This is, frankly, more thorough than most humans manage under pressure at 3 AM. It's the annoying friend who checks the stove is off twice before leaving the house — except it does this instantly, silently, and writes down exactly what it checked, every single time, whether or not anything goes wrong. If the check fails, the robot doesn't get creative. It stops, writes down exactly why, and leaves it for a human. No drama. No "I'll just try something."

Show, don't tell: this actually happened

Talk is cheap, screenshots are not. Here's a real incident, generated by a real (intentionally triggered) tablespace alert, worked entirely by the automation:

Notice this isn't a summary like "fixed the tablespace." It's the literal SQL statement, the literal command output, and the literal math behind the safety check — automatically, every time, with zero chance of "I'll write it up properly later" (we all know later never comes).

And because plenty of DBAs live in OEM and never touch ServiceNow, the same note also shows up as a native comment inside OEM's own incident — cross-referenced back to the ServiceNow ticket:

Nobody had to remember to update two systems. The systems just... did it. Which is, generally speaking, the entire point of automation.

Okay, but does it actually save time, or is this just a fun toy?

Fair question. Here's the honest version, not the marketing version:

The manual-side numbers are realistic estimates of a typical on-call incident, not a scientifically audited historical average — we say that plainly, because a business case built on made-up precision isn't a business case, it's fan fiction. But the automated side has one very real, very measured number baked in: 33 seconds. That's the actual wall-clock time the automation took to diagnose, safety-check, and fix a real tablespace incident, measured from an actual log file, not a slide.

Everything else on the automated side — the "waiting for OEM's next check-in" time — isn't the robot being slow. It's the robot being patient, because it insists on independent confirmation before declaring victory. That's a feature, not a bug.