Unleashing SQL Server 2022: Enhancements to sys.dm_exec_query_statistics_xml

In the world of data management and analysis, SQL Server 2022 has brought numerous improvements and enhancements, one of the most notable being the advancements to the dynamic management view (DMV) sys.dm_exec_query_statistics_xml. This DMV provides detailed runtime statistics about query execution, which is invaluable for performance tuning and query optimization.

In this blog, we will explore the enhancements to sys.dm_exec_query_statistics_xml in SQL Server 2022 using the JBDB database. We’ll walk through a comprehensive business use case, demonstrate these enhancements with T-SQL queries, and show how these can be leveraged for better performance insights.

Business Use Case: Optimizing an E-commerce Database ๐Ÿ›’

Imagine you are a database administrator for JBDB, an e-commerce platform with millions of users and transactions. Ensuring optimal query performance is crucial for providing a seamless user experience. You need to monitor query performance, identify slow-running queries, and understand execution patterns to make informed optimization decisions.

The JBDB Database Schema

For this demo, we’ll use a simplified version of the JBDB database with the following schema:

  • Customers: Stores customer information.
  • Orders: Stores order details.
  • OrderItems: Stores items within an order.
  • Products: Stores product details.

CREATE TABLE Customers (
    CustomerID INT PRIMARY KEY,
    Name NVARCHAR(100),
    Email NVARCHAR(100),
    CreatedAt DATETIME
);

CREATE TABLE Products (
    ProductID INT PRIMARY KEY,
    ProductName NVARCHAR(100),
    Price DECIMAL(10, 2),
    Stock INT
);

CREATE TABLE Orders (
    OrderID INT PRIMARY KEY,
    CustomerID INT FOREIGN KEY REFERENCES Customers(CustomerID),
    OrderDate DATETIME
);

CREATE TABLE OrderItems (
    OrderItemID INT PRIMARY KEY,
    OrderID INT FOREIGN KEY REFERENCES Orders(OrderID),
    ProductID INT FOREIGN KEY REFERENCES Products(ProductID),
    Quantity INT,
    Price DECIMAL(10, 2)
);
INSERT INTO Customers (CustomerID, Name, Email, CreatedAt)
VALUES 
(1, 'John Doe', 'john.doe@example.com', '2023-01-10'),
(2, 'Jane Smith', 'jane.smith@example.com', '2023-02-15'),
(3, 'Emily Johnson', 'emily.johnson@example.com', '2023-03-22'),
(4, 'Michael Brown', 'michael.brown@example.com', '2023-04-05'),
(5, 'Sarah Davis', 'sarah.davis@example.com', '2023-05-30');


INSERT INTO Products (ProductID, ProductName, Price, Stock)
VALUES 
(1, 'Laptop', 999.99, 50),
(2, 'Smartphone', 499.99, 150),
(3, 'Tablet', 299.99, 75),
(4, 'Headphones', 149.99, 200),
(5, 'Smartwatch', 199.99, 100);

INSERT INTO Orders (OrderID, CustomerID, OrderDate)
VALUES 
(1, 1, '2023-06-15'),
(2, 2, '2023-07-20'),
(3, 3, '2023-08-25'),
(4, 4, '2023-09-10'),
(5, 5, '2023-10-05');

INSERT INTO OrderItems (OrderItemID, OrderID, ProductID, Quantity, Price)
VALUES 
(1, 1, 1, 1, 999.99),
(2, 1, 4, 2, 149.99),
(3, 2, 2, 1, 499.99),
(4, 2, 5, 1, 199.99),
(5, 3, 3, 2, 299.99),
(6, 4, 1, 1, 999.99),
(7, 4, 2, 1, 499.99),
(8, 5, 5, 2, 199.99),
(9, 5, 3, 1, 299.99);

Enhancements to sys.dm_exec_query_statistics_xml ๐Ÿ†•

SQL Server 2022 introduces several key enhancements to sys.dm_exec_query_statistics_xml, including:

  1. Enhanced Plan Information: More detailed execution plan information is now available.
  2. Wait Statistics: Comprehensive wait statistics are included to identify bottlenecks.
  3. Query Store Integration: Better integration with the Query Store for historical analysis.

