There is a skill that separates a senior DBA from a junior one more reliably than any other.
It is not knowing which DMVs to query. It is not memorising wait type acronyms. It is not even knowing the right configuration settings.
It is reading an execution plan.
What Plan Reading Actually Is
When SQL Server runs a query, it produces an execution plan — a diagram of every decision the optimiser made about how to retrieve and join the data. Which index to use. Whether to use parallelism. Whether to hash, sort, or nest loops. What estimated row count it was working with, versus what it actually found.
A senior DBA looks at that plan and, in under a minute, spots the hash match that is spilling to tempdb, the implicit conversion that is preventing an index seek, the key lookup that is doing 10 I/Os per row, or the estimated vs actual row count divergence that tells them this plan was compiled with bad statistics.
That gap — between “something is slow” and “here is the exact line in the plan where SQL Server made the wrong decision” — is where most diagnostics leave you.
What Most Diagnostic Tools Do
Most SQL Server diagnostic tools — monitoring platforms, AI-driven or otherwise — cover the same ground: configuration, wait statistics, index health, backup status. That coverage is valuable. It catches the common problems — MAXDOP set to 0, log backups not running, fragmentation at 90%.
But it stops short of the plan.
Configuration checks tell you about the environment. Wait statistics tell you what SQL Server is waiting on. Index health tells you whether your indexes are fragmented or missing. None of these tells you why a specific query is slow, at the level of which decision the optimiser made and where it went wrong.
That is what a plan tells you. And until now, reading plans was something you needed a senior DBA to do manually.
The Gap We Are Closing
Plan reading is not some exotic specialist skill to admire from a distance. It is a baseline capability that anyone diagnosing SQL Server performance should have.
The problem is not that it is hard to learn — it is that it does not scale. You cannot manually read execution plans for every slow query across four production SQL Servers every day. You can look at the worst one when there is an incident. But the plan that is consistently burning 15% of your CPU across 1,000 executions per day gets ignored because it never triggers a severity-1 alert. It just silently costs you.
That is the gap Plan Analyzer closes. It reads the plans, flags the red flags, and tells you which line in the plan caused the problem — for every query in scope, not just the ones you happened to look at.
What Is Coming on 22 May
On 22 May, AIDA Diagnostics gains the ability to read and reason about execution plans as part of every standard engagement.
This is not a new product. It is a step-change in what the existing diagnostic can tell you. The plan analysis feeds into the same findings report, the same human-reviewed workflow, the same $495 per server instance.
The change is that “here are your performance problems” now includes the plan-level evidence for why each one is happening.
If you want to be first in line on 22 May, join the waitlist: https://www.sqlinsightsolutions.com.au/aida-diagnostics-waitlist/