A few weeks ago, a DBA I know ran into ORA-00060 — a deadlock between two sessions, each waiting on a lock the other one held. Nothing dramatic, the kind of thing that turns up in the alert log every so often. Out of curiosity, she pasted the alert log entry into a general AI assistant to see what it would say.
The answer came back fast and confident: find the blocking session, kill the lower-priority one, check the SQL for a missing index causing lock escalation, maybe look at the transaction isolation level. It read like solid advice — the kind of answer that sounds right because it's the answer you'd expect for almost any deadlock.
There was just one problem: it skipped the part that actually decides which session pays for it. Oracle's deadlock detection doesn't wait around for someone to pick a victim — it kills one of the two sessions automatically, every time. What changes between versions is how it chooses.
On a current version with Priority-Transactions configured, the database doesn't just kill whichever session it reaches first. After a short wait, it kills the one with the lowest priority. By the time you've read the alert, the database has usually already made the right call, so following the AI's advice to step in manually doesn't really help — and it might even undo a decision Oracle had good reason to make.
On an older instance, or one without that configuration, the story is different. Victim selection there is mostly arbitrary — the database rolls back a transaction, but not necessarily the one that should have lost. That’s the case where the generic advice is at least pointed in the right direction, it just doesn’t go far enough. The real fix is usually something in the locking order of the application or a missing index, not a one-time session kill.
Same error code. Two different databases. Two different right answers, and one AI response that never asked which database it was looking at.
Two Speeds, One Deadlock
The same error code can mean two very different things depending on what's running underneath it, and that's usually the part a general AI model glosses over.
For engineers working on current versions with Priority-Transactions configured the way Oracle recommends, that deadlock alert is often already resolved by the time they see it — the database rolled back the right session on its own. The generic “find and kill the blocking session” advice doesn't really apply here — at best it's extra work that wasn't needed, at worst it undoes something the database already got right.
For engineers on 11.2.0.4, 12.1.0.2, or any version before 23ai — where Priority-Transactions doesn't exist as an option at all — the database still kills a session automatically — it just doesn't know to pick the one that matters less. Looking at which session got rolled back is a reasonable place to start, but that advice tends to stop right where the real work begins. Most repeat deadlocks come down to something in the application's locking order or a missing index, not the session itself.
Nobody gets asked which situation they’re in before getting an answer. And the cost shows up differently on each side: time spent undoing a fix that wasn’t needed, or a deadlock that keeps coming back because the advice never went deep enough to find what was actually causing it.
Asking the Configuration Before Answering the Error
This is one of the reasons ORAcraft's catalog entry for ORA-00060 becomes very useful here. Before suggesting anything, it takes into account the version you're running and whether Priority-Transactions is configured for the sessions involved, because that's really what decides what should happen next.
| Scenario | Generic AI | ORAcraft catalog |
|---|---|---|
| 23ai, Priority-Transactions configured | Kill the blocking session, check for missing index | Already resolved by the database — confirm the right session was rolled back by priority, no manual action needed |
| 11.2.0.4, pre-23ai, no Priority-Transactions option | Same generic advice | A session was already killed automatically, but not by priority — identify which one, then trace the locking order in the SQL causing repeat contention |
| 23ai, services configured but Priority-Transactions not enabled | Same generic advice either way | Flags the configuration gap itself — the fix is enabling Priority-Transactions, not chasing the SQL |
Each entry in the catalog comes with the exact steps already verified on a live database, and ORAcraft gives DBAs a sandbox environment to run those steps themselves before touching production.
The third row is the one a generic model has a hard time reaching, because it depends on noticing that a missing setting — not the SQL, not the session — is the actual cause. It's less a deeper guess and more an answer that's actually scoped to the system in front of you, rather than an average of every ORA-00060 the model has seen before.
The takeaway
A deadlock doesn't mean something different because the documentation changed — it means something different because the version and configuration underneath it changed. A generic model answers the error. ORAcraft tries to answer the error in the system you're actually running, which turns out to be a different question more often than you'd think.