When something is clearly wrong with SQL Server performance but you can’t immediately tell who or what is causing it, what does your team’s first...
When something is clearly wrong with SQL Server performance but you can’t immediately tell who or what is causing it, what does your team’s first move actually look like? For a lot of DBAs, the honest answer is: pull up the logs and start reconstructing what happened. That approach works, eventually — but it means investigating a problem that already happened, using evidence that is already stale, while the underlying issue may still be actively getting worse.
Session monitoring in SQL Diagnostic Manager for SQL Server (SQL DM) exists to close that gap. Instead of piecing together what occurred after the fact, it gives your team a live view of everything happening on a SQL Server instance right now — who’s connected, what application they’re running, what queries are executing, how long those queries have been running, and what resources they’re consuming. It is one of the fastest ways to go from “something feels off” to “here is exactly what’s causing it,” and it is especially powerful for identifying blocking chains the moment they form.
Session monitoring in SQL Diagnostic Manager gives DBAs a live, real-time view of every session running on a SQL Server instance — who is connected, what they are running, how long it has been running, and what resources it is consuming — including automatic visualization of blocking chains, so teams can see and act on an issue at the moment of impact instead of reconstructing it afterward from logs.
How to Monitor Performance and Availability with SQL Diagnostic Manager for SQL Server
Session monitoring is not a summary or a sampled snapshot — it is a live, continuously updated picture of activity on the instance. In practical terms, it surfaces:
Logs are a record of what already happened. That makes them useful for forensic analysis after an incident is resolved, but they are a poor tool for the moment when performance is degrading right now and the business impact is accumulating in real time. By the time a team has pulled the right logs, correlated timestamps across multiple sources, and reconstructed a sequence of events, the underlying condition — a runaway query, a growing blocking chain, an application that opened far more connections than expected — may have already caused significant downstream damage.
This gets worse, not better, as environments scale. A handful of servers is manageable to reason about from memory and a few log queries. Dozens or hundreds of instances, each with its own applications and workload patterns, make log-based reconstruction slow at exactly the moment speed matters most. The teams that feel this most acutely are the ones fielding an urgent “the application is slow” report with no immediate answer to the most basic diagnostic question: who or what is actually running on the server right now?
Of everything a live session view surfaces, blocking is where it earns its keep the fastest. Blocking happens when one session holds a lock that another session needs, and that second session simply waits — sometimes for a moment, sometimes long enough to cascade into a chain of sessions waiting behind it, each one blocked by the session in front of it. Left undiagnosed, a blocking chain can quietly stall a meaningful portion of an application’s activity while every symptom a team can see from the outside just looks like generic slowness.
Session monitoring turns that into something visible and specific. Instead of inferring that blocking might be happening from indirect symptoms, a DBA can open the Sessions and Blocking views in SQL DM and see the chain directly: which session is the lead blocker, what it is currently doing, how long it has held its lock, and exactly which other sessions are waiting behind it. That visualization is the difference between guessing that “something is blocking something” and knowing, within moments, precisely which session to investigate — and, if necessary, which one to trace or terminate to restore normal activity.
Session monitoring works best as a repeatable first move, not a tool reached for only after other options are exhausted. A practical workflow looks like this:
| Session Monitoring Can | The DBA Must Determine |
|---|---|
| Show every active session, live, with query, duration, and resource detail | Which sessions are actually worth investigating right now |
| Visualize a blocking chain and identify the lead blocker automatically | Whether the lead blocker should be left alone or terminated |
| Surface how long a session or lock has been held | What an acceptable duration looks like for that specific workload |
| Update continuously, in real time, without added agent overhead | When a recurring pattern warrants a structural fix instead of a one-off resolution |
Session monitoring shows you the moment of impact. The DBA still owns the decision.
Real-time, “fix-it-now” diagnostics is Quest Spotlight on SQL Server’s signature positioning, and it is the most direct competitive overlap with session monitoring specifically — a fair comparison is worth making rather than avoiding. SolarWinds SQL Sentry leans on AI Query Assist and ML Anomaly Detection, a related but more predictive, algorithmic pitch. Redgate SQL Monitor carries broader market share and a strong dev/deployment angle, with adaptive alerting layered on top.
SQL Diagnostic Manager’s differentiation is live, real-time visibility at the moment of impact, delivered agentlessly. Watching every active session on every monitored instance does not mean adding an agent’s overhead to each one of those sessions — SQL DM collects this data without deploying additional software on the monitored server itself, so the tool doing the watching doesn’t become part of the performance problem it’s meant to diagnose. Every session and every blocking relationship stays fully transparent and inspectable, with nothing abstracted behind a model a DBA can’t see into.
Most teams start with session monitoring purely reactively — it becomes the tool they reach for the moment something is already wrong. That is a legitimate and valuable use on its own, but it is not the ceiling of what the feature can do. Teams that check in on session and blocking activity periodically, even when nothing is actively broken, start to notice patterns: the same application opening more connections than expected at a predictable time of day, a particular batch job that reliably becomes a lead blocker during month-end processing, or a query that runs long often enough that it is worth tuning before it becomes today’s emergency.
That shift — from only opening the Sessions view during an incident to occasionally checking it as part of routine review — is what turns session monitoring from a fire-extinguisher into an early-warning system. It doesn’t require new tooling or a new license tier, just a habit: a few minutes reviewing active sessions and recent blocking history on the busiest instances, on a schedule, instead of only under duress.
Does session monitoring add overhead to the servers it’s watching?
No. SQL Diagnostic Manager collects session and blocking data agentlessly, so live visibility into every session doesn’t mean deploying additional software — or additional load — onto the SQL Server instance being monitored.
Can I see who is causing a blocking chain, not just that blocking is happening?
Yes. SQL DM’s Blocking view identifies the lead blocker at the head of a chain and shows exactly which sessions are waiting behind it, so you can trace or terminate the specific session causing the problem.
Is session monitoring only useful during an active incident?
It’s most commonly used reactively, but teams that check in on active sessions and blocking history periodically often catch recurring patterns — the same job or application causing blocking at the same time of day — before they escalate into a bigger problem.
How is this different from real-time tools like Quest Spotlight?
The underlying goal — live, in-the-moment visibility — is similar. SQL DM’s approach emphasizes agentless collection and full transparency into every session and blocking relationship, so DBAs get the same real-time picture without added monitoring overhead on the instance itself.
Do I need to configure anything to start using session monitoring?
No. Because SQL DM is already collecting the underlying activity data on every monitored instance, the Sessions and Blocking views are available as soon as an instance is added to monitoring — there is no separate setup phase to complete first.
If your team is still piecing things together from logs when something goes wrong, the live session view is worth revisiting — it tends to cut troubleshooting time significantly, and it turns “who or what is causing this” from a guessing game into a direct answer.
Start a free 14-day trial of SQL Diagnostic Manager
Talk to your account team about a live session monitoring walkthrough
Contact our sales team to get a personalized demo of our database management software for SQL Server!