Demonstrating Enhancements with T-SQL Queries ๐Ÿ“Š

Let’s dive into some T-SQL queries to see these enhancements in action.

Step 1: Capture a Sample Query Execution

First, we’ll execute a sample query to fetch order details along with customer and product information.

SELECT o.OrderID, o.OrderDate, c.Name AS CustomerName, p.ProductName, oi.Quantity, oi.Price
FROM
Orders o
JOIN
Customers c ON o.CustomerID = c.CustomerID
JOIN
OrderItems oi ON o.OrderID = oi.OrderID
JOIN
Products p ON oi.ProductID = p.ProductID
WHERE
o.OrderDate BETWEEN '2023-01-01' AND '2023-12-31';

Step 2: Retrieve Query Statistics XML

Next, we’ll use sys.dm_exec_query_statistics_xml to retrieve detailed execution statistics for the above query.

WITH XMLNAMESPACES (DEFAULT 'http://schemas.microsoft.com/sqlserver/2004/07/showplan')
SELECT
qst.sql_handle,
qst.plan_handle,
qst.execution_count,
qst.total_worker_time,
qst.total_elapsed_time,
qst.total_logical_reads,
qst.total_physical_reads,
qst.creation_time,
qst.last_execution_time,
q.text AS query_text,
qpx.query_plan
FROM
sys.dm_exec_query_stats AS qst
CROSS APPLY
sys.dm_exec_sql_text(qst.sql_handle) AS q
CROSS APPLY
sys.dm_exec_query_plan(qst.plan_handle) AS qpx
WHERE
q.text LIKE '%SELECT o.OrderID, o.OrderDate, c.Name AS CustomerName, p.ProductName, oi.Quantity, oi.Price%';

Step 3: Analyzing Enhanced Plan Information ๐Ÿ”

With SQL Server 2022, the execution plan XML now includes more detailed information about the query execution. You can parse the XML to extract specific details.

WITH XMLNAMESPACES (DEFAULT 'http://schemas.microsoft.com/sqlserver/2004/07/showplan')
SELECT 
    query_plan.value('(//RelOp/LogicalOp)[1]', 'NVARCHAR(100)') AS LogicalOperation,
    query_plan.value('(//RelOp/PhysicalOp)[1]', 'NVARCHAR(100)') AS PhysicalOperation,
    query_plan.value('(//RelOp/RunTimeInformation/RunTimeCountersPerThread/ActualRows)[1]', 'INT') AS ActualRows,
    query_plan.value('(//RelOp/RunTimeInformation/RunTimeCountersPerThread/ActualEndOfScans)[1]', 'INT') AS ActualEndOfScans
FROM 
    (SELECT CAST(qpx.query_plan AS XML) AS query_plan
     FROM sys.dm_exec_query_stats qs
     CROSS APPLY sys.dm_exec_query_plan(qs.plan_handle) AS qpx
     WHERE qs.sql_handle = (SELECT sql_handle FROM sys.dm_exec_requests WHERE session_id = @@SPID)) AS x;

Step 4: Monitoring Wait Statistics โฑ๏ธ

Wait statistics help identify performance bottlenecks such as CPU, IO, or memory waits. SQL Server 2022 provides enhanced wait statistics in the query execution plans.

WITH XMLNAMESPACES (DEFAULT 'http://schemas.microsoft.com/sqlserver/2004/07/showplan')
SELECT 
    wait_type,
    wait_time_ms AS total_wait_time_ms,
    wait_time_ms - signal_wait_time_ms AS resource_wait_time_ms,
    signal_wait_time_ms
FROM 
    sys.dm_exec_session_wait_stats
WHERE 
    session_id = @@SPID;

Leveraging Query Store Integration ๐Ÿ“ˆ

SQL Server 2022’s improved integration with the Query Store allows for historical query performance analysis, helping you understand performance trends and regressions.

