Tunggu Statistik dan Toko Kueri

Ada banyak posting blog di situs ini terkait dengan statistik menunggu; mereka adalah salah satu metrik terpenting yang dapat Anda gunakan saat memecahkan masalah kinerja di SQL Server. Statistik menunggu dibuat tersedia di SQL Server 2005 dan secara tradisional mereka telah mewakili menunggu di tingkat instans melalui sys.dm_os_wait_statistics. Informasi ini sangat bagus saat memecahkan masalah kinerja sistem secara umum, tetapi saat melihat kinerja kueri, informasi tunggu hanya dapat dilihat saat kueri dijalankan dan jika menunggu sumber daya melalui sys.dm_os_waiting_tasks. Data di sys.dm_os_waiting_tasks bersifat sementara (itulah yang sedang menunggu saat ini) dan tidak mudah untuk ditangkap dan disimpan selama masa aktif kueri untuk penyetelan kinerja di lain waktu.

Di SQL Server 2016 DMV baru terbuka, sys.dm_exec_session_wait_stats, yang memberikan informasi tentang menunggu sesi aktif yang ada. Jika Anda mengetahui session_id, Anda dapat melacak menunggu kueri saat kueri dimulai dan selesai (snapshot informasi di awal dan akhir kueri, lalu bedakan informasinya). Tantangannya adalah Anda harus mengetahui session_id untuk kueri, dan Anda harus menyiapkan pengambilan data terlebih dahulu – yang tidak sepele ketika Anda berada di tengah-tengah masalah prioritas tinggi.

Informasi statistik tunggu ada dalam rencana eksekusi sebenarnya yang dimulai di SQL Server 2016 SP1. Hanya 10 waktu tunggu teratas yang diambil, dan ada batasan dalam hal apa yang diwakili oleh data ini. Misalnya, CXPACKET diabaikan dan tidak disertakan dalam output, tetapi akan disertakan dalam SP2 2016 dan 2017 CU3 dan lebih tinggi – di mana menunggu paralelisme yang tidak relevan malah ditangkap oleh CXCONSUMER (yang tidak akan disertakan dalam rencana menunggu yang sebenarnya).

Jadi, bagaimana kita bisa melihat apa yang benar-benar ditunggu oleh kueri tertentu? Kita bisa menggunakan Query Store! SQL Server 2017 menyertakan penangkapan informasi statistik menunggu di penyimpanan kueri, dan fungsionalitas ini juga tersedia di Azure SQL Database. Statistik tunggu terkait dengan rencana kueri, dan diambil dari waktu ke waktu, sama seperti statistik waktu proses. Penambahan informasi statistik tunggu di Query Store adalah permintaan fitur nomor satu setelah rilis awal, dan semua informasi itu bersama-sama menciptakan kemampuan pemecahan masalah yang hebat.

Memulai

Tunggu penangkapan statistik di Query Store diaktifkan secara default untuk Azure SQL Database. Saat database baru dibuat di SQL Server 2017, atau database dimutakhirkan dari SQL Server 2014 atau yang lebih lama, penyimpanan kueri dinonaktifkan secara default... dan dengan demikian penangkapan statistik tunggu dinonaktifkan. Saat database dimutakhirkan dari SQL Server 2016, jika Penyimpanan Kueri diaktifkan, maka pengumpulan statistik tunggu untuk Penyimpanan Kueri akan diaktifkan setelah pemutakhiran.

Untuk tujuan demonstrasi, saya telah memulihkan database WideWorldImporters, lalu saya menjalankan kueri di bawah ini untuk mengaktifkan Query Store dan menghapus semua data yang mungkin telah ada sebelumnya (hanya diperlukan karena ini adalah database sampel):

ALTER DATABASE [WideWorldImporters] SET QUERY_STORE = ON;
GO
 
ALTER DATABASE [WideWorldImporters] SET QUERY_STORE 
(
  OPERATION_MODE = READ_WRITE
);
GO
 
ALTER DATABASE [WideWorldImporters] SET QUERY_STORE CLEAR;
GO

Pengaturan default digunakan dengan pernyataan di atas, dan jika Anda ingin mengubah salah satu opsi, Anda dapat melakukannya melalui UI atau melalui pernyataan ALTER DATABASE. Sekarang setelah Penyimpanan Kueri diaktifkan, penyimpanan kueri akan mulai menangkap data kueri termasuk teks kueri, paket, statistik waktu proses, dan statistik tunggu.

Melihat Statistik Tunggu

Untuk menghasilkan beberapa data, kami akan membuat prosedur tersimpan yang menjalankan kueri paralel berulang kali.

DROP PROCEDURE IF EXISTS [Sales].[OrderInfo];
GO
 
CREATE PROCEDURE [Sales].[OrderInfo]
AS
BEGIN
  WHILE 1=1
  BEGIN
    SELECT *
      FROM Sales.OrderLines ol
      INNER JOIN Warehouse.StockItems s
      ON ol.StockItemID = s.StockItemID
      OPTION (QUERYTRACEON 8649);
  END
END

Kemudian, buat file .cmd dengan kode berikut:

Ini memungkinkan kita untuk tidak jalankan SP di dalam Management Studio, yang membuat ASYNC_NETWORK_IO menunggu yang signifikan; kami ingin melihat penantian terkait dengan paralelisme. Simpan file .cmd, lalu klik dua kali untuk menjalankan. Anda dapat menghasilkan beban tambahan dengan menjalankan banyak file. Dengan skenario ini, kami terutama akan melihat waktu tunggu yang terkait dengan kueri ini, karena kami tidak memiliki beban kerja lain. Jangan ragu untuk menjalankan kueri lain terhadap database WideWorldImporters secara bersamaan jika Anda ingin menghasilkan lebih banyak lagi data tunggu.

