Praktik terbaik untuk memantau beban kerja menggunakan Query Store

2025-03-05

Berlaku untuk: SQL Server 2016 (13.x) dan versi yang lebih baru Azure SQL Database Azure SQL Managed Instance Azure Synapse Analytics (khusus kumpulan SQL khusus)database SQL di Microsoft Fabric

Artikel ini menguraikan praktik terbaik untuk menggunakan SQL Server Query Store dengan beban kerja Anda.

Untuk informasi selengkapnya tentang mengonfigurasi dan mengelola dengan Penyimpanan Kueri, lihat Memantau kinerja dengan menggunakan Penyimpanan Kueri.
Untuk informasi tentang menemukan informasi yang dapat ditindaklanjuti dan menyetel performa dengan Penyimpanan Kueri, lihat Menyetel performa dengan menggunakan Penyimpanan Kueri.
Untuk informasi tentang mengoperasikan Penyimpanan Kueri di Azure SQL Database, lihat Mengoperasikan Penyimpanan Kueri di Azure SQL Database.
Di Azure Synapse Analytics, Penyimpanan Kueri tidak diaktifkan secara default untuk kumpulan SQL khusus, tetapi dapat diaktifkan. Opsi konfigurasi lebih lanjut untuk Penyimpanan Kueri tidak didukung. Untuk informasi selengkapnya, lihat Penyimpanan dan analisis kueri historis di Azure Synapse Analytics.

Menggunakan SQL Server Management Studio terbaru

SQL Server Management Studio memiliki sekumpulan antarmuka pengguna yang dirancang untuk mengonfigurasi Penyimpanan Kueri dan untuk menggunakan data yang dikumpulkan tentang beban kerja Anda. Unduh versi terbaru SQL Server Management Studio.

Untuk deskripsi singkat tentang penggunaan Query Store dalam skenario pemecahan masalah, lihat Query Store Azure blogs.

Menggunakan Wawasan Performa Kueri di Azure SQL Database

Jika Anda menjalankan Penyimpanan Kueri di Azure SQL Database, Anda bisa menggunakan Query Performance Insight untuk menganalisis konsumsi sumber daya dari waktu ke waktu. Meskipun Anda dapat menggunakan Management Studio dan Azure Data Studio untuk mendapatkan konsumsi sumber daya terperinci untuk semua kueri Anda, seperti CPU, memori, dan I/O, Wawasan Performa Kueri memberi Anda cara yang cepat dan efisien untuk menentukan efeknya pada konsumsi DTU secara keseluruhan untuk database Anda. Untuk informasi selengkapnya, lihat Azure SQL Database Query Performance Insight.

Untuk memantau performa dalam database Fabric SQL, gunakan dasbor Performa.

Menggunakan Penyimpanan Kueri dengan database Kumpulan Elastis

Anda dapat menggunakan Query Store di semua database tanpa perlu khawatir, bahkan di kumpulan elastis Azure SQL Database yang dikemas secara padat. Semua masalah sebelumnya yang terkait dengan penggunaan sumber daya berlebihan yang mungkin telah terjadi ketika Query Store diaktifkan untuk sejumlah besar database di dalam kumpulan elastis telah diselesaikan.

Mulai dengan pemecahan masalah performa kueri

Alur pemecahan masalah menggunakan Query Store bekerja sederhana, seperti yang diperlihatkan dalam diagram berikut:

Diagram pemecahan masalah Penyimpanan Kueri: Aktifkan Penyimpanan Kueri, Biarkan Penyimpanan Kueri mengumpulkan data, Menentukan dan memperbaiki kueri yang bermasalah.

Aktifkan Penyimpanan Kueri dengan menggunakan Management Studio, seperti yang dijelaskan di bagian sebelumnya, atau jalankan pernyataan Transact-SQL berikut:

ALTER DATABASE [DatabaseOne] SET QUERY_STORE = ON;

