Posted by

Posted on

June 2, 2026

Posted under

Core

Comments

SQL Server 2025 Series : ABORT_QUERY_EXECUTION Explained with Full Live Demo!

If you manage production workloads, you’ve probably seen situations where one problematic query keeps hurting performance for everyone else. In SQL Server 2025, Microsoft highlights ABORT_QUERY_EXECUTION as a Query Store hint that lets administrators block the future execution of a known problematic query without changing application code. That makes it a practical DBA-focused safeguard when you need control quickly.

In this blog, I’ll explain what ABORT_QUERY_EXECUTION is, why it matters, the prerequisites, and then walk through a full live demo using only the code shown below. I’ll also show how to verify whether the hint is configured and how to list blocked queries recorded in Query Store. Microsoft’s product and demo references position this feature as part of the broader query-processing and administrative control improvements in SQL Server 2025.

What is ABORT_QUERY_EXECUTION?

ABORT_QUERY_EXECUTION is a query hint showcased for SQL Server 2025 that can be applied through Query Store hints to block future executions of a specific query. The available Microsoft and demo references consistently describe it as an administrative control for stopping a known bad query from continuing to impact workload stability, while avoiding application code changes.

One important clarification: this feature is described as preventing future executions of the targeted query. The references do not describe it as a general-purpose replacement for terminating a query that is already running.

Why was this introduced?

The purpose is simple and practical. Sometimes a query is known to be expensive or disruptive, but the application team cannot change the code immediately. In that situation, Query Store hints already provide a way to influence query behavior without redeploying code, and ABORT_QUERY_EXECUTION extends that model by allowing the query to be blocked from future execution.

Available references describe this feature as a way to stop rogue or problematic queries from harming the rest of the workload and to improve reliability during incidents. That is what makes it a useful operational safety valve for DBAs.

Prerequisites

Before testing this feature, the main prerequisite is that Query Store must be enabled, because ABORT_QUERY_EXECUTION works through Query Store hints. This requirement is explicitly reflected in the demo references and supporting guidance.

For this walkthrough, you need:

SQL Server 2025
A database where your demo query can be captured in Query Store
Query Store enabled for that database

Full Demo Code

			
-- ABORT_QUERY_EXECUTION
CREATE OR ALTER procedure [dbo].[usp_procdisplaydata] @Col2 int
as
begin
SELECT top (150000)
    [Col1], 
    [Col2], 
    [Col3], 
    [Col4], 
    [Col5]
FROM dbo.Table1
WHERE [Col2] = @Col2
ORDER BY [Col3];
END
EXEC [dbo].[usp_procdisplaydata] @Col2=2
SELECT TOP (20)
    q.query_id,
    qt.query_sql_text,
    rs.count_executions,
    rs.avg_duration,
    rs.last_duration
FROM sys.query_store_query_text qt
JOIN sys.query_store_query q
    ON qt.query_text_id = q.query_text_id
JOIN sys.query_store_plan p
    ON q.query_id = p.query_id
JOIN sys.query_store_runtime_stats rs
    ON p.plan_id = rs.plan_id
WHERE qt.query_sql_text LIKE N'%SELECT top (150000)%'
ORDER BY rs.last_execution_time DESC;
GO -- Query Id 38
EXEC sys.sp_query_store_set_hints
    @query_id = 38, 
    @query_hints = N'OPTION (USE HINT (''ABORT_QUERY_EXECUTION''))';
GO
SELECT *
FROM sys.query_store_query_hints
WHERE query_id = 38;
GO
EXEC [dbo].[usp_procdisplaydata] @Col2=2
EXEC sys.sp_query_store_clear_hints
    @query_id = 38;
GO
-- Blocked queries in Query Store
SELECT qsh.query_id,
       q.query_hash,
       qt.query_sql_text
FROM sys.query_store_query_hints AS qsh
INNER JOIN sys.query_store_query AS q
ON qsh.query_id = q.query_id
INNER JOIN sys.query_store_query_text AS qt
ON q.query_text_id = qt.query_text_id
WHERE UPPER(qsh.query_hint_text) LIKE '%ABORT[_]QUERY[_]EXECUTION%'

		

Step-by-Step Demo Explanation

1) Create the procedure and execute it once

The first part of the demo creates a stored procedure and executes it so the query text is captured in Query Store. That step is important because the feature is implemented through Query Store hints, and you need the corresponding query_id before you can apply the hint.

