Praktik terbaik untuk memantau beban kerja dengan Penyimpanan Kueri

Artikel
03/21/2023

Berlaku untuk:SQL Server Azure SQL Database Azure SQL Managed Instance

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 performa 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 cara menggunakan Penyimpanan Kueri 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 Wawasan Performa Kueri 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 dampaknya pada konsumsi DTU secara keseluruhan untuk database Anda. Untuk informasi selengkapnya, lihat Wawasan Performa Kueri Azure SQL Database.

Menggunakan Penyimpanan Kueri dengan database Kumpulan Elastis

Anda dapat menggunakan Penyimpanan Kueri di semua database tanpa kekhawatiran, 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 Penyimpanan Kueri diaktifkan untuk sejumlah besar database di kumpulan elastis telah diselesaikan.

Mulai dengan pemecahan masalah performa kueri

Alur kerja pemecahan masalah dengan Penyimpanan Kueri sederhana, seperti yang diperlihatkan dalam diagram berikut:

Query Store troubleshooting

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	Metrik eksekusi	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:

Query Store views

Tabel berikut ini menjelaskan kapan harus menggunakan setiap tampilan Penyimpanan Kueri:

Tampilan SQL Server Management Studio	Skenario
Kueri yang Diregresikan	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 Penggunaan Sumber Daya Teratas	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 dampak terbesar terhadap konsumsi sumber daya database.
Kueri Dengan Paket Paksa	Mencantumkan paket yang sebelumnya dipaksakan menggunakan Penyimpanan Kueri. Gunakan tampilan ini untuk mengakses semua paket yang saat ini dipaksakan dengan cepat.
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 paket paksa dan Anda ingin memastikan bahwa performa kueri stabil.

Tip

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 paket dan paket 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.

Query Store force plan

Catatan

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

Shape	Arti
Lingkaran	Kueri selesai, yang berarti bahwa eksekusi reguler berhasil diselesaikan.
Square	Dibatalkan, yang berarti bahwa eksekusi dibatalkan yang dimulai klien.
Segitiga	Gagal, yang berarti bahwa pengecualian dibatalkan eksekusi.

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 muncul dalam rencana eksekusi kueri. Buat indeks yang hilang, dan periksa performa kueri dengan menggunakanQuery Store.

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.

Tip

Di Azure SQL Database, pertimbangkan fitur petunjuk Penyimpanan Kueri untuk memaksa petunjuk kueri pada kueri tanpa perubahan kode. Untuk informasi dan contoh selengkapnya, lihat Petunjuk Penyimpanan Kueri.

Verifikasi bahwa Penyimpanan Kueri mengumpulkan data kueri terus menerus

Penyimpanan Kueri dapat mengubah mode operasi secara diam-diam. Pantau status Penyimpanan Kueri secara teratur untuk memastikan bahwa Penyimpanan Kueri beroperasi, dan untuk mengambil tindakan untuk menghindari kegagalan karena penyebab 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 agar Penyimpanan Kueri beralih secara diam-diam 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 Penyimpanan Kueri 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_MB .ALTER DATABASE
Bersihkan data Penyimpanan Kueri dengan menggunakan pernyataan 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 yang diizinkan secara maksimal untuk secara dramatis mengurangi 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 Pengambilan Penyimpanan Kueri ke Otomatis karena 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 dipertahankan pada disk.

Dimulai dengan SQL Server 2017 (14.x), Penyimpanan Kueri dapat dipulihkan dengan menjalankan prosedur tersimpan sys.sp_query_store_consistency_check dalam database 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 diperlihatkan.

Jika pemulihan tidak berhasil, Anda bisa mencoba menghapus Penyimpanan Kueri 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 non-parameter

Menggunakan kueri non-parameter saat itu tidak diperlukan bukanlah praktik terbaik. Contohnya adalah dalam kasus analisis ad hoc. Paket singgahan tidak dapat digunakan kembali, yang memaksa Pengoptimal Kueri untuk mengkompilasi kueri untuk setiap teks kueri unik. Untuk informasi selengkapnya, lihat Panduan untuk menggunakan parameterisasi paksa.

Selain itu, Penyimpanan Kueri dapat dengan cepat melebihi kuota ukuran karena sejumlah besar teks kueri yang berbeda dan akibatnya sejumlah besar rencana eksekusi yang berbeda dengan bentuk yang sama. Akibatnya, performa beban kerja Anda bersifat suboptimal, dan Penyimpanan Kueri mungkin beralih ke mode baca-saja atau terus menghapus data untuk mencoba mengikuti kueri masuk.

