<img src="https://erikdarling.com/wp-content/uploads/2025/08/darling-data-logo_RGB.jpg" alt="Darling Data Logo" width="300"/>

Darling Data: SQL Server Troubleshooting Scripts

Navigatory

Scripts:
- sp_PressureDetector: Quickly detect CPU and memory pressure
- sp_PerfCheck: Comprehensive SQL Server performance health check
- sp_HumanEvents: Use Extended Events to track down various query performance issues
- sp_HumanEventsBlockViewer: Analyze the blocked process report
- sp_QuickieStore: The fastest and most configurable way to navigate Query Store data
- sp_QueryReproBuilder: Generate executable reproduction scripts from Query Store data
- sp_HealthParser: Pull all the performance-related data from the system health Extended Event
- sp_LogHunter: Get all of the worst stuff out of your error log
- sp_IndexCleanup: Identify unused and duplicate indexes
- sp_QueryStoreCleanup: Remove duplicate and noisy queries from Query Store

Who are these scripts for?

You need to troubleshoot performance problems with SQL Server, and you need to do it now.

You don't have time to track down a bunch of DMVs, figure out Extended Events, wrestle with terrible SSMS interfaces, or learn XML.

These scripts aren't a replacement for a mature monitoring tool, but they do a good job of capturing important issues and reporting on existing diagnostic data

Support

Right now, all support and Q&A is handled on GitHub. Please be patient; it's just me over here answering questions, fixing bugs, and adding new features.

As far as compatibility goes, they're only guaranted to work on Microsoft-supported SQL Server versions.

Older versions are either missing too much information, or simply aren't compatible (Hello, Extended Events. Hello, Query Store) with the intent of the script.

If you have questions about performance tuning, or SQL Server in general, you'll wanna hit a Q&A site:

Back to top

Pressure Detector

Is your client/server relationship on the rocks? Are queries timing out, dragging along, or causing CPU fans to spin out of control?

All you need to do is hit F5 to get information about:

Wait stats since startup
Database file size, stall, and activity
tempdb configuration details
Memory consumers
Low memory indicators
Memory configuration and allocation
Current query memory grants, along with other execution details
CPU configuration and retained utilization details
Thread count and current usage
Any current THREADPOOL waits (best observed with the DAC)
Currently executing queries, along with other execution details

For a video walkthrough of the script and the results, head over here.

Current valid parameter details:

| parameter_name | data_type | description | valid_inputs | defaults | |----------------------------|-----------|--------------------------------------------------------------------------------|------------------------------------------------------|--------------| | @what_to_check | varchar | areas to check for pressure | "all", "cpu", and "memory" | all | | @skip_queries | bit | if you want to skip looking at running queries | 0 or 1 | 0 | | @skip_plan_xml | bit | if you want to skip getting plan XML | 0 or 1 | 0 | | @minimum_disk_latency_ms | smallint | low bound for reporting disk latency | a reasonable number of milliseconds for disk latency | 100 | | @cpu_utilization_threshold | smallint | low bound for reporting high cpu utlization | a reasonable cpu utlization percentage | 50 | | @skip_waits | bit | skips waits when you do not need them on every run | 0 or 1 | 0 | | @skip_perfmon | bit | skips perfmon counters when you do not need them on every run | a valid tinyint: 0-255 | 0 | | @sample_seconds | tinyint | take a sample of your server's metrics | 0 or 1 | 0 | | @log_to_table | bit | enable logging to permanent tables | 0 or 1 | 0 | | @log_database_name | sysname | database to store logging tables | valid database name | NULL | | @log_schema_name | sysname | schema to store logging tables | valid schema name | NULL | | @log_table_name_prefix | sysname | prefix for all logging tables | valid table name prefix | 'PressureDetector' | | @log_retention_days | integer | Number of days to keep logs, 0 = keep indefinitely | integer | 30 | | @troubleshoot_blocking | bit | show blocking chains instead of pressure analysis | 0 or 1 | 0 | | @help | bit | how you got here | 0 or 1 | 0 | | @debug | bit | prints dynamic sql, displays parameter and variable values, and table contents | 0 or 1 | 0 | | @version | varchar | OUTPUT; for support | none | none; OUTPUT | | @version_date | datetime | OUTPUT; for support | none | none; OUTPUT |

Back to top

Human Events

Extended Events are hard. You don't know which ones to use, when to use them, or how to get useful information out of them.

This procedure is designed to make them easier for you, by creating event sessions to help you troubleshoot common scenarios:

Blocking: blocked process report
Query performance: query execution metrics an actual execution plans
Compiles: catch query compilations
Recompiles: catch query recompilations
Wait Stats: server wait stats, broken down by query and database

The default behavior is to run a session for a set period of time to capture information, but you can also set sessions u

DarlingData

Install / Use

README