Dibutuhkan beberapa waktu sampai Query Store mengumpulkan himpunan data yang secara akurat mewakili beban kerja Anda. Biasanya, satu hari sudah cukup bahkan untuk beban kerja yang sangat kompleks. Namun, Anda dapat mulai menjelajahi data dan mengidentifikasi kueri yang membutuhkan perhatian segera setelah mengaktifkan fitur tersebut. Buka subfolder Penyimpanan Kueri di bawah simpul database di Object Explorer dari Management Studio untuk membuka tampilan pemecahan masalah untuk skenario tertentu.

Tampilan Penyimpanan Kueri Management Studio beroperasi dengan serangkaian metrik eksekusi, masing-masing dinyatakan sebagai salah satu fungsi statistik berikut:

Versi SQL Server	Indikator Kinerja	Fungsi statistik
SQL Server 2016 (13.x)	Waktu CPU, Durasi, Jumlah eksekusi, Bacaan logis, Penulisan logis, Konsumsi memori, Bacaan fisik, waktu CLR, Tingkat paralelisme (DOP), dan Jumlah baris	Rata-rata, Maksimum, Minimum, Simpang Siur Standar, Total
SQL Server 2017 (14.x)	Waktu CPU, Durasi, Jumlah eksekusi, Bacaan logis, Penulisan logis, Konsumsi memori, Bacaan fisik, waktu CLR, Tingkat paralelisme, Jumlah baris, Memori log, memori TempDB, dan Waktu tunggu	Rata-rata, Maksimum, Minimum, Simpang Siur Standar, Total

Grafik berikut ini memperlihatkan cara menemukan tampilan Penyimpanan Kueri:

Cuplikan layar dari SSMS menunjukkan lokasi tampilan Query Store.

Tabel berikut ini menjelaskan kapan harus menggunakan setiap tampilan Query Store:

Tampilan SQL Server Management Studio	Skenario
Kueri yang Mengalami Regresi	Menentukan kueri yang metrik eksekusinya baru-baru ini mengalami regresi (misalnya, berubah menjadi lebih buruk). Gunakan tampilan ini untuk menghubungkan masalah performa yang diamati dalam aplikasi Anda dengan kueri aktual yang perlu diperbaiki atau ditingkatkan.
Konsumsi Sumber Daya Keseluruhan	Analisis total konsumsi sumber daya untuk database untuk salah satu metrik eksekusi. Gunakan tampilan ini untuk mengidentifikasi pola sumber daya (beban kerja harian vs. malam) dan optimalkan konsumsi keseluruhan untuk database Anda.
Kueri dengan Konsumsi Sumber Daya Tertinggi	Pilih metrik eksekusi yang menarik, dan identifikasi kueri yang memiliki nilai paling ekstrem untuk interval waktu yang disediakan. Gunakan tampilan ini untuk memfokuskan perhatian Anda pada kueri yang paling relevan yang memiliki efek terbesar pada konsumsi sumber daya database.
Kueri Dengan Rencana Paksa	Mencantumkan rencana yang sebelumnya dipaksakan menggunakan Penyimpanan Kueri. Gunakan tampilan ini untuk dengan cepat mengakses semua rencana yang dalam paksaan saat ini.
Kueri Dengan Variasi Tinggi	Analisis kueri dengan variasi eksekusi tinggi karena berkaitan dengan salah satu dimensi yang tersedia, seperti Durasi, waktu CPU, IO, dan Penggunaan memori, dalam interval waktu yang diinginkan. Gunakan tampilan ini untuk mengidentifikasi kueri dengan performa yang sangat bervariasi yang dapat memengaruhi pengalaman pengguna di seluruh aplikasi Anda.
Statistik Tunggu Kueri	Menganalisis kategori tunggu yang paling aktif dalam database dan kueri mana yang paling berkontribusi pada kategori tunggu yang dipilih. Gunakan tampilan ini untuk menganalisis statistik tunggu dan mengidentifikasi kueri yang mungkin memengaruhi pengalaman pengguna di seluruh aplikasi Anda. Berlaku untuk: Dimulai dengan SQL Server Management Studio v18.0 dan SQL Server 2017 (14.x).
Kueri Terlacak	Lacak eksekusi kueri terpenting secara real time. Biasanya, Anda menggunakan tampilan ini saat Anda memiliki kueri dengan rencana terpaksa dan Anda ingin memastikan bahwa performa kueri stabil.

