Rediģēt

Kopīgot, izmantojot

Use the Query Store with In-Memory OLTP

  • Raksts

Applies to: SQL Server Azure SQL Database

SQL Server Query Store allows you to monitor the performance of natively compiled code for workloads running in-memory OLTP.

Compile and runtime statistics are collected and exposed the same way as for disk-based workloads. When you migrate to in-memory OLTP, you can continue using Query Store views in SQL Server Management Studio and custom scripts you have developed for disk-based workloads before migration. This saves your investment in learning Query Store technology and makes it usable for troubleshooting all workloads.
For general information on using the Query Store, see Monitoring Performance By Using the Query Store.

Using the Query Store with in-memory OLTP requires no additional feature configuration. When you enable it on your database, it works for all types of workloads.
However, there are some specific aspects that users should be aware of when using Query Store with in-memory OLTP:

  • When Query Store is enabled, queries, plans, and compile-time statistics are collected by default. However, runtime statistics collection is only activated if you explicitly enable it with sys.sp_xtp_control_query_exec_stats (Transact-SQL).

  • When you set @new_collection_value to 0, the Query Store stops collecting runtime statistics for the affected procedure or the entire SQL Server instance.

  • The value configured with sys.sp_xtp_control_query_exec_stats (Transact-SQL) isn't persisted. Make sure you check and configure again the statistics collection after restarting SQL Server.

  • As with regular query statistics collection, performance may decrease when you use Query Store to track workload execution. Consider enabling statistics collection only for an important subset of natively compiled stored procedures.

  • Queries and plans are captured and stored on the first native compilation and updated upon every recompilation.

  • If you enabled Query Store or cleared its content after all native stored procedures were compiled you must recompile them manually to make them capture by the Query Store. The same applies if you removed queries manually by using sp_query_store_remove_query (Transact-SQL) or sp_query_store_remove_plan (Transact-SQL). Use sp_recompile (Transact-SQL) to force procedure recompilation.

  • Query Store leverages plan generation mechanisms from in-memory OLTP to capture query execution plan during the compilation. Stored plan is semantically equivalent to one that you would get by using SET SHOWPLAN_XML ON with one difference; plans in Query Store are split and stored per individual statement.

  • When you run Query Store in a database with a mixed workload, then you can use the is_natively_compiled field from sys.query_store_plan (Transact-SQL) to quickly find query plans that are generated by the native code compilation.

  • Query Store capture mode (QUERY_CAPTURE_MODE parameter in ALTER TABLE statement) doesn't affect queries from natively compiled modules as they're always captured regardless of the configured value. This includes setting QUERY_CAPTURE_MODE = NONE.

  • The duration of query compilation captured by the Query Store includes only time spent in query optimization before the native code was generated. More precisely, it doesn't include time for C code compilation and generation of internal structures necessary for C code generation.

  • Memory grants metrics within sys.query_store_runtime_stats (Transact-SQL) aren't populated for natively compiled queries - their values are always 0. The memory grants columns are: avg_query_max_used_memory, last_query_max_used_memory, min_query_max_used_memory, max_query_max_used_memory, and stdev_query_max_used_memory.

Enable and use Query Store with In-Memory OLTP

The following simple example demonstrates using Query Store with in-memory OLTP in an end-to-end user scenario. In this example, we assume that a database (MemoryOLTP) is enabled for in-memory OLTP.
For more information on prerequisites for memory-optimized tables, see Creating a Memory-Optimized Table and a Natively Compiled Stored Procedure.

USE MemoryOLTP;
GO

-- Create a simple memory-optimized table
CREATE TABLE dbo.Ord
   (OrdNo INTEGER not null PRIMARY KEY NONCLUSTERED,
    OrdDate DATETIME not null,
    CustCode NVARCHAR(5) not null)
WITH (MEMORY_OPTIMIZED=ON);
GO

-- Enable Query Store before native module compilation
ALTER DATABASE MemoryOLTP SET QUERY_STORE = ON;
GO

-- Create natively compiled stored procedure
CREATE PROCEDURE dbo.OrderInsert(@OrdNo integer, @CustCode nvarchar(5))
WITH NATIVE_COMPILATION, SCHEMABINDING
AS
    BEGIN ATOMIC WITH
    (TRANSACTION ISOLATION LEVEL = SNAPSHOT,
    LANGUAGE = N'English')

    DECLARE @OrdDate DATETIME = GETDATE();
    INSERT INTO dbo.Ord (OrdNo, CustCode, OrdDate)
        VALUES (@OrdNo, @CustCode, @OrdDate);
END;
GO

-- Enable runtime stats collection for queries from dbo.OrderInsert stored procedure
DECLARE @db_id INT = DB_ID()
DECLARE @proc_id INT = OBJECT_ID('dbo.OrderInsert');
DECLARE @collection_enabled BIT;

EXEC [sys].[sp_xtp_control_query_exec_stats] @new_collection_value = 1,
    @database_id = @db_id, @xtp_object_id = @proc_id;

-- Check the state of the collection flag
EXEC sp_xtp_control_query_exec_stats @database_id = @db_id,
    @xtp_object_id = @proc_id,
    @old_collection_value= @collection_enabled output;
SELECT @collection_enabled AS 'collection status';

-- Execute natively compiled workload
EXEC dbo.OrderInsert 1, 'A';
EXEC dbo.OrderInsert 2, 'B';
EXEC dbo.OrderInsert 3, 'C';
EXEC dbo.OrderInsert 4, 'D';
EXEC dbo.OrderInsert 5, 'E';

-- Check Query Store Data
-- Compile time data
SELECT q.query_id, plan_id, object_id, query_hash, p.query_plan,
    p.initial_compile_start_time, p.last_compile_start_time,
    p.last_execution_time, p.avg_compile_duration,
    p.last_force_failure_reason, p.force_failure_count
FROM sys.query_store_query AS q
JOIN sys.query_store_plan AS p
    ON q.query_id = p.plan_id
WHERE q.object_id = OBJECT_ID('dbo.OrderInsert');

-- Get runtime stats
-- Check count_executions field to verify that runtime statistics
-- have been collected by the Query Store
SELECT q.query_id, p.plan_id, object_id, rsi.start_time, rsi.end_time,
    p.last_force_failure_reason, p.force_failure_count, rs.*
FROM sys.query_store_query AS q
JOIN sys.query_store_plan AS p
    ON q.query_id = p.plan_id
JOIN sys.query_store_runtime_stats AS rs
    ON rs.plan_id = p.plan_id
JOIN sys.query_store_runtime_stats_interval AS rsi
    ON rs.runtime_stats_interval_id = rsi.runtime_stats_interval_id
WHERE q.object_id = OBJECT_ID('dbo.OrderInsert');

See also