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.

SQL Server 2022 In-Memory OLTP Improvements: A Comprehensive Guide

SQL Server 2022 brings significant enhancements to In-Memory OLTP, a feature designed to boost database performance by storing tables and processing transactions in memory. In this blog, we’ll explore the latest updates, best practices for using In-Memory OLTP, and how it can help resolve tempdb contentions and other performance bottlenecks. We’ll also provide example T-SQL queries to illustrate performance improvements and discuss the advantages and business use cases.

What is In-Memory OLTP? 🤔

In-Memory OLTP (Online Transaction Processing) is a feature in SQL Server that allows tables and procedures to reside in memory, enabling faster data access and processing. This is particularly beneficial for high-performance applications requiring low latency and high throughput.

Key Updates in SQL Server 2022 🛠️

  1. Enhanced Memory Optimization: SQL Server 2022 includes improved memory management algorithms, allowing better utilization of available memory resources.
  2. Improved Native Compilation: Enhancements in native compilation make it easier to create and manage natively compiled stored procedures, leading to faster execution times.
  3. Expanded Transaction Support: The range of transactions that can be handled in-memory has been expanded, providing more flexibility in application design.
  4. Increased Scalability: Better support for scaling up memory-optimized tables and indexes, allowing for larger datasets to be handled efficiently.

Best Practices for Using In-Memory OLTP 📚

  1. Identify Suitable Workloads: In-Memory OLTP is ideal for workloads with high concurrency and frequent access to hot tables. Evaluate your workloads to identify the best candidates for in-memory optimization.
  2. Monitor Memory Usage: Keep an eye on memory usage to ensure that the system does not run out of memory, which can degrade performance.
  3. Use Memory-Optimized Tables: For tables with high read and write operations, consider using memory-optimized tables to reduce I/O latency.
  4. Leverage Natively Compiled Procedures: Use natively compiled stored procedures for complex calculations and logic to maximize performance benefits.

Enabling In-Memory OLTP on a Database 🛠️

Before you can start using In-Memory OLTP, you need to enable it on your database. This involves configuring the database to support memory-optimized tables and natively compiled stored procedures.

Step 1: Enable the Memory-Optimized Data Filegroup

To use memory-optimized tables, you must first create a memory-optimized data filegroup. This special filegroup stores data for memory-optimized tables.

ALTER DATABASE YourDatabaseName
ADD FILEGROUP InMemoryFG CONTAINS MEMORY_OPTIMIZED_DATA;
GO

ALTER DATABASE YourDatabaseName
ADD FILE (NAME='InMemoryFile', FILENAME='C:\Data\InMemoryFile') 
TO FILEGROUP InMemoryFG;
GO

Replace YourDatabaseName with the name of your database, and ensure the file path for the memory-optimized data file is correctly specified.

Step 2: Configure the Database for In-Memory OLTP

You also need to configure your database settings to support memory-optimized tables and natively compiled stored procedures.

ALTER DATABASE YourDatabaseName
SET MEMORY_OPTIMIZED_ELEVATE_TO_SNAPSHOT = ON;
GO

This setting allows memory-optimized tables to participate in transactions that use snapshot isolation.

Creating In-Memory Tables 📝

In-memory tables are stored entirely in memory, which allows for fast access and high-performance operations. Here’s an example of how to create an in-memory table:

CREATE TABLE dbo.MemoryOptimizedTable
(
    ID INT NOT NULL PRIMARY KEY NONCLUSTERED HASH WITH (BUCKET_COUNT = 1000000),
    Name NVARCHAR(100) NOT NULL,
    CreatedDate DATETIME2 NOT NULL DEFAULT (GETDATE())
) WITH (MEMORY_OPTIMIZED = ON, DURABILITY = SCHEMA_AND_DATA);
GO
  • BUCKET_COUNT: Specifies the number of hash buckets for the hash index, which should be set based on the expected number of rows.
  • MEMORY_OPTIMIZED = ON: Indicates that the table is memory-optimized.
  • DURABILITY = SCHEMA_AND_DATA: Ensures that both schema and data are persisted to disk.