Tips

Untuk deskripsi terperinci tentang cara menggunakan Management Studio untuk mengidentifikasi kueri yang memakan sumber daya teratas dan memperbaiki kueri yang mengalami kemunculan kembali karena perubahan pilihan rencana, lihat Query Store Azure Blogs.

Saat Anda mengidentifikasi kueri dengan performa suboptimal, tindakan Anda bergantung pada sifat masalahnya.

Jika kueri dijalankan dengan beberapa rencana dan rencana terakhir secara signifikan lebih buruk dari rencana sebelumnya, Anda dapat menggunakan mekanisme pemaksaan rencana untuk memaksanya. SQL Server mencoba memaksa rencana di pengoptimal. Jika rencana memaksa gagal, XEvent diaktifkan dan pengoptimal diinstruksikan untuk mengoptimalkan dengan cara normal.

Cuplikan layar dari tombol 'Force Plan' di Query Store SSMS.

Catatan

Grafik sebelumnya mungkin menampilkan bentuk yang berbeda untuk rencana kueri tertentu, dengan arti berikut untuk setiap status yang mungkin:

Bentuk	Makna
Lingkaran	Kueri selesai, yang berarti bahwa eksekusi reguler berhasil diselesaikan.
Square	Dibatalkan, yang berarti bahwa eksekusi yang dibatalkan diinisiasi oleh klien.
Segitiga	Gagal, yang berarti bahwa eksekusi dihentikan karena pengecualian.

Selain itu, ukuran bentuk mencerminkan jumlah eksekusi kueri dalam interval waktu yang ditentukan. Ukurannya meningkat dengan jumlah eksekusi yang lebih tinggi.

Anda mungkin menyimpulkan bahwa kueri Anda kehilangan indeks untuk eksekusi yang optimal. Informasi ini ditampilkan dalam rencana eksekusi kueri. Buat indeks yang hilang, dan periksa performa kueri dengan menggunakan Query Store.

Cuplikan layar dari SSMS paket Penyimpanan Kueri, dengan pemberitahuan indeks yang hilang disorot.

Jika Anda menjalankan beban kerja di SQL Database, daftar ke SQL Database Index Advisor untuk menerima rekomendasi indeks secara otomatis.

Dalam beberapa kasus, Anda mungkin memberlakukan kompilasi ulang statistik jika Anda melihat bahwa perbedaan antara perkiraan dan jumlah baris aktual dalam rencana eksekusi signifikan.
Menulis ulang kueri bermasalah, misalnya, untuk memanfaatkan parameterisasi kueri atau menerapkan logika yang lebih optimal.

Kiat

Di Azure SQL Database, pertimbangkan fitur petunjuk Penyimpanan Kueri untuk memaksakan penggunaan petunjuk pada kueri tanpa harus mengubah kode. Untuk informasi dan contoh selengkapnya, lihat Query Store hints.

Verifikasi bahwa Penyimpanan Kueri mengumpulkan data kueri terus-menerus

Penyimpanan Kueri dapat mengubah mode operasi secara diam-diam. Pantau status Query Store secara teratur untuk memastikan bahwa Query Store beroperasi, dan mengambil tindakan pencegahan terhadap kegagalan yang disebabkan oleh faktor yang dapat dicegah. Jalankan kueri berikut untuk menentukan mode operasi dan menampilkan parameter yang paling relevan:

