Learn how to install SQL Server with our step-by-step guide for SQL Server 2022 installation process.

The post Install SQL Server 2022 Standard Edition appeared first on MSSQLTips.com.

Live Webcast Abstract Database environments are dynamic: databases grow, workloads change, and this requires a focus on scalability, performance tuning, resource optimization, and cost optimization. What deployment options are right for you? What are the best practices for right-sizing SQL Server on AWS to optimize licenses? What about back-up and storage costs? Tune in to […]

The post Making SQL Server More Affordable in the Cloud: Smarter Approaches for 2026 appeared first on MSSQLTips.com.

A query that ran in 200 milliseconds yesterday is taking 14 seconds today. The application team noticed before the monitoring tool did. By the time someone opens the database server, there are 47 sessions in the active requests view, three of them blocked, and one of them holding a lock that has been open for six minutes. Nobody can tell you what that session is doing, who it belongs to, or whether killing it is safe. This is not a hardware problem. It is a visibility problem. And it is more common than it should be. Let us talk about Real-Time Performance Views That Make Troubleshooting Easier.

The Gap Between Data and Diagnosis

SQL Server produces an enormous amount of real-time performance data. The dynamic management views alone, including sys.dm_exec_requests, sys.dm_os_wait_stats, sys.dm_exec_query_stats, sys.dm_exec_sessions, and sys.dm_db_index_operational_stats, contain everything a DBA needs to understand what is happening on an instance at any given moment. The problem is not availability of data. The problem is that raw DMV output is not a troubleshooting interface.

A query against sys.dm_exec_requests joined to sys.dm_exec_sql_text and sys.dm_exec_query_plan gives you the active request, the statement text, and the cached execution plan. That is genuinely useful. But writing that query under pressure, at 9 PM, while someone is waiting for an update, is a very different experience from having it presented in a live view that refreshes every few seconds and highlights what matters. Monitoring platforms such as Idera SQL Diagnostic Manager exist specifically to surface those DMV relationships in a live operational view rather than forcing DBAs to reconstruct them manually during an incident.

Real-time performance views bridge that gap. Done well, they take the same underlying data and present it in a way that compresses the time between opening a monitoring tool and knowing what to do next.

What Belongs in a Real-Time View

Not everything belongs in a live dashboard. Cluttering a real-time view with metrics that only make sense over hours or days, such as index fragmentation trends, storage growth, and backup history, turns a diagnostic tool into a reporting tool. They serve different purposes.

The metrics that genuinely belong in a real-time troubleshooting view are those where a change in the last 30 to 60 seconds is diagnostically meaningful. The table below maps each category to its source DMV, the appropriate collection interval, and what it actually tells you.

Metric Category	Primary DMV(s)	Collection Interval	What It Tells You
Active Sessions & Blocking	sys.dm_exec_requests, sys.dm_exec_sessions	15 to 30 seconds	Who is running, who is blocked, how long, and what the wait type is. Renders as a blocking chain tree.
Wait Stat Deltas	sys.dm_os_wait_stats (sampled at intervals)	30 to 60 seconds	Rate of change in PAGEIOLATCH, LCK_M, CXPACKET, CXCONSUMER, and SOS_SCHEDULER_YIELD. Not cumulative totals.
Cached Execution Plans	sys.dm_exec_query_plan, sys.dm_exec_text_query_plan	On demand	Cached plan SQL Server is using for any active request. Use sys.dm_exec_query_profiles for operator-level in-flight data.
Query CPU vs Historical Avg	sys.dm_exec_requests correlated via query_hash to sys.dm_exec_query_stats	30 to 60 seconds	Whether current execution is anomalous or simply expensive as usual. query_hash links current requests to their historical aggregate.
Tempdb Pressure	sys.dm_db_session_space_usage, sys.dm_db_task_space_usage, sys.dm_exec_requests	60 seconds	Version store size, allocation page contention, and per-session and per-task tempdb usage for a complete pressure picture.
Memory Pressure	sys.dm_os_performance_counters, sys.dm_exec_query_memory_grants	60 seconds	Sustained downward trend in PLE, not raw value, is the signal. Memory grants pending indicates workload waiting on memory allocation.

Table 1: Real-time metric categories, their DMV sources, and diagnostic value

How Collection Architecture Shapes What You See