2) Find the query in Query Store

The next query searches the Query Store catalog views using the text pattern SELECT top (150000) to identify the relevant query and retrieve its query_id. In this demo script, the query id used is 38. The overall approach aligns with the feature’s dependency on Query Store metadata.

3) Apply ABORT_QUERY_EXECUTION

The core configuration step is:

			
EXEC sys.sp_query_store_set_hints
    @query_id = 38, 
    @query_hints = N'OPTION (USE HINT (''ABORT_QUERY_EXECUTION''))';

This applies the ABORT_QUERY_EXECUTION query hint through Query Store for the specific query. The available demo and product materials explicitly show this feature being implemented through sp_query_store_set_hints.

4) Verify that the hint is configured

The following verification query checks the Query Store catalog view for the configured hint:

			
SELECT *
FROM sys.query_store_query_hints
WHERE query_id = 38;

This is a practical way to verify whether ABORT_QUERY_EXECUTION has been configured for that query in your database.

5) Execute the procedure again

After the hint is applied, the procedure is executed again so you can validate the configured behavior. Based on the available references, ABORT_QUERY_EXECUTION is designed to block future executions of the targeted query once the hint is in place.

6) Clear the hint

Once testing is complete, the hint is removed using:

			
EXEC sys.sp_query_store_clear_hints
    @query_id = 38;

This completes the full end-to-end lifecycle: identify the query, apply the hint, verify it, test it, and clear it when it is no longer needed.

7) List blocked queries in Query Store

The final query in the script looks for entries in sys.query_store_query_hints where the configured hint text contains ABORT_QUERY_EXECUTION. This is useful when you want to audit or review queries that have been configured with this hint

			
SELECT qsh.query_id,
       q.query_hash,
       qt.query_sql_text
FROM sys.query_store_query_hints AS qsh
INNER JOIN sys.query_store_query AS q
ON qsh.query_id = q.query_id
INNER JOIN sys.query_store_query_text AS qt
ON q.query_text_id = qt.query_text_id
WHERE UPPER(qsh.query_hint_text) LIKE '%ABORT[_]QUERY[_]EXECUTION%'

		

ABORT_QUERY_EXECUTION is one of the more practical DBA-oriented capabilities highlighted in SQL Server 2025. It gives administrators a way to block the future execution of a known problematic query using Query Store hints, without changing application code. That makes it especially valuable when immediate workload protection is needed.

Watch the Full Demo

I’ve recorded a complete walkthrough of this setup on my YouTube channel JBSWiki. If you’re a visual learner, go check it out!

👉 Watch here: https://www.youtube.com/watch?v=SjjC18u-jjM

Thank You,
Vivek Janakiraman

Disclaimer:
The views expressed on this blog are mine alone and do not reflect the views of my company or anyone else. All postings on this blog are provided “AS IS” with no warranties, and confers no rights.

Posted by

Vivek Janakiraman

Posted on

June 2, 2026

Posted under

Core

Comments

SQL Server 2025 Series : Degree Of Parallelism (DOP) Feedback Explained with Real-Time Demo!

Parallelism tuning has always been one of the most challenging aspects of SQL Server performance optimization. DBAs often spend hours fine-tuning MAXDOP settings, trying to strike the perfect balance between performance and resource consumption.

With SQL Server 2025, this challenge is significantly reduced thanks to Degree of Parallelism (DOP) Feedback—a powerful Intelligent Query Processing feature that automatically optimizes parallel query execution.

In this blog, we will walk through:

What DOP Feedback is
How to track it using Extended Events
A real-time demo with multiple scenarios
How to validate whether DOP Feedback is working on your server

What is DOP Feedback?

DOP Feedback enables SQL Server to self-adjust the degree of parallelism for repeated queries. Instead of relying on static MAXDOP settings, SQL Server analyzes runtime performance (CPU usage, execution time, waits) and dynamically tunes DOP for subsequent executions.

This helps:

Reduce excessive CPU usage
Improve query performance
Eliminate manual tuning effort

Tracking DOP Feedback using Extended Events

To understand how SQL Server applies DOP Feedback, we can capture internal engine decisions using Extended Events.