USE [QueryStoreDB];
GO

SELECT actual_state_desc, desired_state_desc, current_storage_size_mb,
    max_storage_size_mb, readonly_reason, interval_length_minutes,
    stale_query_threshold_days, size_based_cleanup_mode_desc,
    query_capture_mode_desc
FROM sys.database_query_store_options;

Perbedaan antara actual_state_desc dan desired_state_desc menunjukkan bahwa perubahan mode operasi terjadi secara otomatis. Perubahan yang paling umum adalah bahwa Penyimpanan Kueri secara otomatis beralih ke mode baca-saja. Dalam keadaan yang sangat jarang terjadi, Penyimpanan Kueri bisa berakhir dalam status KESALAHAN karena kesalahan internal.

Saat status aktual bersifat baca-saja, gunakan readonly_reason kolom untuk menentukan akar penyebabnya. Biasanya, Anda menemukan bahwa Query Store beralih ke mode baca-saja karena kuota ukuran terlampaui. Dalam hal ini, readonly_reason diatur ke 65536. Untuk alasan lain, lihat sys.database_query_store_options (Transact-SQL).

Pertimbangkan langkah-langkah berikut untuk mengalihkan Penyimpanan Kueri ke mode baca-tulis dan mengaktifkan pengumpulan data:

Tingkatkan ukuran penyimpanan maksimum dengan menggunakan opsi MAX_STORAGE_SIZE_MBALTER DATABASE.
Bersihkan data Penyimpanan Kueri dengan menggunakan pernyataan SQL berikut:
```
ALTER DATABASE [QueryStoreDB] SET QUERY_STORE CLEAR;
```

Anda dapat menerapkan satu atau kedua langkah ini dengan menjalankan pernyataan berikut yang secara eksplisit mengubah mode operasi kembali ke baca-tulis:

ALTER DATABASE [QueryStoreDB]
SET QUERY_STORE (OPERATION_MODE = READ_WRITE);

Lakukan langkah-langkah berikut agar proaktif:

Anda dapat mencegah perubahan mode operasi senyap dengan menerapkan praktik terbaik. Pastikan ukuran Penyimpanan Kueri selalu di bawah nilai maksimal yang diizinkan untuk mengurangi secara dramatis kemungkinan transisi ke mode baca-saja. Aktifkan kebijakan berbasis ukuran seperti yang dijelaskan di bagian Konfigurasi Penyimpanan Kueri sehingga Penyimpanan Kueri secara otomatis membersihkan data saat ukuran mendekati batas.
Untuk memastikan bahwa data terbaru disimpan, konfigurasikan kebijakan berbasis waktu untuk menghapus informasi kedaluarsa secara teratur.
Terakhir, pertimbangkan untuk mengatur Mode Penangkapan Penyimpanan Kueri ke Otomatis karena akan memfilter kueri yang biasanya kurang relevan untuk beban kerja Anda.

Status KESALAHAN

Untuk memulihkan Penyimpanan Kueri, coba atur mode baca-tulis secara eksplisit dan periksa status aktual lagi.

ALTER DATABASE [QueryStoreDB]
SET QUERY_STORE (OPERATION_MODE = READ_WRITE);
GO

SELECT actual_state_desc, desired_state_desc, current_storage_size_mb,
    max_storage_size_mb, readonly_reason, interval_length_minutes,
    stale_query_threshold_days, size_based_cleanup_mode_desc,
    query_capture_mode_desc
FROM sys.database_query_store_options;

Jika masalah berlanjut, itu menunjukkan bahwa kerusakan data Penyimpanan Kueri masih ada di disk.

Dimulai dengan SQL Server 2017 (14.x), Query Store dapat dipulihkan dengan menjalankan prosedur tersimpan sys.sp_query_store_consistency_check dalam basis data yang terpengaruh. Penyimpanan Kueri harus dinonaktifkan sebelum Anda mencoba operasi pemulihan. Berikut adalah kueri sampel untuk digunakan atau dimodifikasi untuk menyelesaikan pemeriksaan konsistensi dan pemulihan QDS:

