24x7 Remote Oracle DBA Support: SLA Tiers Explained

In short: "24x7 DBA support" means very different things depending on the SLA tier behind it. A vendor promising round-the-clock coverage without a written response-time matrix, an escalation path, and a defined scope of what counts as an incident versus a request is promising availability, not a service level. This is the checklist worth working through before signing a remote DBA managed-services contract, for Oracle, PostgreSQL, MySQL or any mix of them.

Severity tiers — the foundation of any real SLA

A usable managed-services SLA defines severity levels with concrete criteria, not adjectives. A common structure:

• P1 — Critical: production database down, or a core business process (order entry, invoicing, payroll run) blocked for all users. Target first response: under 30-60 minutes, 24x7, with continuous work until resolved or mitigated.
• P2 — High: significant degradation — one module unusable, severe performance regression affecting a business process, a failed job blocking a batch cycle. Target first response: 1-4 hours during business hours, faster if the client has purchased extended coverage.
• P3 — Medium: a workaround exists, or the issue affects a subset of users without blocking core operations. Target first response: same business day to next business day.
• P4 — Low / requests: enhancement requests, minor tuning, non-urgent access changes. Target: scheduled into the next available maintenance window.

The number that matters in a contract negotiation is not "24x7 support" as a headline — it is the P1 first-response and resolution targets, because that is the tier that actually determines whether a database outage costs the business an hour or a day.

What "24x7" should actually specify

Round-the-clock coverage can mean an on-call engineer who is paged (with a defined page-to-acknowledge SLA, typically 15-30 minutes for P1), or it can mean a follow-the-sun model with staffed shifts across time zones. Both are legitimate, but they behave differently under a sustained incident: a paged on-call engineer working alone for eight hours straight is a different risk profile than a shift handover to a fresh engineer. A serious SLA states which model is in use and what happens if the primary on-call engineer does not acknowledge within the page SLA — is there a secondary escalation, or does the alert simply retry?

Scope: what counts as included support

The most common source of disputes in DBA managed services is scope, not response time. A clear contract specifies, explicitly:

• Reactive incident response (something broke) vs. proactive monitoring (alerting before it breaks) vs. scheduled maintenance (patching, upgrades) — these are frequently priced and staffed differently, and a "24x7 support" quote that only covers reactive incident response will surprise a client expecting proactive monitoring included.
• Patch cycle cadence and who tests patches before production rollout.
• Performance tuning — is ongoing tuning included, or billed as a separate project once a specific problem is identified?
• Capacity planning and growth forecasting — often left out of a base SLA and sold as a quarterly add-on.

Monitoring baseline — what should already be watching before an incident happens

A DBA managed-services provider that is only reactive — waiting for the client to report an outage — is not really providing 24x7 coverage, regardless of what the contract says. The monitoring baseline that should already be running: tablespace/disk space thresholds, replication lag (Data Guard apply lag, PostgreSQL streaming replication lag), long-running or blocking sessions, failed scheduled jobs, backup completion and validation, and alert-log/error-log scanning for ORA- errors or PostgreSQL FATAL/PANIC entries. If none of this is running before day one of the contract, the "24x7" promise is really "we will respond once you notice."

Escalation path — the part most SLAs leave vague

A specific, named escalation path matters more than most clients realise until they need it: who is the primary on-call DBA, who is the secondary if the first does not respond within the page SLA, and who is the named engagement manager who gets involved if a P1 runs past its resolution target. Vendors that cannot name specific people and a specific escalation chain — rather than "our team will handle it" — have usually not operationalised the SLA they are selling.

Questions worth asking before signing

Concretely: what is the P1 first-response time, in writing, with a defined penalty or credit if missed? Is monitoring already active before the contract starts, or does it need to be built as a paid onboarding phase? Does the SLA name specific engineers and an escalation chain, or a generic team? Is the same SLA structure applied consistently whether the database is Oracle, PostgreSQL, or MySQL, or does coverage quietly degrade for the non-Oracle engines? That last question is where many otherwise-solid Oracle-focused providers fall short, and it is worth asking directly.

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 →