The flow is straightforward. DMV sources feed a collection engine, and that collection engine drives the real-time views a DBA actually works with. The collection intervals are not arbitrary. They reflect a real tradeoff between diagnostic resolution and overhead on the monitored instance.

Higher collection frequency means more load on the monitored instance and more storage consumed by the monitoring infrastructure. Well-designed tools manage this by applying different intervals to different metric categories: live session data at 15-second intervals, wait stat deltas at 60 seconds, and index and storage metrics at longer intervals. The goal is to capture what needs capturing without adding meaningful overhead to an already pressured instance.

For blocking chain analysis, collection frequency matters more than most people realize. A blocking event that resolves in three minutes and causes a burst of application errors may never appear in a tool with five-minute refresh cycles. Sub-minute collection is what allows those transient events to be caught, preserved in history, and reviewed after they have already cleared.

The Execution Plan Problem

One of the more underused capabilities in real-time troubleshooting is cached execution plan access. sys.dm_exec_query_plan returns the cached plan associated with a running request, which is the plan SQL Server is actually using to execute the query and what a DBA needs during an incident. sys.dm_exec_text_query_plan returns it as XML, filterable by statement offset, which lets you isolate the relevant plan for a specific statement inside a multi-statement batch.

The important distinction is that this is the cached plan, not a live execution plan reflecting current runtime statistics. For in-flight execution statistics such as rows actually processed per operator and actual versus estimated row counts, sys.dm_exec_query_profiles provides operator-level data for active queries, though it requires the query to have been compiled with runtime statistics collection enabled. In most incidents, the cached plan from sys.dm_exec_query_plan is sufficient to identify the problem.

This matters because a query can perform well under one set of conditions and catastrophically under another, using the same cached plan. If a parameter-sniffed plan that was optimal for a small result set is now running against a large one, the plan itself will show you exactly where the cost is landing: on a nested loop join that is iterating millions of times, on a key lookup against a non-covering index, or on a hash match that has spilled to tempdb. You cannot reliably infer this from wait statistics alone.

A real-time view that surfaces the cached plan for any selected active request, rendered graphically rather than as raw XML, collapses what used to be a multi-step investigation into a single click. The DBA sees the request, sees the plan, and can make a decision about whether the fix is a hint, an index, or a statistics update, all without leaving the monitoring interface.

Why Refresh Rate Matters More Than People Think

A real-time view that refreshes every five minutes is not a real-time view. It is a slow reporting tool with a hopeful name.

For blocking chain analysis, a five-minute refresh means you may never see a blocking event that resolves in three minutes, which is exactly the kind of event that causes a burst of application errors and then disappears before anyone investigates. Sub-minute collection intervals, typically 15 to 30 seconds for live session data, are what allow a monitoring tool to catch transient blocking events and preserve them in historical data even after they have cleared. Idera SQL Diagnostic Manager collects live session and blocking data at these sub-minute intervals, which means a blocking chain that forms and clears within two minutes still appears in the historical record and can be reviewed after the fact.

There is a real tradeoff here. Higher collection frequency means more load on the monitored instance and more storage consumed by the monitoring infrastructure. Well-designed tools manage this by applying different collection intervals to different metric categories: live session data at 15-second intervals, wait stat deltas at 60 seconds, and index and storage metrics at longer intervals. The goal is to capture what needs capturing without adding meaningful overhead to an already pressured instance.

Wait Statistics: Deltas Over Totals

sys.dm_os_wait_stats is cumulative since the last service restart. A server that has been running for three weeks carries three weeks of accumulated wait history in every row. The cumulative total is useful for trend analysis over long periods. It is not useful for understanding what is happening right now.

The signal you want in a real-time context is the rate of change. How much have PAGEIOLATCH_EX waits increased in the last two minutes? Are SOS_SCHEDULER_YIELD waits climbing, indicating CPU saturation? Has ASYNC_NETWORK_IO spiked, which often points to a client that is not consuming result sets fast enough? A monitoring tool that samples wait stats at short intervals and presents the delta, rather than the running total, exposes pressure that cumulative views hide completely.

PAGEIOLATCH_SH / PAGEIOLATCH_EX

Waits on data pages being read from disk into the buffer pool. A rising delta points to disk I/O pressure or buffer pool churn from insufficient memory.

CXPACKET

Producer-side parallel exchange wait. A rising delta alongside high CPU can indicate plan skew, MAXDOP misconfiguration, or a workload that is being over-parallelized.