IF EXISTS (SELECT * FROM sys.database_query_store_options WHERE actual_state=3) 
BEGIN
  BEGIN TRY
    ALTER DATABASE [QDS] SET QUERY_STORE = OFF
    Exec [QDS].dbo.sp_query_store_consistency_check
    ALTER DATABASE [QDS] SET QUERY_STORE = ON
    ALTER DATABASE [QDS] SET QUERY_STORE (OPERATION_MODE = READ_WRITE)
  END TRY
 
  BEGIN CATCH 
    SELECT  
      ERROR_NUMBER() AS ErrorNumber  
      ,ERROR_SEVERITY() AS ErrorSeverity  
      ,ERROR_STATE() AS ErrorState  
      ,ERROR_PROCEDURE() AS ErrorProcedure  
      ,ERROR_LINE() AS ErrorLine  
      ,ERROR_MESSAGE() AS ErrorMessage; 
  END CATCH;   
END

Untuk SQL Server 2016 (13.x), Anda perlu menghapus data dari Penyimpanan Kueri seperti yang ditunjukkan.

Jika pemulihan tidak berhasil, Anda bisa mencoba menghapus Query Store sebelum Anda mengatur mode baca-tulis.

ALTER DATABASE [QueryStoreDB]
SET QUERY_STORE CLEAR;
GO

ALTER DATABASE [QueryStoreDB]
SET QUERY_STORE (OPERATION_MODE = READ_WRITE);
GO

SELECT actual_state_desc, desired_state_desc, current_storage_size_mb,
    max_storage_size_mb, readonly_reason, interval_length_minutes,
    stale_query_threshold_days, size_based_cleanup_mode_desc,
    query_capture_mode_desc
FROM sys.database_query_store_options;

Hindari menggunakan kueri tanpa parameterisasi

Menggunakan kueri non-parameter ketika tidak diperlukan bukanlah praktik terbaik. Contohnya adalah dalam kasus analisis ad hoc. Rencana yang disimpan dalam cache tidak dapat digunakan kembali, yang memaksa Pengoptimal Kueri untuk mengkompilasi ulang kueri setiap kali ada teks kueri yang unik. Untuk informasi selengkapnya, lihat Panduan untuk menggunakan parameterisasi paksa.

Selain itu, Penyimpanan Kueri dapat dengan cepat melebihi kuota ukuran karena beragam teks kueri yang berbeda dan akibatnya sejumlah besar rencana eksekusi dalam bentuk yang serupa. Akibatnya, performa beban kerja Anda menjadi tidak optimal, dan Query Store mungkin beralih ke mode baca-saja atau terus-menerus menghapus data agar dapat mengikuti kueri yang masuk.

Pertimbangkan opsi berikut:

Parametrkan kueri di mana memungkinkan. Misalnya, mengemas kueri di dalam prosedur tersimpan atau sp_executesql. Untuk informasi selengkapnya, lihat Parameter dan penggunaan kembali rencana eksekusi.
Gunakan opsi optimalkan untuk beban kerja ad hoc jika beban kerja Anda berisi banyak batch ad hoc sekali pakai dengan rencana kueri yang berbeda.
- Bandingkan jumlah nilai query_hash yang berbeda dengan jumlah total entri dalam sys.query_store_query. Jika rasionya mendekati 1, beban kerja ad hoc Anda menghasilkan kueri yang berbeda.
Terapkan parameterisasi paksa untuk database atau untuk subset kueri jika jumlah paket kueri yang berbeda tidak besar.
- Gunakan panduan rencana untuk memaksa parameterisasi hanya pada kueri yang dipilih.
- Konfigurasikan parameterisasi paksa dengan menggunakan perintah opsi database parameterisasi, jika ada sejumlah kecil rencana kueri yang berbeda dalam beban kerja Anda. Contohnya adalah ketika rasio antara jumlah query_hash yang berbeda dan jumlah total entri di sys.query_store_query jauh lebih sedikit dari 1.
Atur QUERY_CAPTURE_MODE ke AUTO untuk memfilter kueri ad hoc secara otomatis dengan konsumsi sumber daya kecil.