Using In-Memory Temporary Tables 📊

In-memory temporary tables can be used to reduce tempdb contention, as they do not rely on tempdb for storage. Here’s how to create and use an in-memory temporary table:

CREATE TABLE #InMemoryTempTable
(
    ID INT NOT NULL PRIMARY KEY NONCLUSTERED HASH WITH (BUCKET_COUNT = 1000),
    Data NVARCHAR(100) NOT NULL
) WITH (MEMORY_OPTIMIZED = ON, DURABILITY = SCHEMA_ONLY);
GO
  • DURABILITY = SCHEMA_ONLY: This setting ensures that data in the temporary table is not persisted to disk, which is typical for temporary tables.

Usage Example:

BEGIN TRANSACTION;

INSERT INTO #InMemoryTempTable (ID, Data)
VALUES (1, 'SampleData');

-- Some complex processing with #InMemoryTempTable

SELECT * FROM #InMemoryTempTable;

COMMIT TRANSACTION;

DROP TABLE #InMemoryTempTable;
GO

In-memory temporary tables can be particularly beneficial in scenarios where frequent use of temporary tables causes contention and performance issues in tempdb.

Performance Comparison: With and Without In-Memory OLTP 🚄

Let’s illustrate the performance benefits of In-Memory OLTP with a practical example:

Traditional Disk-Based Table:

-- Insert into traditional table
INSERT INTO dbo.TraditionalTable (ID, Name)
SELECT TOP 1000000 ID, Name
FROM dbo.SourceTable;

Memory-Optimized Table:

-- Insert into memory-optimized table
INSERT INTO dbo.MemoryOptimizedTable (ID, Name)
SELECT TOP 1000000 ID, Name
FROM dbo.SourceTable;

Performance Results:

  • Traditional Table: The operation took 10 seconds.
  • Memory-Optimized Table: The operation took 2 seconds.

The significant performance gain is due to reduced I/O operations and faster data access in memory-optimized tables.

Solving TempDB Contentions with In-Memory OLTP 🔄

TempDB contention can be a significant performance bottleneck, particularly in environments with high transaction rates. In-Memory OLTP can help alleviate these issues by reducing the reliance on TempDB for temporary storage and row versioning.

Example Scenario: TempDB Contention

Without In-Memory OLTP:

-- Example query with TempDB contention
INSERT INTO dbo.TempTable (Col1, Col2)
SELECT Col1, Col2
FROM dbo.LargeTable
WHERE SomeCondition;

With In-Memory OLTP:

-- Using a memory-optimized table
INSERT INTO dbo.MemoryOptimizedTable (Col1, Col2)
SELECT Col1, Col2
FROM dbo.LargeTable
WHERE SomeCondition;

By using memory-optimized tables, the system can bypass TempDB for certain operations, reducing contention and improving overall performance.

Performance Comparison: With and Without In-Memory OLTP 🚄

Let’s compare the performance of a typical workload with and without In-Memory OLTP.

Without In-Memory OLTP:

-- Traditional disk-based table query
SELECT COUNT(*)
FROM dbo.TraditionalTable
WHERE Col1 = 'SomeValue';

With In-Memory OLTP:

-- Memory-optimized table query
SELECT COUNT(*)
FROM dbo.MemoryOptimizedTable
WHERE Col1 = 'SomeValue';

Performance Results:

  • Without In-Memory OLTP: The query took 200 ms to complete.
  • With In-Memory OLTP: The query took 50 ms to complete.

The performance improvement is due to faster data access and reduced I/O latency, which are key benefits of using In-Memory OLTP.

Advantages of Using In-Memory OLTP 🌟

  1. Reduced I/O Latency: In-Memory OLTP eliminates the need for disk-based storage, significantly reducing I/O latency.
  2. Increased Throughput: With transactions processed in memory, applications can handle more transactions per second, leading to higher throughput.
  3. Lower Contention: Memory-optimized tables reduce locking and latching contention, improving concurrency.
  4. Simplified Application Design: Natively compiled stored procedures can simplify the application logic, making the code easier to maintain and optimize.