Setup DOP Feedback Tracking

			
IF EXISTS (SELECT 1 FROM sys.server_event_sessions WHERE name = 'DOPFeedbackWatch')
    DROP EVENT SESSION DOPFeedbackWatch ON SERVER;
GO
CREATE EVENT SESSION DOPFeedbackWatch ON SERVER
ADD EVENT sqlserver.dop_feedback_eligible_query(
    ACTION(sqlserver.sql_text, sqlserver.plan_handle, sqlserver.query_hash)),
ADD EVENT sqlserver.dop_feedback_provided(
    ACTION(sqlserver.sql_text, sqlserver.plan_handle, sqlserver.query_hash)),
ADD EVENT sqlserver.dop_feedback_validation(
    ACTION(sqlserver.sql_text, sqlserver.plan_handle, sqlserver.query_hash)),
ADD EVENT sqlserver.dop_feedback_stabilized(
    ACTION(sqlserver.sql_text, sqlserver.plan_handle, sqlserver.query_hash)),
ADD EVENT sqlserver.dop_feedback_reverted(
    ACTION(sqlserver.sql_text, sqlserver.plan_handle, sqlserver.query_hash)),
ADD EVENT sqlserver.dop_feedback_analysis_stopped(
    ACTION(sqlserver.sql_text, sqlserver.plan_handle, sqlserver.query_hash)),
ADD EVENT sqlserver.dop_feedback_reassessment_failed(
    ACTION(sqlserver.sql_text, sqlserver.plan_handle, sqlserver.query_hash))
ADD TARGET package0.ring_buffer;
GO
ALTER EVENT SESSION DOPFeedbackWatch ON SERVER STATE = START;
GO

		

What this captures

This session helps us track:

When a query becomes eligible for DOP Feedback
When SQL Server adjusts DOP
Whether feedback is validated or reverted
When the system stabilizes on an optimal DOP

This gives real-time visibility into the self-tuning engine behavior.

DOP Feedback Demo (Step-by-Step)

Let’s simulate workloads to observe DOP Feedback in action.