Pertimbangkan opsi berikut:

Parameterisasi kueri jika berlaku. Misalnya, membungkus 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 paket 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 untuk 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 OTOMATIS untuk memfilter kueri ad hoc secara otomatis dengan konsumsi sumber daya kecil.

Tip

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 Penembolokan dan parameterisasi Kueri EF dan Kueri SQL Mentah EF.

Menemukan kueri yang tidak berparameter di Penyimpanan Kueri

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 sesi Extended Events untuk mengambil 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. Peristiwa '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 paket di Penyimpanan Kueri, dan juga banyak statistik lainnya juga. Cari plan_countkolom , , query_countmax_stmt_hash_map_size_kb, dan max_size_mb dalam data peristiwa, untuk memahami jumlah memori yang digunakan dan jumlah paket yang dilacak oleh Penyimpanan Kueri. Jika jumlah paket lebih tinggi dari normal, itu mungkin menunjukkan peningkatan kueri non-parameter. Gunakan kueri DMV Penyimpanan Kueri di bawah ini untuk meninjau kueri berparameter dan kueri non-parameter di Penyimpanan Kueri.

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-parameter:

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

Penyimpanan Kueri mengaitkan entri kueri dengan objek yang berisi, 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 pemakaian rencana. Untuk menghindari situasi ini, gunakan ALTER <object> proses untuk mengubah definisi objek yang berisi kapan pun memungkinkan.

Periksa status paket paksa secara teratur

Rencana memaksa adalah mekanisme yang nyaman untuk memperbaiki performa untuk 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 kembali ke kompilasi ulang kueri sementara alasan kegagalan memaksa yang sebenarnya muncul di sys.query_store_plan. Kueri berikut mengembalikan informasi tentang paket 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 pemakaian rencana.

Tip

Hindari mengganti nama database untuk kueri dengan paket paksa

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

Jika Anda mengganti nama database, rencana memaksa gagal, yang menyebabkan kompilasi ulang di semua eksekusi kueri berikutnya.

Menggunakan Penyimpanan Kueri di server misi-kritis

Bendera pelacakan global 7745 dan 7752 dapat digunakan untuk meningkatkan ketersediaan database dengan menggunakan Penyimpanan Kueri. Untuk informasi selengkapnya, lihat Melacak bendera.

Bendera pelacakan 7745 mencegah perilaku default di mana Penyimpanan Kueri menulis data ke disk sebelum SQL Server dapat 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 pelacakan 7752 memungkinkan beban asinkron Penyimpanan Kueri. Ini memungkinkan database menjadi online dan kueri dijalankan sebelum Penyimpanan Kueri telah sepenuhnya dipulihkan. Perilaku default adalah melakukan beban sinkron Penyimpanan Kueri. 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 Penyimpanan Kueri untuk wawasan beban kerja just-in-time di SQL Server 2016 (13.x), rencanakan untuk menginstal peningkatan skalabilitas performa 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 dapat terjadi dan performa server mungkin menjadi lambat. Secara khusus, Anda mungkin melihat pertikaian QUERY_STORE_ASYNC_PERSIST berat pada spinlock atau SPL_QUERY_STORE_STATS_COOKIE_CACHE spinlock. Setelah penyempurnaan ini diterapkan, Penyimpanan Kueri tidak akan lagi menyebabkan ketidakcocokan spinlock.

Penting

Jika Anda menggunakan Penyimpanan Kueri untuk wawasan beban kerja just-in-time di SQL Server (SQL Server 2016 (13.x) melalui SQL Server 2017 (14.x)), rencanakan untuk menginstal peningkatan skalabilitas performa 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. Perhatikan bahwa batas memori internal Penyimpanan Kueri tidak didokumenkan karena dapat berubah.

Menggunakan Query Store di replikasi geografis aktif Azure SQL Database

Penyimpanan Kueri pada replika geografis aktif sekunder Azure SQL Database akan menjadi salinan aktivitas baca-saja 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 jenis tunggu HADR_THROTTLE_LOG_RATE_MISMATCHED_SLO di sys.dm_db_wait_stats yang menunjukkan pembatasan laju log transaksi pada replika utama karena jeda sekunder.

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

Menjaga Penyimpanan Kueri tetap disesuaikan dengan beban kerja Anda

Praktik terbaik dan rekomendasi untuk mengonfigurasi dan mengelola Penyimpanan Kueri telah diperluas dalam artikel ini: Praktik terbaik untuk mengelola Penyimpanan Kueri.