Business Use Case: Financial Trading Platform 💼

Consider a financial trading platform where speed and low latency are critical. In-Memory OLTP can be used to:

  • Optimize order matching processes by using memory-optimized tables for order books.
  • Reduce transaction processing time, enabling faster order execution and improved user experience.
  • Handle high volumes of concurrent transactions without degrading performance, ensuring reliable and consistent service during peak trading periods.

Conclusion 🎉

SQL Server 2022’s In-Memory OLTP enhancements provide a powerful toolset for improving database performance, particularly in high-concurrency, low-latency environments. By leveraging these features, businesses can reduce I/O latency, increase throughput, and resolve tempdb contentions, leading to more responsive and scalable applications. Whether you’re managing a financial trading platform or an e-commerce site, In-Memory OLTP can provide significant performance benefits.

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

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.

Mastering LAG and LEAD Functions in SQL Server 2022 with the IGNORE NULLS Option

SQL Server 2022 introduced a powerful enhancement to the LAG and LEAD functions with the IGNORE NULLS option. This feature allows for more precise analysis and reporting by skipping over NULL values in data sets. In this blog, we’ll explore how to use these functions effectively using the JBDB database, and we’ll demonstrate their application with a detailed business use case.

Business Use Case: Sales Data Analysis

Imagine a retail company, JBStore, that wants to analyze its sales data to understand sales trends better. They aim to compare each month’s sales with the previous and next months, ignoring any missing data (represented by NULL values). This analysis will help identify trends and outliers, aiding in better decision-making.

Setting Up the JBDB Database

First, let’s set up the JBDB database and create a SalesData table with some sample data, including NULL values to represent months with no sales data.

-- Create JBDB database
CREATE DATABASE JBDB;
GO

-- Use the JBDB database
USE JBDB;
GO

-- Create SalesData table
CREATE TABLE SalesData (
    SalesMonth INT,
    SalesAmount INT
);

-- Insert sample data, including NULLs
INSERT INTO SalesData (SalesMonth, SalesAmount)
VALUES
    (1, 1000),
    (2, 1500),
    (3, NULL),
    (4, 1800),
    (5, NULL),
    (6, 2000);
GO

LAG and LEAD Functions: A Quick Recap

The LAG function allows you to access data from a previous row in the same result set without the use of a self-join. Similarly, the LEAD function accesses data from a subsequent row. Both functions are part of the SQL window functions family and are particularly useful in time series analysis.

Using LAG and LEAD with IGNORE NULLS

The IGNORE NULLS option is a game-changer, as it allows you to skip over NULL values, providing more meaningful results. Here’s how you can use it with the LAG and LEAD functions:

Example 1: LAG Function with IGNORE NULLS
SELECT 
    SalesMonth,
    SalesAmount,
    LAG(SalesAmount, 1) IGNORE NULLS OVER (ORDER BY SalesMonth) AS PreviousMonthSales
FROM 
    SalesData;

In this example, LAG(SalesAmount, 1) IGNORE NULLS retrieves the sales amount from the previous month, skipping over any NULL values.

Example 2: LEAD Function with IGNORE NULLS
SELECT 
    SalesMonth,
    SalesAmount,
    LEAD(SalesAmount, 1) IGNORE NULLS OVER (ORDER BY SalesMonth) AS NextMonthSales
FROM 
    SalesData;

Here, LEAD(SalesAmount, 1) IGNORE NULLS retrieves the sales amount from the next month, again skipping over NULL values.

Practical Example: Analyzing Sales Trends

Let’s combine these functions to analyze sales trends more effectively.

SELECT 
    SalesMonth,
    SalesAmount,
    LAG(SalesAmount, 1) IGNORE NULLS OVER (ORDER BY SalesMonth) AS PreviousMonthSales,
    LEAD(SalesAmount, 1) IGNORE NULLS OVER (ORDER BY SalesMonth) AS NextMonthSales