Setelah beberapa menit, hentikan file perintah dan perluas database WideWorldImporters dalam Management Studio untuk melihat folder Query Store, dan laporan di bawahnya. Jika Anda membuka laporan Kueri Mengkonsumsi Sumber Daya Teratas, Anda akan melihat kueri prosedur tersimpan sebagai kueri teratas.

Tampilan default untuk laporan ini menunjukkan kueri dengan total durasi tertinggi. Untuk melihat kueri berdasarkan statistik tunggu, kita dapat memilih tombol Konfigurasi dan mengubahnya menjadi Waktu Tunggu (md).

Jika Anda mengarahkan kursor ke bilah untuk kueri pertama, Anda dapat melihat waktu tunggu untuk kueri tersebut. Tampilan ini saat ini merupakan satu-satunya cara untuk melihat informasi menunggu di UI, tetapi laporan tambahan khusus untuk statistik menunggu diharapkan hadir dalam rilis Management Studio di masa mendatang.

Tunggu informasi di UI

Anda yang telah bekerja dengan statistik menunggu untuk sementara waktu akan melihat bahwa deskripsi jenis menunggu berbeda. Artinya, alih-alih tipe tunggu CXPACKET untuk menunjukkan paralelisme, Anda cukup melihat "Jenis Tunggu Paralelisme." Ini adalah perbedaan mendasar di Query Store:Jenis menunggu dikelompokkan ke dalam kategori. Ada lebih dari 900 jenis tunggu yang berbeda di SQL Server saat ini, dan mencoba melacak masing-masing secara terpisah sangat mahal. Selain itu, Penyimpanan Kueri dirancang dengan mempertimbangkan semua profesional data – baik Anda ahli dalam penyetelan kinerja atau baru mulai memahami cara kerja SQL Server, Anda harus dapat menggunakan Penyimpanan Kueri untuk menemukan kueri berperforma buruk dengan mudah. Itu juga berarti membuat informasi menunggu lebih mudah dipahami. Untuk daftar lengkap kategori menunggu dan jenis menunggu di dalamnya, silakan kunjungi dokumentasi untuk sys.query_store_wait_stats.

Anda juga dapat melihat informasi tunggu menggunakan T-SQL. Contoh kueri adalah di bawah ini, yang menyertakan kueri, plan_id(s) untuk kueri itu, dan statistik tunggu untuk interval waktu tertentu:

SELECT TOP (10)
  [ws].[wait_category_desc],
  [ws].[avg_query_wait_time_ms],
  [ws].[total_query_wait_time_ms],
  [ws].[plan_id],
  [qt].[query_sql_text],
  [rsi].[start_time],
  [rsi].[end_time]
FROM [sys].[query_store_query_text] [qt]
JOIN [sys].[query_store_query] [q]
    ON [qt].[query_text_id] = [q].[query_text_id]
JOIN [sys].[query_store_plan] [qp] 
    ON [q].[query_id] = [qp].[query_id]
JOIN [sys].[query_store_runtime_stats] [rs] 
    ON [qp].[plan_id] = [rs].[plan_id]
JOIN [sys].[query_store_runtime_stats_interval] [rsi] 
    ON [rs].[runtime_stats_interval_id] = [rsi].[runtime_stats_interval_id]
JOIN [sys].[query_store_wait_stats] [ws]
    ON [ws].[runtime_stats_interval_id] = [rs].[runtime_stats_interval_id]
    AND [ws].[plan_id] = [qp].[plan_id]
WHERE [rsi].[end_time] > DATEADD(MINUTE, -5, GETUTCDATE()) 
AND [ws].[execution_type] = 0
ORDER BY [ws].[avg_query_wait_time_ms] DESC;

Keluaran kueri

Meskipun Anda sekarang dapat melihat semua menunggu untuk kueri tertentu dan rencananya, Anda masih harus menggali lebih jauh ke dalam kinerja untuk memahami, misalnya, mengapa kueri berjalan secara paralel (bila mungkin Anda tidak menginginkannya) atau apa yang mungkin memblokir kueri. Perhatikan bahwa statistik tunggu, seperti statistik waktu proses, terkait dengan rencana kueri dari waktu ke waktu. Dalam keluaran ini, panjang interval untuk Penyimpanan Kueri diatur selama 10 menit, jadi statistik tunggu adalah untuk setiap paket untuk interval 10 menit tersebut (11:50 pada 21 November 2017 hingga tengah malam pada 22 November 2017). Secara default, panjang interval saat Anda mengaktifkan Query Store adalah 60 menit.

Ringkasan

Statistik tunggu, dikombinasikan dengan rencana kueri individual, menjadikan Query Store sebagai alat yang lebih tangguh saat memecahkan masalah sistem dan kinerja kueri. Query Store adalah satu-satunya fitur yang memungkinkan Anda untuk menangkap kueri, rencana, metrik kinerja, dan statistik tunggu secara native di satu lokasi. Bagi Anda yang terbiasa dengan berbagai jenis menunggu, menyesuaikan dengan kategori yang digunakan di Query Store seharusnya tidak ada masalah. Bagi siapa pun yang baru menunggu statistik, kategori adalah tempat yang tepat untuk mulai memahami sumber daya yang menunggu kueri.