SELECT 
    qsp.plan_id,
    qsp.query_id,
    qsqt.query_sql_text AS query_text,
    qsrs.count_executions AS execution_count,
    qsrs.avg_duration,
    qsrs.avg_cpu_time,
    qsrs.avg_logical_io_reads
FROM 
    sys.query_store_runtime_stats qsrs
JOIN 
    sys.query_store_plan qsp ON qsrs.plan_id = qsp.plan_id
JOIN 
    sys.query_store_query qsq ON qsp.query_id = qsq.query_id
JOIN 
    sys.query_store_query_text qsqt ON qsq.query_text_id = qsqt.query_text_id
WHERE 
    qsqt.query_sql_text LIKE '%SELECT o.OrderID, o.OrderDate, c.Name AS CustomerName, p.ProductName, oi.Quantity, oi.Price%';

Conclusion ๐ŸŽ‰

The enhancements to sys.dm_exec_query_statistics_xml in SQL Server 2022 provide deeper insights into query performance, making it easier to identify and resolve performance issues. By leveraging these new capabilities, database administrators can ensure their SQL Server instances run more efficiently and effectively.

Feel free to experiment with the queries provided and explore the powerful new features SQL Server 2022 has to offer. Happy querying! ๐Ÿง‘โ€๐Ÿ’ป

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.

    Proactively Managing Transactional Replication Latency with SQL Server

    Transactional replication is a critical component of many SQL Server environments, providing high availability, load balancing, and other essential benefits. However, managing replication latency, the delay between an action occurring on the publisher and it being reflected on the subscriber, is vital for ensuring system performance and data integrity. In this blog post, we’ll explore a proactive approach to monitor and alert on replication latency, helping database administrators (DBAs) maintain optimal system health.

    The Issue:

    Replication latency can sometimes go unnoticed until it impacts the system performance or data accuracy, leading to potential data loss or business disruptions. Traditional monitoring techniques may not provide real-time alerts or may require significant manual intervention, making them less effective for immediate latency identification and resolution.

    The Script:

    To address this challenge, we introduce a SQL script designed by Vivek Janakiraman from JBSWiki, specifically crafted to monitor transactional replication latency in SQL Server environments. This script efficiently posts tracer tokens to specified publications and measures the time taken for these tokens to move through the replication components, providing a clear picture of any latency present in the system.

    /*
    Author: Vivek Janakiraman
    Company: JBSWiki
    Description: This script is used to alert in case there is Transactional replication Log reader or distribution agent latency.
    It posts tracer tokens to specified publications and measures the latency to the distributor and subscriber.
    */

    -- Switch to the publisher database to insert tracer tokens.
    USE [Publisher_Database_Here] -- Use your publisher database name here.
    -- Insert tracer tokens into the specified publications.
    EXEC sys.sp_posttracertoken @publication = 'Publication_Name' -- Change appropriate Publication that should be monitored.
    EXEC sys.sp_posttracertoken @publication = 'Publication_Name1' -- Change appropriate Publication that should be monitored.
    -- Wait for 5 minutes to allow the tokens to propagate.
    WAITFOR DELAY '00:05:00'

    -- Switch to the distribution database to query latency information.
    USE distribution
    ;WITH LatestEntries AS (
    -- Select the latest entries for each publication and agent.
    SELECT publication_id, agent_id, MAX(publisher_commit) AS MaxDate
    FROM MStracer_tokens t
    JOIN MStracer_history h ON t.tracer_id = h.parent_tracer_id
    GROUP BY publication_id, agent_id
    )
    -- Select latency information for the latest tokens.
    SELECT c.name, t.publication_id, h.agent_id, t.publisher_commit,
    ISNULL(DATEDIFF(s,t.publisher_commit,t.distributor_commit), 299) as 'Time To Dist (sec)',
    ISNULL(DATEDIFF(s,t.distributor_commit,h.subscriber_commit), 299) as 'Time To Sub (sec)'
    INTO #REPL_LATENCY
    FROM MStracer_tokens t
    JOIN MStracer_history h ON t.tracer_id = h.parent_tracer_id
    JOIN distribution.dbo.MSdistribution_agents c ON h.agent_id = c.id
    JOIN LatestEntries le ON t.publication_id = le.publication_id AND h.agent_id = le.agent_id AND t.publisher_commit = le.MaxDate
    ORDER BY t.publisher_commit DESC

    -- Check if there is any latency beyond acceptable limits and select those records.
    IF EXISTS (SELECT 1 FROM #REPL_LATENCY WHERE ([Time To Dist (sec)] > 30 OR [Time To Sub (sec)] > 30))
    BEGIN
    SELECT name, publication_id, agent_id, publisher_commit, [Time To Dist (sec)], [Time To Sub (sec)]
    INTO #REPL_LATENCY_Email
    FROM #REPL_LATENCY
    WHERE ([Time To Dist (sec)] > 30 OR [Time To Sub (sec)] > 30)
    END

    -- Prepare the HTML body content for the email alert.
    DECLARE @body_content NVARCHAR(MAX);
    SET @body_content = N'
    <style>
    table.GeneratedTable {
    width: 100%;
    background-color: #D3D3D3;
    border-collapse: collapse;
    border-width: 2px;
    border-color: #A9A9A9;
    border-style: solid;
    color: #000000;
    }
    table.GeneratedTable td, table.GeneratedTable th {
    border-width: 2px;
    border-color: #A9A9A9;
    border-style: solid;
    padding: 3px;
    }
    table.GeneratedTable thead {
    background-color: #A9A9A9;
    }
    </style>
    <table class="GeneratedTable">
    <thead>
    <tr>
    <th>name</th>
    <th>publication_id</th>
    <th>agent_id</th>
    <th>publisher_commit</th>
    <th>[Time To Dist (sec)]</th>
    <th>[Time To Sub (sec)]</th>
    </tr>
    </thead>
    <tbody>' +
    CAST(
    (SELECT td = name, '',
    td = publication_id, '',
    td = agent_id, '',
    td = publisher_commit, '',
    td = [Time To Dist (sec)], '',
    td = [Time To Sub (sec)], ''
    FROM [dbo].#REPL_LATENCY_Email
    FOR XML PATH('tr'), TYPE
    ) AS NVARCHAR(MAX)
    ) +
    N'</tbody>
    </table>';

    -- Send an email alert if there is any latency issue found.
    IF EXISTS (SELECT TOP 1 * FROM [dbo].#REPL_LATENCY_Email)
    BEGIN
    EXEC msdb.dbo.sp_send_dbmail @profile_name = 'JBSWIKI',
    @body = @body_content,
    @body_format = 'HTML',
    @recipients = 'jvivek2k1@yahoo.com',
    @subject = 'ALERT: Transactional Replication Latency Alert';
    END

    -- Cleanup temporary tables.
    DROP TABLE #REPL_LATENCY
    DROP TABLE #REPL_LATENCY_Email

    The Solution:

    The script works by first posting tracer tokens to the specified publications within the publisher database. It then waits for a predetermined amount of time (defaulted to 5 minutes in the script) to allow the tokens to propagate through the system. Following this, the script measures the latency to the distributor and subscriber, providing a detailed report of the time taken in each stage of the replication process.

    This information is then used to generate an HTML-formatted email alert if the latency exceeds predefined thresholds (30 seconds in the provided script), allowing for immediate action to be taken. The use of HTML formatting in the email ensures that the information is presented in an easily digestible format, facilitating quick understanding and response by the DBA.

    Conclusion:

    Proactive monitoring and management of transactional replication latency are paramount for maintaining the health and performance of SQL Server environments. The script provided offers a straightforward and effective solution for DBAs to stay ahead of potential replication issues. By automating the process of latency detection and alerting, this approach not only saves valuable time but also helps in preventing the negative impact of replication latency on business operations.

    Remember, while this script serves as a valuable tool in your monitoring arsenal, it’s also important to tailor the solution to your specific environment and requirements. Regularly reviewing and adjusting the latency thresholds and monitoring frequency will ensure you continue to get the most out of your replication setup.

    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.