Kiat

Saat menggunakan solusi Pemetaan Hubungan Objek (ORM) seperti Kerangka Kerja Entitas (EF), kueri aplikasi seperti pohon kueri LINQ manual atau kueri SQL mentah tertentu mungkin tidak diparameterkan, yang memengaruhi penggunaan kembali rencana dan kemampuan untuk melacak kueri di Penyimpanan Kueri. Untuk informasi selengkapnya, lihat Penyimpanan Sementara dan Parameterisasi Kueri EF dan Kueri SQL Mentah EF.

Temukan kueri yang tidak berparameter di Query Store

Anda dapat menemukan jumlah paket yang disimpan di Penyimpanan Kueri menggunakan kueri di bawah ini, menggunakan DMV Penyimpanan Kueri, di SQL Server, Azure SQL Managed Instance, atau Azure SQL Database:

SELECT count(Pl.plan_id) AS plan_count, Qry.query_hash, Txt.query_text_id, Txt.query_sql_text
FROM sys.query_store_plan AS Pl
INNER JOIN sys.query_store_query AS Qry
    ON Pl.query_id = Qry.query_id
INNER JOIN sys.query_store_query_text AS Txt
    ON Qry.query_text_id = Txt.query_text_id
GROUP BY Qry.query_hash, Txt.query_text_id, Txt.query_sql_text
ORDER BY plan_count desc;

Sampel berikut membuat Extended Events session untuk menangkap peristiwa query_store_db_diagnostics, yang dapat berguna dalam mendiagnosis konsumsi sumber daya kueri. Di SQL Server, sesi kejadian yang diperluas ini membuat file peristiwa di folder Log SQL Server secara default. Misalnya, dalam penginstalan SQL Server 2019 (15.x) default di Windows, file peristiwa (file.xel) harus dibuat di folder C:\Program Files\Microsoft SQL Server\MSSQL15.MSSQLSERVER\MSSQL\Log. Untuk Azure SQL Managed Instance, tentukan lokasi Azure Blob Storage sebagai gantinya. Untuk informasi selengkapnya, lihat XEvent event_file untuk Azure SQL Managed Instance. Acara 'qds.query_store_db_diagnostics' tidak tersedia untuk Azure SQL Database.

CREATE EVENT SESSION [QueryStore_Troubleshoot] ON SERVER 
ADD EVENT qds.query_store_db_diagnostics(
      ACTION(sqlos.system_thread_id,sqlos.task_address,sqlos.task_time,sqlserver.database_id,sqlserver.database_name))
ADD TARGET package0.event_file(SET filename=N'QueryStore',max_file_size=(100))
WITH (MAX_MEMORY=4096 KB,EVENT_RETENTION_MODE=ALLOW_SINGLE_EVENT_LOSS,MAX_DISPATCH_LATENCY=30 SECONDS,MAX_EVENT_SIZE=0 KB,MEMORY_PARTITION_MODE=NONE,TRACK_CAUSALITY=OFF,STARTUP_STATE=OFF);

Dengan data ini Anda dapat menemukan jumlah rencana di Penyimpanan Kueri, dan banyak statistik lainnya. Cari plan_count kolom, query_count, max_stmt_hash_map_size_kb, dan max_size_mb dalam data peristiwa, untuk memahami jumlah memori yang digunakan dan jumlah rencana yang dilacak oleh Penyimpanan Kueri. Jika jumlah rencana lebih tinggi dari biasanya, ini mungkin menunjukkan peningkatan kueri non-parameterisasi. Gunakan kueri Dynamic Management Views (DMVs) Query Store di bawah ini untuk meninjau kueri berparameter dan kueri non-parameter di Query Store.

