{ Abhilash Kumar Bhattaram : Follow on LinkedIn }
This article focuses on working with Oracle Support — and how I help you get an SR resolved instead of just logged.
Working With Oracle Support
Every DBA who's been at this long enough has a My Oracle Support (MOS) story, and most of them aren't flattering. None of that is a secret — every IT leadership reading this has heard it from their own team.
MOS UI is continuosly changed , but that does not stop a DBA to get the best out of Oracle Support by proactively sharing information to the guy sitting on the other side of the table.
A bad SR gets raised and waited on. A good SR gets raised and worked — by both sides, at the same time.
Here's the distinction that experience actually teaches you: an SR isn't a request you hand off and wait on. It's a case you build with the engineer, and the DBAs who get resolutions fastest are the ones who act less like a customer filing a complaint and more like a second engineer already working the problem. That single mindset shift — help Oracle Support, don't just wait for it — is the entire difference between a ticket that moves and one that doesn't.
1. Ground Zero: Where Challenges Start
Let's start with a plain canvas and understand our ground zero — almost every stalled SR traces back to something that should have been done before the ticket was even opened.
Typical Weekend Panic & corresponding solutions:
Ticket raised, then the team waits for the engineer to ask for diagnostics → Solution: Upload TFA, ExaCS diagnostic collections, and OS Watcher data proactively, at SR creation — don't wait to be asked
"The database is slow" logged with no application context → Solution: Explain what the application was doing, what business process it supports, and what "slow" actually means in numbers
An ORA-00600/ORA-00700 error logged as a mystery → Solution: Run it through the ORA-600/700 Lookup Tool first — it may already be a documented bug with a known fix
SR sits open for days with no update from your side either → Solution: Treat silence as your problem too — a stale SR from your end signals it's not urgent, even if it is
Engineer's first response asks for something you already have on hand → Solution: Attach it before they ask — a DBA who anticipates the next question is remembered and prioritized
SR written from the DBA's frustration, not the engineer's perspective → Solution: Ask yourself what you'd need to see if you were the one picking up this case cold
Team assumes "Oracle will figure it out" once diagnostics are attached → Solution: Diagnostics start the investigation — they don't replace your own analysis of what you're seeing
This is where most SRs go from "slow" to "stuck" — not because Oracle stopped working it, but because both sides stopped moving it forward together.
As you can see, a great SR is built through the same discipline you'd use troubleshooting the issue yourself — Oracle Support is a collaborator here, not a vending machine.
2. Underneath Ground Zero: Finding the Real Problem
Once you've understood your Ground Zero problems, you need to move to why so many DBAs default to raise-and-wait instead of raise-and-help.
Why "we logged an SR" doesn't mean the same thing to every DBA:
Proactive diagnostic tools are seen as something you run only when asked → Solution: Treat TFA, OS Watcher, and ExaCS diagnostics as part of opening the SR, not responding to it
Less experienced DBAs don't know the ORA-600/700 Lookup Tool exists → Solution: Build it into your team's first-response checklist for any internal error before an SR is even raised
The application team and the DBA team don't share context before the SR is written → Solution: Pull in the application owner briefly — what changed, what's the business impact — before logging
DBAs think "attaching everything" is the same as "explaining the problem" → Solution: A pile of logs isn't a diagnosis — pair every attachment with what you believe it shows
Support is viewed adversarially, as something to escalate against rather than work with → Solution: Shift the internal language from "fighting with support" to "working the case with
support"No one on the team has been shown what a genuinely well-run SR looks like → Solution: Have your most experienced DBA mentor others through their first few high-severity SRs
This gap is why two DBAs with the same issue and the same Oracle support tier get completely different outcomes.
As you can see, the difference isn't Oracle's engineers — it's how much of the diagnostic and analytical work has already been done by the time they open the case.
3. Working Upwards: From Understanding to Solution
Here's what separates an SR that moves from one that doesn't — the things an experienced DBA does without being told to.
Do this before you even log the SR:
Run the error through the ORA-600/700 Lookup Tool (MOS Note 153788.1) before assuming it needs a fresh investigation. A meaningful share of ORA-600/ORA-700 errors are already documented, with a known bug number, workaround, or patch — an experienced DBA checks this first and often finds the SR is unnecessary, or at least dramatically shortened.
Collect TFA (Trace File Analyzer) output proactively. TFA correlates logs across all nodes and layers automatically — attach it at SR creation, don't wait for the engineer to request it.
On ExaCS, run the relevant Exadata diagnostic collection up front — cell server logs, ILOM data, and health check output. Exadata issues almost always need this, so there's no version of the SR where it isn't eventually asked for.
If OS-level performance is in question, have OS Watcher data ready — CPU, memory, I/O, and network captured around the incident window. Reconstructing this after the fact is far harder than having it captured continuously.
Do this when you write the SR:
Explain the application problem, not just the database symptom. "ORA-01555 during month-end batch" tells an engineer far less than "ORA-01555 during the finance close batch, which reads a 40M row table over 3 hours — this started after we increased batch parallelism last week."
Put yourself in the SR engineer's seat. They're picking this up cold, possibly mid-shift-change, with no memory of your environment. Write the SR so a stranger could triage it in five minutes.
State what you've already ruled out. If you've checked for blocking sessions, recent parameter changes, or a matching bug, say so — it prevents the engineer from re-walking ground you've already covered.
Do this while the SR is open:
- Don't raise and wait — keep working the problem on your side in parallel. If you find something new, post it immediately, don't hold it for the next scheduled update.
- Respond to every ask same-day where possible. An SR that goes quiet from your end loses momentum and priority just as easily as one that goes quiet from Oracle's.
- If you're stuck, say exactly what you need — a call, a specific engineer, a decision by a specific time — not a general nudge.
The pattern holds no matter which version of MOS you're using: the SRs that move are the ones where the DBA is visibly still working the problem, not just waiting on someone else to.
Technical Issues:
- ORA-600/700 errors logged without checking the Lookup Tool first
— Solution: Make the Lookup Tool check step one, before an SR is even opened
- TFA, OS Watcher, and ExaCS diagnostics collected only after being requested — Solution: Build proactive diagnostic collection into your incident response runbook
- Diagnostics attached without any accompanying analysis — Solution: Pair every attachment with a sentence on what you believe it shows
Non-Technical Issues:
- Support treated as adversarial rather than collaborative —
Solution: Reframe internally as working the case together, not escalating against a vendor
- Application context missing from SRs raised by the DBA team alone
— Solution: Involve the application owner briefly before logging, every time
- Junior DBAs never shown what a well-run SR looks like — Solution: Pair them with an experienced DBA on their first few Sev 1/Sev 2 cases
A MOS great SR isn't about being demanding, and it isn't about waiting patiently either — it's about doing the engineer's first three steps for them before they've had the chance to ask.
Top comments (0)