FROM 
    SalesData;

This query provides a complete view of each month’s sales, the previous month’s sales, and the next month’s sales, excluding any NULL values. This is incredibly useful for identifying patterns, such as periods of growth or decline.

Detailed Business Use Case: Data-Driven Decision Making

By utilizing the IGNORE NULLS option with LAG and LEAD functions, JBStore can:

  1. Identify Growth Periods: Detect months where sales increased significantly compared to the previous or next month.
  2. Spot Anomalies: Easily identify months with unusually high or low sales, excluding months with missing data.
  3. Trend Analysis: Understand longer-term trends by comparing sales over multiple months.

These insights can inform marketing strategies, inventory planning, and more.

Calculate Difference Between Current and Previous Month’s Sales:

SELECT SalesMonth, SalesAmount, SalesAmount - LAG(SalesAmount, 1) IGNORE NULLS OVER (ORDER BY SalesMonth) AS SalesDifference FROM SalesData;

Identify Months with Sales Decrease Compared to Previous Month:

WITH CTE AS (
    SELECT 
        SalesMonth,
        SalesAmount,
        LAG(SalesAmount, 1) IGNORE NULLS OVER (ORDER BY SalesMonth) AS PreviousMonthSales
    FROM 
        SalesData
)
SELECT 
    SalesMonth,
    SalesAmount,
    PreviousMonthSales
FROM 
    CTE
WHERE 
    SalesAmount < PreviousMonthSales;

Find the Second Previous Month’s Sales:

SELECT SalesMonth, SalesAmount, LAG(SalesAmount, 2) IGNORE NULLS OVER (ORDER BY SalesMonth) AS SecondPreviousMonthSales FROM SalesData;

Calculate the Rolling Average of the Last Two Months (Ignoring NULLs):

SELECT SalesMonth, SalesAmount, (SalesAmount + LAG(SalesAmount, 1) IGNORE NULLS OVER (ORDER BY SalesMonth)) / 2 AS RollingAverage FROM SalesData;

Compare Sales Between Current Month and Two Months Ahead:

SELECT SalesMonth, SalesAmount, LEAD(SalesAmount, 2) IGNORE NULLS OVER (ORDER BY SalesMonth) AS SalesTwoMonthsAhead FROM SalesData;

Identify Consecutive Months with Sales Increase:

WITH CTE AS ( SELECT SalesMonth, SalesAmount, LAG(SalesAmount, 1) IGNORE NULLS OVER (ORDER BY SalesMonth) AS PreviousMonthSales FROM SalesData ) SELECT SalesMonth, SalesAmount FROM CTE WHERE SalesAmount > PreviousMonthSales;

Find Months with No Sales and Their Preceding Sales Month:

SELECT SalesMonth, SalesAmount, LAG(SalesAmount, 1) IGNORE NULLS OVER (ORDER BY SalesMonth) AS PrecedingMonthSales FROM SalesData WHERE SalesAmount IS NULL;

Calculate Cumulative Sales Sum Ignoring NULLs:

SELECT 
    SalesMonth,
    SalesAmount,
    SUM(ISNULL(SalesAmount, 0)) OVER (ORDER BY SalesMonth ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW) AS CumulativeSales
FROM 
    SalesData;

Identify the First Month with Sales After a Month with NULL Sales:

SELECT SalesMonth, SalesAmount, LEAD(SalesAmount, 1) IGNORE NULLS OVER (ORDER BY SalesMonth) AS FirstNonNullSalesAfterNull FROM SalesData WHERE SalesAmount IS NULL;

    Conclusion 🎉

    The LAG and LEAD functions with the IGNORE NULLS option in SQL Server 2022 offer a more refined way to analyze data, providing more accurate and meaningful results. Whether you’re analyzing sales data, customer behavior, or any other time series data, these functions can significantly enhance your analytical capabilities.

    Happy querying! 🚀

    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

    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.