Untuk kueri berparameter:

SELECT qsq.query_id, qsqt.query_sql_text
FROM sys.query_store_query AS qsq 
INNER JOIN sys.query_store_query_text AS qsqt
ON qsq.query_text_id= qsqt.query_text_id 
WHERE qsq.query_parameterization_type<>0 or qsqt.query_sql_text like '%@%';

Untuk kueri non-parametrik:

SELECT qsq.query_id, qsqt.query_sql_text
FROM sys.query_store_query AS qsq 
INNER JOIN sys.query_store_query_text AS qsqt
ON qsq.query_text_id= qsqt.query_text_id 
WHERE query_parameterization_type=0;

Hindari pola DROP dan CREATE untuk memuat objek

Query Store mengaitkan entri kueri dengan objek yang memuat, seperti prosedur tersimpan, fungsi, dan pemicu. Saat Anda membuat ulang objek yang berisi, entri kueri baru dibuat untuk teks kueri yang sama. Ini mencegah Anda melacak statistik performa untuk kueri tersebut dari waktu ke waktu dan menggunakan mekanisme pemaksaan rencana. Untuk menghindari situasi ini, gunakan proses ALTER <object> untuk mengubah definisi objek yang berisi ketika memungkinkan.

Periksa status rencana yang dipaksakan secara teratur

Pemaksaan rencana adalah mekanisme yang mudah digunakan untuk memperbaiki kinerja kueri penting dan membuatnya lebih dapat diprediksi. Seperti halnya petunjuk rencana dan panduan rencana, memaksa rencana bukanlah jaminan bahwa rencana tersebut akan digunakan dalam eksekusi di masa mendatang. Biasanya, ketika skema database berubah dengan cara objek yang direferensikan oleh rencana eksekusi diubah atau dihilangkan, rencana memaksa mulai gagal. Dalam hal ini, SQL Server mengandalkan kompilasi ulang kueri sementara alasan sebenarnya dari kegagalan pemaksaan muncul di sys.query_store_plan. Kueri di bawah ini mengembalikan informasi tentang rencana paksa:

USE [QueryStoreDB];
GO

SELECT p.plan_id, p.query_id, q.object_id as containing_object_id,
    force_failure_count, last_force_failure_reason_desc
FROM sys.query_store_plan AS p
JOIN sys.query_store_query AS q on p.query_id = q.query_id
WHERE is_forced_plan = 1;

Untuk daftar lengkap alasannya, lihat sys.query_store_plan. Anda juga dapat menggunakan query_store_plan_forcing_failed XEvent untuk melacak dan memecahkan masalah kegagalan pemaksaan rencana.

Tips

Di Azure SQL Database, pertimbangkan fitur Petunjuk Penyimpanan Kueri untuk menerapkan petunjuk kueri tanpa mengubah kode. Untuk informasi dan contoh selengkapnya, lihat petunjuk Query Store.

Hindari mengganti database untuk query dengan rencana terpaksa

Rencana eksekusi mereferensikan objek dengan menggunakan nama tiga bagian seperti database.schema.object.

Jika Anda mengganti nama database, pemaksaan rencana gagal, yang mengakibatkan kompilasi ulang dalam semua eksekusi kueri berikutnya.

Menggunakan Penyimpanan Kueri di server misi-kritis

Jejak bendera global 7745 dan 7752 dapat dimanfaatkan untuk meningkatkan ketersediaan database dengan menggunakan Query Store. Untuk informasi selengkapnya, lihat Melacak bendera.

