How to Choose an Oracle DBA Support Partner: 10 Questions to Ask

Choosing who looks after your Oracle databases is a risk decision, not a price comparison. Whoever you pick will hold privileged access to the systems your business runs on. This guide gives you ten practical questions to ask any Oracle DBA support partner, including us. For each one we say what a good answer sounds like and what should worry you. It is vendor-neutral, and where a point rests on Oracle's own documentation we link to it.

1. Can you prove a restore works, not just that backups run?

A backup job that completes proves very little. Ask when the partner last restored a database from backup and how they test it. Oracle's RMAN documentation says that RMAN validation checks a backup to determine whether it can be restored, and also checks for corrupt blocks and missing files. A good partner has a routine for this and can show you the last result. A weak answer is "the backup job is green".

2. What is your patching process?

Oracle publishes Critical Patch Updates on a quarterly schedule. Oracle's database security guidance says to apply security patches as soon as they are available. In practice, "as soon as" means testing first. Ask how patches are tested on a non-production copy, how you approve a window, and how they roll back. Be wary of a partner who patches production directly, or never.

3. How will you access our systems, and who can see what?

Ask how engineers connect (VPN, jump host, your own tooling), whether access is named per person, whether sessions are logged, and how access is removed when someone leaves the partner. Shared accounts and permanent broad privileges are a red flag. You should be able to see a list of who has access today.

4. What high-availability setups have you actually run?

If you use Real Application Clusters (RAC) or Data Guard, ask for specific experience with the version you run: switchover, failover and how they check that the standby is current. If you do not use them, ask whether they would recommend them for your recovery needs, and what that would involve. Avoid vague claims such as "we know everything about Oracle".

5. What hours do you cover, and who answers at night?

Business-hours and round-the-clock support are different services. Ask for the coverage hours in writing, which time zone they refer to, and whether out-of-hours calls go to a named on-call engineer. Match this to the cost of an hour of downtime for you, not to what sounds reassuring.

6. How does escalation work?

Ask what happens when the first engineer cannot solve the problem: who is next, how fast, and when Oracle Support gets involved. Find out whether the partner can raise Oracle Support requests on your behalf or whether you must use your own support identifier, and who owns that process. Get the escalation path as a document with names or roles.

7. What will we receive each month?

Good reporting is short and specific: incidents and their causes, backup and restore test results, patch status, capacity trends such as tablespace growth, and recommendations. Ask for a sample report. If the only output is a ticket list, you are paying for reaction rather than prevention.

8. How do you onboard a new database?

A responsible partner reviews before it promises. Ask what the first review covers: backup and recovery posture, patch level, parameters, security settings, capacity and any unsupported configurations. Ask whether it is a fixed-scope piece of work with a defined output, so you can judge the partner on that before committing to a longer arrangement. Be careful with anyone who quotes a monthly fee without looking at your environment.

9. What happens if we leave?

Ask for the exit terms before signing. You want all scripts, runbooks, documentation, credentials and monitoring configuration handed over in usable form, and a clear statement that the knowledge about your databases belongs to you. A partner who is confident in their service has no reason to make leaving difficult.

10. Do you understand our Oracle licensing position?

Oracle licensing is a common source of unplanned cost. A DBA partner is not your licensing adviser, but should know which options and packs are in use, avoid enabling licensable features without telling you, and flag changes that could affect your position. Ask how they handle this, and treat any claim about what you do or do not owe Oracle as something to confirm with Oracle or a licensing specialist.

A note on price

Price matters, but compare it only after the scope is the same. One quote may include restore tests, patching, monthly reports and out-of-hours cover while another covers monitoring and ticket handling only. Ask each partner to list what is included and what is billed separately, then compare like with like. A low monthly figure that leaves out patching or restore testing is not cheaper, it simply moves the cost to the day something breaks.

How to use the list

• Ask for answers in writing and compare partners on the same ten points.
• Prefer evidence (a sample report, a restore test log, an access list) over assurances.
• Start with a limited scope. A fixed-scope review shows you how a partner works before you hand over ongoing responsibility.

Where ROSTAN fits

If you want a starting point, our Oracle DBA support page describes a fixed-scope health check and the options we offer, and it has an FAQ on how support works. You are welcome to put these ten questions to us as well.

Written & reviewed by

Virender Kumar

Head of Cloud & Database, ROSTAN Technologies

Virender Kumar leads the cloud and database practice at ROSTAN Technologies, covering Oracle Database administration, Oracle Cloud Infrastructure (OCI) and enterprise cloud migration. More from Virender →