Nuta
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Dotyczy:programu SQL Server
Azure SQL Database
Magazyn zapytań programu SQL Server umożliwia monitorowanie wydajności natywnie skompilowanego kodu dla obciążeń z systemem OLTP w pamięci.
Statystyki kompilacji i środowiska uruchomieniowego są zbierane i udostępniane w taki sam sposób jak w przypadku obciążeń opartych na dyskach.
Podczas migracji do magazynu OLTP w pamięci można nadal używać widoków magazynu zapytań w programie SQL Server Management Studio i skryptów niestandardowych opracowanych dla obciążeń opartych na dyskach przed migracją. Pozwala to zaoszczędzić inwestycję w uczenie się technologii magazynu zapytań i ułatwia rozwiązywanie problemów ze wszystkimi obciążeniami.
Aby uzyskać ogólne informacje na temat korzystania z magazynu zapytań, zobacz Monitorowanie wydajności przy użyciu magazynu zapytań.
Korzystanie z magazynu zapytań z funkcją OLTP w pamięci nie wymaga dodatkowej konfiguracji funkcji. Po włączeniu jej w bazie danych działa ona dla wszystkich typów obciążeń.
Istnieją jednak pewne konkretne aspekty, o których użytkownicy powinni wiedzieć podczas korzystania z Query Store z in-memory OLTP:
Gdy magazyn zapytań jest włączony, zapytania, plany i statystyki czasu kompilacji są zbierane domyślnie. Jednak zbieranie statystyk środowiska uruchomieniowego jest aktywowane tylko wtedy, gdy jawnie włączysz ją za pomocą sys.sp_xtp_control_query_exec_stats (Transact-SQL).
Po ustawieniu @new_collection_value na 0 magazyn zapytań zatrzymuje zbieranie statystyk środowiska uruchomieniowego dla objętej procedury lub całego wystąpienia programu SQL Server.
Wartość skonfigurowana za pomocą sys.sp_xtp_control_query_exec_stats (Transact-SQL) nie jest utrwalana. Sprawdź i skonfiguruj ponownie kolekcję statystyk po ponownym uruchomieniu programu SQL Server.
Podobnie jak w przypadku regularnego zbierania statystyk zapytań, wydajność może się zmniejszyć, gdy używasz magazynu zapytań do śledzenia wykonywania obciążenia. Rozważ włączenie zbierania statystyk tylko dla ważnego podzestawu natywnie skompilowanych procedur składowanych.
Zapytania i plany są przechwytywane i przechowywane w pierwszej kompilacji natywnej i aktualizowane po każdej ponownej kompilacji.
W przypadku włączenia magazynu zapytań lub wyczyszczenia jego zawartości po skompilowaniu wszystkich natywnych procedur składowanych należy je ponownie skompilować ręcznie, aby przechwycić je przez magazyn zapytań. To samo dotyczy ręcznego usuwania zapytań przy użyciu sp_query_store_remove_query (Transact-SQL) lub sp_query_store_remove_plan (Transact-SQL). Użyj sp_recompile (Transact-SQL), aby wymusić ponowną kompilację procedury.
Magazyn zapytań wykorzystuje mechanizmy generowania planów z OLTP w pamięci do przechwytywania planu wykonania zapytania podczas kompilacji. Przechowywany plan jest semantycznie równoważny planowi, który można uzyskać z użyciem
SET SHOWPLAN_XML ON, z jedną różnicą; plany w Magazynie Zapytań są dzielone i przechowywane dla poszczególnych instrukcji.Po uruchomieniu magazynu zapytań w bazie danych z mieszanym obciążeniem, można użyć pola is_natively_compiled z sys.query_store_plan (Transact-SQL) aby szybko odnaleźć plany zapytań generowane poprzez kompilację kodu natywnego.
Tryb przechwytywania magazynu zapytań (QUERY_CAPTURE_MODE parametr w instrukcji ALTER TABLE ) nie ma wpływu na zapytania z natywnie skompilowanych modułów, ponieważ są one zawsze przechwytywane niezależnie od skonfigurowanej wartości. Obejmuje to ustawienie
QUERY_CAPTURE_MODE = NONE.Czas trwania kompilacji zapytań przechwycony przez magazyn zapytań obejmuje tylko czas spędzony w optymalizacji zapytań przed wygenerowaniem kodu natywnego. Dokładniej mówiąc, nie obejmuje czasu na kompilację kodu języka C i generowanie struktur wewnętrznych niezbędnych do generowania kodu C.
Metryki przyznawania pamięci w sys.query_store_runtime_stats (Transact-SQL) nie są wypełniane dla natywnie skompilowanych zapytań — ich wartości są zawsze równe 0. Kolumny przydzielania pamięci to: avg_query_max_used_memory, last_query_max_used_memory, min_query_max_used_memory, max_query_max_used_memory i stdev_query_max_used_memory.
Włącz i używaj Magazynu zapytań z In-Memory OLTP
W poniższym prostym przykładzie pokazano użycie Query Store z in-memory OLTP w scenariuszu end-to-end użytkownika. W tym przykładzie przyjęto założenie, że baza danych (MemoryOLTP) jest obsługiwana w pamięci OLTP.
Aby uzyskać więcej informacji na temat wymagań wstępnych dotyczących tabel zoptymalizowanych pod kątem pamięci, zobacz Tworzenie tabeli Memory-Optimized i natywnie skompilowanej procedury składowanej.
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');
Zobacz także
- Monitorowanie wydajności przy użyciu magazynu zapytań
- Tworzenie tabeli zoptymalizowanej pod kątem pamięci i natywnie skompilowanej procedury przechowywanej
- Najlepsze praktyki z magazynem zapytań
- Procedury składowane magazynu zapytań (Transact-SQL)
- widoki wykazu magazynu zapytań zapytań (Transact-SQL)