Scenario 1: High-Volume Parallel Query (Feedback Adjusted)

			
CREATE DATABASE jbdb
GO
USE JBDB
GO
--Create table and load table
CREATE TABLE [dbo].[Table1]([Col1] [int] IDENTITY(1,1) ON [PRIMARY]
GO
set nocount on
insert into Table1 (Col2, Col3, Col4, Col5) values (1, REPLICATE ('a',4000), 10, 100)
go 999
insert into Table1 (Col2, Col3, Col4, Col5) values (2, REPLICATE ('z',4000), 11, 100)
go 99999
insert into Table1 (Col2, Col3, Col4, Col5) values (3, REPLICATE ('f',4000), 12, 100)
go 8965
insert into Table1 (Col2, Col3, Col4, Col5) values (4, REPLICATE ('g',4000), 13, 100)
go 7844
insert into Table1 (Col2, Col3, Col4, Col5) values (5, REPLICATE ('u',4000), 14, 100)
go 4567
insert into Table1 (Col2, Col3, Col4, Col5) values (2, REPLICATE ('z',4000), 11, 100)
go 751049
-- Stored Procedure to query the table
CREATE OR ALTER PROCEDURE [dbo].[usp_GetDetails] @Col2 int
AS
BEGIN
SELECT top (50000)
    [Col1], 
    [Col2], 
    [Col3], 
    [Col4], 
    [Col5]
FROM dbo.Table1
WHERE [Col2] = @Col2
ORDER BY [Col3];
END
--EXECUTE the stored procedure
EXEC [dbo].[usp_GetDetails] @Col2 = 2
--OSTRESS
C:\Program Files\Microsoft Corporation\RMLUtils>ostress -S"VIJANAK\IN2025" -E -Q"EXEC usp_GetDetails @Col2 = 2;" -n1 -r100 -q -dJBDB

		

In this scenario:

Query executes repeatedly under load
SQL Server identifies inefficiencies in parallelism
DOP is adjusted for better performance

Scenario 2: Skewed Parallelism (Feedback Evaluation)

			
use JBBlog
[dbo].[usp_SkewedParallelReport]
ostress -S"VIJANAK\IN2025" -E -Q"EXEC usp_SkewedParallelReport;" -n1 -r100 -q -dJBBlog

Here:

SQL Server evaluates skewed workloads
Determines whether reducing DOP improves efficiency
May validate or reject feedback

Monitoring Live Workload

To see what is actively running:

			
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED
  -- What SQL Statements Are Currently Running?
  SELECT [Spid] = session_Id
, ecid
, [Database] = DB_NAME(sp.dbid)
, [User] = nt_username
, [Status] = er.status
, [Wait] = wait_type
, [Individual Query] = SUBSTRING (qt.text,
      er.statement_start_offset/2,
(CASE WHEN er.statement_end_offset = -1
    THEN LEN(CONVERT(NVARCHAR(MAX), qt.text)) * 2
ELSE er.statement_end_offset END -
                er.statement_start_offset)/2)
,[Parent Query] = qt.text
, Program = program_name
, Hostname
, nt_domain
, start_time
  FROM sys.dm_exec_requests er
  INNER JOIN sys.sysprocesses sp ON er.session_id = sp.spid
  CROSS APPLY sys.dm_exec_sql_text(er.sql_handle)as qt
  where session_Id NOT IN (@@SPID)   -- Ignore this current statement.
  ORDER BY 1, 2
  go

		

This helps you:

Identify active queries
Validate parallel workloads
Correlate with Extended Event output

Key Observations from the Demo

From the above scenarios, you will typically notice:

DOP Feedback Applied Successfully
- SQL Server reduces or adjusts DOP
- Performance improves over repeated executions
Optimal DOP Identified
- No change needed
- System confirms current DOP is efficient
Query Not Eligible
- Some queries are excluded
- Depends on execution pattern and workload

Why This Matters

DOP Feedback fundamentally changes how DBAs approach tuning:

Traditional Approach	SQL Server 2025 Approach
Manual MAXDOP tuning	Automatic per-query tuning
Trial and error	Data-driven decisions
Static configuration	Adaptive optimization

Watch the Full Demo

I’ve recorded a complete walkthrough of this setup on my YouTube channel JBSWiki. If you’re a visual learner, go check it out!

👉 Watch here: https://www.youtube.com/watch?v=nVMeQeiUKTA

Final Thoughts

With SQL Server 2025, the database engine becomes smarter and more autonomous.

DOP Feedback:

Eliminates guesswork
Improves performance stability
Reduces CPU contention
Adapts dynamically to workload changes

For DBAs and performance engineers, this means less time tuning and more time delivering value.

If you are testing SQL Server 2025 in your environment, I highly recommend running this demo and observing the Extended Events output — it gives incredible insight into how the engine learns and adapts in real time.

Thank You,
Vivek Janakiraman

Posted by

Vivek Janakiraman

Posted on

August 6, 2024

Posted under

Core

Comments

SQL Server Unused Indexes: Identification, Monitoring, and Management

Indexes are crucial for optimizing query performance in SQL Server. However, not all indexes are used effectively; some might remain unused, consuming space and resources unnecessarily. In this comprehensive blog, we’ll delve into the concept of unused indexes, how to identify them, the potential risks of deleting them, and best practices for managing them. We’ll also explore real-world scenarios and provide the necessary T-SQL scripts for monitoring and handling unused indexes.

🔍 What is an Unused Index?

An unused index is an index that exists in the database but is not used by the SQL Server query optimizer. This could be due to several reasons:

Outdated Query Patterns: The index may have been useful for queries that are no longer executed.
Changes in Data Distribution: Alterations in data patterns may render the index less effective or redundant.
Incorrect Index Design: The index might not align with the current workload or data structure.

Unused indexes can lead to unnecessary resource consumption, such as additional storage space and increased overhead during data modification operations (INSERT, UPDATE, DELETE).

Risks of Removing Unused Indexes ⚠️

While removing unused indexes can free up resources, it can also lead to unexpected performance issues if not done carefully. Here are some potential risks:

Impact on Rarely Used Queries: An index might appear unused but could be critical for infrequent queries, such as quarterly reports.
Incorrect Monitoring Period: A short monitoring period might not capture all usage patterns, leading to incorrect conclusions.

Best Practices for Monitoring Unused Indexes 📊

Extended Monitoring Period: Monitor index usage over an extended period (e.g., several months) to capture all usage patterns.
Analyze Workload Patterns: Understand your workload and identify critical periods (e.g., end-of-month processing).
Test Before Removing: Always test the impact of removing an index in a non-production environment.

Advantages of Managing Unused Indexes 🌟

Improved Performance: Reducing the number of unused indexes can improve performance for data modification operations.
Reduced Storage Costs: Freeing up storage space by removing unused indexes.
Simplified Maintenance: Fewer indexes to maintain and monitor.

🔧 How to Identify Unused Indexes

Identifying unused indexes involves monitoring the usage statistics provided by SQL Server. The sys.dm_db_index_usage_stats dynamic management view (DMV) is a valuable resource for this purpose.

📋 T-SQL Script to Identify Unused Indexes

The following script retrieves information about indexes that haven’t been used since the last server restart:

SELECT 
    i.name AS IndexName,
    i.object_id,
    o.name AS TableName,
    s.name AS SchemaName,
    i.index_id,
    u.user_seeks,
    u.user_scans,
    u.user_lookups,
    u.user_updates
FROM 
    sys.indexes AS i
JOIN 
    sys.objects AS o ON i.object_id = o.object_id
JOIN 
    sys.schemas AS s ON o.schema_id = s.schema_id
LEFT JOIN 
    sys.dm_db_index_usage_stats AS u 
    ON i.object_id = u.object_id AND i.index_id = u.index_id
WHERE 
    i.is_primary_key = 0
    AND i.is_unique_constraint = 0
    AND o.type = 'U'
    AND u.index_id IS NULL
    AND u.object_id IS NULL
ORDER BY 
    s.name, o.name, i.name;

This script filters out primary key and unique constraint indexes, focusing on user-created indexes that have not been used since the last server restart.

⚠️ Potential Issues with Deleting Unused Indexes

While removing unused indexes can free up resources, it also carries potential risks:

Hidden Usage: Some indexes may not show usage in the DMV statistics if they are used infrequently or during specific maintenance operations.
Future Requirements: An index deemed unused might be needed for future queries or batch jobs, especially if they run infrequently (e.g., quarterly reports).
Inaccurate Assessment: Short monitoring periods can lead to incorrect conclusions about an index’s utility.

⏲️ Best Time Frame for Monitoring

It’s advisable to monitor index usage over a prolonged period, ideally encompassing a full business cycle (e.g., monthly, quarterly). This ensures that all potential usage patterns, including infrequent but critical operations, are accounted for.

🛠️ Handling Unused Indexes

Best Practices for Managing Unused Indexes

Prolonged Monitoring: As mentioned, extend the monitoring period to capture all usage patterns.
Review Before Deletion: Before removing an index, consult with application developers and database administrators to understand its purpose.
Testing and Staging: Always test the impact of removing an index in a staging environment before applying changes to production.
Documentation: Maintain documentation of all indexes and their intended purpose to avoid unintentional removal.

📜 Example Scenarios

1. Beneficial Removal of an Unused Index

Scenario: A retail company finds an unused index on a transactional table that has not been utilized for over a year. The index occupies significant disk space and slows down data modification operations.

Action: After thorough analysis and consultation, the company decides to remove the index, resulting in improved performance and reduced storage costs.

T-SQL for Removing the Index:

DROP INDEX IndexName ON SchemaName.TableName;

2. Problematic Removal of a Used Index

Scenario: A financial services company removes an index that appears unused based on a short monitoring period. The index was actually used for a quarterly reconciliation job, leading to significantly slower performance and extended processing times during the next quarter.

Lesson Learned: The company learned the importance of comprehensive monitoring and consultation before making changes.

🏢 Business Use Cases

Cost Optimization

Removing unused indexes can free up valuable disk space and reduce maintenance overhead, leading to cost savings. This is particularly beneficial for organizations with large databases where storage costs are a significant concern.

Performance Enhancement

By eliminating unnecessary indexes, the performance of data modification operations can be improved, leading to faster transaction processing and more efficient database operations.

🏁 Conclusion

Managing unused indexes in SQL Server requires careful analysis and a comprehensive approach. While removing unused indexes can provide benefits like reduced storage costs and improved performance, it is crucial to ensure that the indexes are genuinely unused and not required for infrequent operations. By following best practices and leveraging the right tools, you can optimize your SQL Server environment effectively.

For any questions or further guidance, feel free to reach out or leave a comment! Happy optimizing! 🚀

For more tutorials and tips on SQL Server, including performance tuning and database management, be sure to check out our JBSWiki YouTube channel.

Thank You,
Vivek Janakiraman