The first 90 minutes of a DBR mission

Why 90 minutes

It's my first working session. Three goals:

• Understand where it really hurts before touching anything. Rule out the nice-but-wrong hypotheses.
• Come out with 3 to 5 priorities that drive the rest of the mission. Not an exhaustive list of everything that could be improved.
• Give you an honest opinion on the remaining effort: what's worth the time, what can wait.

By the end of those 90 minutes, I have a structured note, prioritised actions with estimates, and we have a roadmap for what's next. If I think it needs more time, I say so. If I think it's not my area, I say that too.

What I need beforehand

Three things, simple:

1. Read access to the instance (system DMVs, msdb views, Windows counters if possible). No write access — I make no changes during this first session.
2. 30 to 45 minutes of the technical lead for targeted questions. Ideally the person who answers the on-call.
3. The business context in 5 lines: criticality, permitted maintenance windows, expected RPO/RTO (measured or theoretical).

If you can't answer one of these, that's already useful information for what follows.

The six phases

1. Business framing (15 min)

I don't start with the technical side. First I try to understand:

• What's the real criticality of the instance (vs. the one it has on paper)?
• What are the 2 or 3 incidents that marked the last 12 months?
• What worries the IT director today?
• What's the acceptable intervention window, and the one tolerated in a crisis?

By the end of this phase, I have a real list of pain points, not the exhaustive list of everything that could be improved. That list drives the remaining 75 minutes.

2. Instance health check (15 min)

Three angles, in parallel:

• Wait stats (sys.dm_os_wait_stats): where SQL Server "loses its time". Top 5 by category, normalised signal vs. resource time. A snapshot, ideally a 24-48 h sample via regular capture.
• Key performance counters: Buffer Cache Hit Ratio, Page Life Expectancy, Batch Requests/sec, Compilations/Recompilations ratio, disk latencies (Avg. Disk sec/Read and /Write).
• Configuration: sp_configure. Flags on defaults left in place: MAXDOP, cost threshold for parallelism, max server memory, optimize for ad hoc workloads.

It's not a full diagnosis. But in 15 minutes, we know whether the instance is struggling or not, and on which axis.

3. Backup and restore (10 min)

The least glamorous but most structuring point.

• Coverage: msdb.dbo.backupset. When was the last FULL? the last DIFF? are the LOGs in a continuous chain?
• Restore test: has it been done in the last 6 months? On an instance other than production? How long did it take?
• Measured RPO/RTO: if I have to restore now, point-in-time, how many minutes of data lost? How many hours of restore?

A single "no" to one of these questions, and it's an immediate priority in the summary. An untested backup is not a backup.

4. High availability (10 min)

If an HA architecture is in place (AlwaysOn Availability Group, FCI, mirroring, replicas):

• Real topology vs. documented topology. The gap is often frightening.
• Current replica state: synchronisation, latency, last successful failover.
• Failover procedure documented and tested? By whom? On which database?

Without HA: we look at whether the need exists (an RTO incompatible with a standard restore), and we quantify the gap.

5. Targeted performance (25 min)

The densest phase. I target 3 to 5 priority queries or problems, identified via:

• Top queries by CPU, logical reads, average duration, frequency (sys.dm_exec_query_stats + sys.dm_exec_query_plan). A mix of "what costs the most" and "what costs most often".
• Suspect execution plans: a seek that should be a scan (or the reverse), a needless sort or hash, parameter sniffing, critical missing indexes flagged by the engine.
• Indexing: fragmentation on the most-used indexes, missing indexes with estimated impact, redundant or never-used indexes.
• tempdb: number of data files vs cores, allocation contention (PAGELATCH_UP on GAM/SGAM/PFS files), version store if snapshot isolation is active.

The goal isn't exhaustiveness. It's to surface 3 to 5 real, actionable problems.

6. Summary and actions (15 min)

No cold write-up. We finish together.

• 3 to 5 prioritised actions. Quick wins at the top, structural at the bottom.
• For each action: estimated effort (in days), estimated impact (performance, reliability, risk avoided), any prerequisites (maintenance window, access, etc.).
• Hand-off: a structured Markdown note you keep in your wiki, or a simple discussion + email. Your call.

If an action clearly goes beyond the 90-minute scope (for example "the HA architecture needs a redesign"), I say so explicitly and we frame the next phase.

Typical deliverables

• Structured note (Markdown, roughly 5 to 10 pages). Readable in Confluence, GitHub, Notion or any Markdown editor.
• Table of prioritised actions: action, effort in days, impact, prerequisites.
• Reproduction scripts for the findings (where applicable). So your teams can re-check after my fixes.

No slides, no decorative diagrams. You leave with something executable.

At the end of those 90 minutes

You have:

• A focused snapshot of the instance (health, performance, HA, backup)
• A list of prioritised actions with effort estimates
• A frank external opinion on what's left to dig into
• A roadmap for the rest of the mission

What we dig into next

What follows depends on the priorities identified. Depending on the case, we tackle:

• Deep performance tuning: implementing the actions, A/B tests on a replica, validating the gains.
• HA hardening: architecture review, AlwaysOn/FCI setup, failover tests, documented procedures.
• Backup strategy: coverage overhaul, automated restore tests, measured RPO/RTO.
• Industrialisation: IaC with PowerShell DSC or Ansible, maintenance plans, monitoring.
• Incident recovery: if the first session reveals a critical situation, we switch to intervention.

Out of scope

A few topics I don't handle, to set expectations from the start:

• Full security audit (permissions, attack surface, hardening): that needs a dedicated security expert.
• Regulatory compliance (GDPR, ISO 27001): a different job.
• Large-scale workload benchmarking / capacity planning: a different mission format.
• Pure NoSQL (Mongo, Cassandra): a specialist will be a better fit.

Let's talk about your mission

If this method resonates with your situation, the first 30-minute call is on me. No sales pitch, just the right questions to frame things.

Day rate and terms at rethink-it.fr.