CXCONSUMER

Consumer-side parallel exchange wait, separated from CXPACKET in SQL Server 2017 CU3. Typically benign. A high CXCONSUMER delta without a corresponding CXPACKET rise is usually not a tuning signal.

SOS_SCHEDULER_YIELD

A thread voluntarily yielded the scheduler under heavy CPU load. A rising delta means the instance is CPU-bound.

ASYNC_NETWORK_IO

SQL Server is waiting for the client to consume data. Often a client-side bottleneck, but it still occupies sessions and can create apparent blocking.

LCK_M_X / LCK_M_S / LCK_M_U

Lock waits. Any meaningful delta here means blocking is active or was recently active. The session view will tell you who is involved.

Reading the View Under Pressure

The most important quality of a real-time performance view is that it should be readable by someone who is already stressed and moving fast. That sounds obvious. Most monitoring interfaces still miss it.

Effective real-time views lead with the answer. If there is blocking, the blocking view should be the first thing visible, not buried under a navigation menu. If a wait type has spiked in the last two minutes, it should stand out visually from the ones that have not. If a query is consuming 10 times its usual CPU, that deviation should be immediately obvious without requiring the DBA to remember what the usual number is.

This is the difference between a view that presents data and a view that supports a decision. The underlying SQL Server data is the same in both cases. The difference is in how it is structured, filtered, and surfaced.

Where Idera SQL Diagnostic Manager Fits

Idera SQL Diagnostic Manager approaches real-time monitoring with this kind of operational thinking built in. Its live session browser surfaces active requests, blocking chains, and wait types in a single view with sub-minute refresh, without requiring custom queries or multiple tool switches. The execution plan viewer pulls the cached plan for any selected session directly from sys.dm_exec_query_plan and renders it graphically, letting DBAs move from symptom to plan to decision in one workflow.

The wait statistics view presents deltas rather than cumulative totals, which is the correct framing for real-time troubleshooting. Tempdb and memory pressure indicators are surfaced alongside session data rather than in separate dashboards. And because SQL Diagnostic Manager maintains historical baselines, what appears in the real-time view can be immediately compared to what normal looks like for that specific instance, removing the guesswork that makes troubleshooting under pressure harder than it needs to be.

For teams whose troubleshooting workflow currently involves running DMV queries from memory while an incident is in progress, that is the gap worth closing.

Reference: Pinal Dave (https://blog.sqlauthority.com/), X

First appeared on Real-Time Performance Views That Make Troubleshooting Easier

2026-04-15

• Show a clear message when Copilot Pro trial is paused instead of a generic policy error
• Status bar shows @files and #issues hints while typing, and /help hint when the slash command picker is open
• Clipboard copy on WSL no longer leaks an invisible BOM character into pasted text
• Add /ask command to ask a quick question without affecting conversation history
• Add copilot plugin marketplace update command to refresh plugin catalogs

Microsoft has sharply raised prices across its Surface lineup as RAM and component costs keep climbing. "Both its midrange and flagship Surface lines are now significantly more expensive than they were just a few weeks ago, with the flagship Surface Laptop 7 and Surface Pro 11 now starting at $500 more than they launched at in 2024," reports Windows Central. From the report: The Surface Pro 12-inch, which was previously Microsoft's cheapest modern Surface PC at $799, now starts at $1,049. The flagship Surface Pro 13-inch, which originally launched for $999, now starts at an eyewatering $1,499. It's the same story for the Surface Laptop lines, with the entry-level 13-inch model originally priced at $899, now starting at $1,149. The 13.8-inch flagship Surface Laptop launched at $999, but now costs $1,499, with the 15-inch model now starting at $1,599. This means that Microsoft's midrange devices now cost more than the flagships did when they launched in 2024. [...] Microsoft has raised prices for all SKUs on offer, meaning the high end models are now more expensive too. A top end Surface Laptop 15-inch with Snapdragon X Elite, 64GB RAM and 1TB SSD storage now costs a staggering $3,649. To compare, the 16-inch MacBook Pro with an M5 Pro, 64GB RAM, and 1TB SSD is $3,299, and that comes with a significantly better display and much more power under the hood.

Read more of this story at Slashdot.

Microsoft vice president Scott Hanselman has brought a semi-useful Mac feature to Windows 11.

The post Scott Hanselman Brings a macOS Feature to Windows appeared first on Thurrott.com.