Lambang pelacakan 7745 mencegah perilaku default di mana Query Store menulis data ke disk sebelum SQL Server dimatikan. Ini berarti bahwa data Penyimpanan Kueri yang telah dikumpulkan tetapi belum disimpan ke disk akan hilang, hingga jendela waktu yang ditentukan dengan DATA_FLUSH_INTERVAL_SECONDS.
Bendera pelacak 7752 mengaktifkan pemuatan asinkron Penyimpanan Kueri. Ini memungkinkan database kembali aktif dan kueri dijalankan sebelum Query Store sepenuhnya dipulihkan. Perilaku default adalah pemuatan sinkron pada Query Store. Perilaku default mencegah kueri dijalankan sebelum Penyimpanan Kueri dipulihkan tetapi juga mencegah kueri terlewatkan dalam pengumpulan data.

Catatan

Dimulai dengan SQL Server 2019 (15.x), perilaku ini dikendalikan oleh mesin, dan bendera pelacakan 7752 tidak berpengaruh.

Penting

Jika Anda menggunakan Query Store untuk mendapatkan wawasan beban kerja secara just-in-time di SQL Server 2016 (13.x), rencanakan untuk menginstal peningkatan kapasitas kinerja di SQL Server 2016 (13.x) SP2 CU2 (KB 4340759) sesegera mungkin. Tanpa peningkatan ini, ketika database berada di bawah beban kerja yang berat, pertikaian spinlock mungkin terjadi dan performa server mungkin menjadi lambat. Secara khusus, Anda mungkin melihat persaingan berat pada spinlock QUERY_STORE_ASYNC_PERSIST atau pada spinlock SPL_QUERY_STORE_STATS_COOKIE_CACHE. Setelah penyempurnaan ini diterapkan, Query Store tidak akan lagi menyebabkan kontensi spinlock.

Penting

Jika Anda menggunakan Penyimpanan Kueri untuk wawasan beban kerja tepat waktu di SQL Server (SQL Server 2016 (13.x) melalui SQL Server 2017 (14.x)), rencanakan untuk menginstal peningkatan skalabilitas kinerja di SQL Server 2016 (13.x) SP2 CU15, SQL Server 2017 (14.x) CU23, dan SQL Server 2019 (15.x) CU9 sesegera mungkin. Tanpa peningkatan ini, ketika database berada di bawah beban kerja ad hoc berat, Penyimpanan Kueri mungkin menggunakan sejumlah besar memori dan performa server mungkin menjadi lambat. Setelah penyempurnaan ini diterapkan, Query Store memberlakukan batas internal untuk jumlah memori yang dapat digunakan berbagai komponennya, dan dapat secara otomatis mengubah mode operasi menjadi baca-saja sampai memori yang cukup telah dikembalikan ke Mesin Database. Batas memori internal Query Store tidak didokumentasikan karena dapat berubah.

Penggunaan Query Store dalam replikasi geografis aktif di Azure SQL Database

Query Store pada replika aktif sekunder geografis Azure SQL Database akan menjadi salinan hanya-baca dari aktivitas pada replika utama.

Hindari tingkatan yang tidak cocok dengan replikasi geografis Azure SQL Database. Database sekunder harus berada di atau mendekati ukuran komputasi database utama yang sama, dan di tingkat layanan yang sama dari database utama. Cari tipe tunggu HADR_THROTTLE_LOG_RATE_MISMATCHED_SLO di sys.dm_db_wait_stats, yang menunjukkan pembatasan laju log transaksi pada replika primer karena jeda sekunder.

Untuk informasi selengkapnya tentang memperkirakan dan mengonfigurasi ukuran database Azure SQL sekunder replikasi geografis aktif, lihat Mengonfigurasi database sekunder.

Pastikan Query Store Anda disesuaikan dengan beban kerja.

Praktik terbaik dan rekomendasi untuk mengonfigurasi serta mengelola Penyimpanan Kueri telah dijelaskan lebih lanjut dalam artikel ini: Praktik terbaik untuk mengelola Penyimpanan Kueri.