Seperti yang Anda ketahui, tanggung jawab utama administrator database terletak pada pemantauan kinerja SQL Server dan intervensi dalam waktu yang ditentukan. Anda dapat menemukan beberapa alat pemantauan kinerja SQL Server di pasar tetapi terkadang kami memerlukan informasi tambahan tentang kinerja SQL Server untuk mendiagnosis dan memecahkan masalah kinerja. Jadi kita harus memiliki informasi yang cukup tentang Tampilan Manajemen Dinamis SQL Server untuk menangani masalah tentang SQL Server.
Dynamic Management View (DMV) adalah konsep yang membantu kami menemukan metrik kinerja SQL Server Engine. DMV pertama kali diumumkan dalam versi SQL Server 2005 dan berlanjut di semua versi SQL Server sesudahnya. Dalam posting ini, kita akan berbicara tentang DMV tertentu yang administrator databasenya harus memiliki informasi yang cukup. Ini sys.dm_os_wait_stats .
sys.dm_os_wait_stats
sys.dm_os_wait_stats mendukung metrik penting untuk mendiagnosis masalah kinerja SQL Server. Jika Anda memiliki beberapa masalah (CPU, Memori, I/O, Kunci, Latch, dll.) di SQL Server Engine, data sys.dm_os_wait_stats memandu kami untuk menentukan masalahnya. Activity Monitor di SQL Server Management Studio menyertakan panel bernama “Resource Menunggu ”. "Resource Waits" mendapatkan metrik ini dari prosedur tersimpan khusus. Nama prosedur tersimpan sementara ini adalah “#am_generate_waitstats ” dan menggunakan sys.dm_os_wait_stats. Anda dapat menemukan prosedur tersimpan sementara ini di "tempdb". Pada titik ini, saya ingin menambahkan beberapa catatan tentang prosedur penyimpanan sementara. Karena jenis prosedur tersimpan ini tidak memiliki penggunaan yang umum.
Prosedur tersimpan sementara tidak berbeda dari prosedur tersimpan permanen. Ini memiliki dua jenis:lokal dan global seperti tabel sementara. Prosedur tersimpan lokal tetap aktif di sesi saat ini dan dihapus setelah sesi ditutup. Itu dapat dibuat seperti ini:
CREATE PROCEDURE #LocalTestSP AS PRINT Hello Local Stored Procedure
Prosedur tersimpan global juga tetap aktif di semua sesi dan dihapus setelah sesi yang dibuat ditutup. Prosedur tersimpan global dapat dibuat sebagai:
CREATE PROCEDURE ##GlobalTestSP AS PRINT Hello Global Stored Procedure
Kiat: Saat kami membuka Monitor Aktivitas, itu membuat #am_generate_waitstats prosedur tersimpan sementara dan menghapusnya setelah penutupan.
Sekarang kita akan melihat ide utama dan detail sys.dm_os_wait_stats . Kueri di bawah ini akan mengembalikan semua data tentang SQL Server "Statistik Tunggu". Permintaan ini dalam bentuk paling murni. Tidak nyaman untuk mendeteksi masalah dengan formulir seperti itu. Di bagian berikut, Anda akan menemukan kueri yang lebih berguna daripada sys.dm_os_wait_stats. Sekarang kami akan menjelaskan deskripsi kolom "Statistik Tunggu" SQL Server:
SELECT * FROM sys.dm_os_wait_stats ORDER BY wait_time_ms DESC
kolom tipe_tunggu berisi definisi atau nama statistik tunggu. data kolom wait_type penting bagi kami karena definisi statistik tunggu yang menunjukkan alasan utama masalah tersebut. waiting_tasks_count menunjukkan frekuensi jenis menunggu yang terjadi di SQL Server.
tunggu_time_ms menunjukkan total waktu tunggu. Satuan ukurannya adalah milidetik.
max_wait_time_ms menunjukkan waktu tunggu maksimum.
signal_wait_time_ms dijelaskan dalam MSDN sebagai "Perbedaan antara waktu utas menunggu ditandai dan ketika mulai berjalan". Nilai yang sangat tinggi dari kolom ini menandakan tekanan CPU. Jadi kueri menunggu dalam antrian yang dapat dijalankan dan siap dijalankan tetapi CPU sibuk dengan kueri lainnya. Karena alasan ini, kueri menunggu dalam antrian. Ketika sumber daya CPU tersedia, CPU akan mendapatkan kueri baru dari antrian yang dapat dijalankan dan akan mulai memproses. Singkatnya, kami dapat menjelaskan signal_wait_time_ms sebagai waktu tunggu dalam antrian runnable yang statusnya runnable menjadi running.
Kiat: Dalam praktik terbaik, beberapa statistik menunggu paling penting daripada yang lain. Ini dapat dicantumkan sebagai:
• PAGEIOLATCH_*
• WRITELOG
• ASYNC_NETWORK_IO
• CXPACKET
• CPU
• LCK_M_*
• PREEMPTIVE_*
• PAGELATCH_*
Lihatlah Pinal Dave atau Paul S. Randal menunggu kueri statistik. Mereka menghilangkan beberapa jenis statistik tunggu dalam kueri mereka. Jenis tunggu sumber daya di bawah ini dapat dihilangkan di sys.dm_os_wait_stats pertanyaan:
• BROKER_EVENTHANDLER
• BROKER_RECEIVE_WAITFOR
• BROKER_TASK_STOP
• BROKER_TO_FLUSH
• BROKER_TRANSMITTER
• CHECKPOINT_QUEUE
• CHKPT
•EVENT
_EVENT CLR_AUTO_EVENT
• CLR_SEMAPHORE
• DBMIRROR_DBM_EVENT
• DBMIRROR_DBM_MUTEX
• DBMIRROR_EVENTS_QUEUE
• DBMIRROR_WORKER_QUEUE
• DBMIRRORING_CMD
RE_PODIRSECHER_PAGE_POLLSECHER_PAGE_POLLSECHER_PAGE_POLLSECHER_PAGE_ />• EXECSYNC
• FSAGENT
• FT_IFTS_SCHEDULER_IDLE_WAIT
• FT_IFTSHC_MUTEX
• HADR_CLUSAPI_CALL
• HADR_FILESTREAM_IOMGR_IOCOMPLETION
TIFIKASI
• HADR_FILESTREAM_IOMGR_IOCOMPLETION
• HADR_TIMER_TASK
• HADR_WORK_QUEUE
• LAZYWRITER_SLEEP
• LOGMGR_QUEUE
• MEMORY_ALLOCATION_EXT
• ONDEMAND_TASK_QUEUE
• PREEMPTIVE_CHADR_LEASE_MEORY_HADR_LEASE_MEOS
• PREEMPTIVE_OS_COMOPS
• PREEMPTIVE_OS_CREATEFILE
• PREEMPTIVE_OS_CRYPTOPS
• PREEM Preemptive_osfileops
• preemptive_os_genericops
• preemptive_os_libraryops
• preemptive_os_pipeops
br />• PREEMPTIVE_SP_SERVER_DIAGNOSTICS
• PREEMPTIVE_XE_GETTARGETSTATE
• PWAIT_ALL_COMPONENTS_INITIALIZED
• PWAIT_DIRECTLOGCONSUMER_GETNEXT
• QDS_ASYNC_QUEUE
• QDS_CLEANUP_STALE_QUERIES_TASK_MAIN_LOOP_SLEEP
• QDS_PERSIST_TASK_MAIN_LOOP_SLEEP
• QDS_SHUTDOWN_QUEUE
• REDO_THREAD_PENDING_WORK
• REQUEST_FOR_DEADLOCK_SEARCH
• RESOURCE_QUEUE
• SERVER_IDLE_CHECK
• SLEEP_BPOOL_FLUSH
• SLEEP_DBSTARTUP
MULAI TIDUR
• TIDUR SLEEP_MASTERMDREADY
• SLEEP_MASTERUPGRADED
• SLEEP_MSDBSTARTUP
• SLEEP_SYSTEMTASK
• SLEEP_TASK
• SP_SERVER_DIAGNOSTICS_SLEEP
• SQLTRACE_BUFFER_FLUSHTRACE _INCREMENTAL_FLUSH_SLEEP
• SQLTRACE_WAIT_ENTRIES
• UCS_SESSION_REGISTRATIO
• WAIT_FOR_RESULTS
• WAIT_XTP_CKPT_CLOSE
• WAIT_XTP_HOST_WAIT_
WAIT_XTP_HOST_WAIT_
WAIT_XTP_HOST_WAIT_
br />• WAITFOR_TASKSHUTDOW
• XE_TIMER_EVENT
• XE_DISPATCHER_WAIT
• XE_LIVE_TARGET_TVF
Kiat: SQL Server mulai mengumpulkan data DMV saat dimulai atau dimulai ulang. SQL Server secara otomatis mengatur ulang statistik tunggu ketika dimulai ulang dan permintaan di bawah ini memaksa untuk mengatur ulang statistik menunggu sejak SQL Server terakhir dimulai ulang:
DBCC SQLPERF('sys.dm_os_wait_stats', CLEAR) Selain itu, akurasi pengukuran statistik tunggu adalah poin kuncinya. Pada titik ini kita dapat mempertimbangkan dua pendekatan:
• Setel ulang statistik menunggu dan ingat kembali statistik menunggu.
• Tangkap dua "statistik waktu tunggu" yang berbeda dan ukur perbedaan nilainya.
Menurut pendapat saya, menangkap dan menyimpan statistik tunggu untuk pendekatan tabel riwayat apa pun lebih baik daripada yang lain. Dalam metode ini, Anda dapat mengukur interval waktu tertentu dan tidak kehilangan statistik tunggu dari data historis.
Sekarang kita akan membuat contoh pengambilan statistik menunggu dan menampilkan data yang diambil di Power BI dengan grafik.
Kami akan membuat tabel riwayat untuk menyimpan statistik tunggu:
CREATE TABLE [dbo].[HistoryOfWaitStatistics]( [SQLStartTime] [datetime] NULL, [Dt] [datetime] NOT NULL, [WaitType] [nvarchar](60) NOT NULL, [WaitTimeSecond] [numeric](25, 6) NULL, [ResourcesWaitSecond] [numeric](25, 6) NULL, [SignalWaitSecond] [numeric](25, 6) NULL ) ON [PRIMARY]
Skrip di bawah ini menyisipkan "statistik tunggu" ke tabel riwayat. Tetapi Anda perlu menjadwalkan kueri ini di SQL Server Agent untuk menyimpan tabel riwayat:
DROP TABLE IF exists #eliminate_WS
CREATE TABLE #eliminate_WS (wait_type NVARCHAR(100));
INSERT INTO #eliminate_WS VALUES ('ASYNC_IO_COMPLETION');
INSERT INTO #eliminate_WS VALUES ('CHECKPOINT_QUEUE');
INSERT INTO #eliminate_WS VALUES ('CHKPT');
INSERT INTO #eliminate_WS VALUES ('CXPACKET');
INSERT INTO #eliminate_WS VALUES ('DISKIO_SUSPEND');
INSERT INTO #eliminate_WS VALUES ('FT_IFTS_SCHEDULER_IDLE_WAIT');
INSERT INTO #eliminate_WS VALUES ('IO_COMPLETION');
INSERT INTO #eliminate_WS VALUES ('KSOURCE_WAKEUP');
INSERT INTO #eliminate_WS VALUES ('LAZYWRITER_SLEEP');
INSERT INTO #eliminate_WS VALUES ('LOGBUFFER');
INSERT INTO #eliminate_WS VALUES ('LOGMGR_QUEUE');
INSERT INTO #eliminate_WS VALUES ('MISCELLANEOUS');
INSERT INTO #eliminate_WS VALUES ('PREEMPTIVE_XXX');
INSERT INTO #eliminate_WS VALUES ('REQUEST_FOR_DEADLOCK_SEARCH');
INSERT INTO #eliminate_WS VALUES ('RESOURCE_QUERY_SEMAPHORE_COMPILE');
INSERT INTO #eliminate_WS VALUES ('RESOURCE_SEMAPHORE');
INSERT INTO #eliminate_WS VALUES ('SOS_SCHEDULER_YIELD');
INSERT INTO #eliminate_WS VALUES ('SQLTRACE_BUFFER_FLUSH ');
INSERT INTO #eliminate_WS VALUES ('THREADPOOL');
INSERT INTO #eliminate_WS VALUES ('WRITELOG');
INSERT INTO #eliminate_WS VALUES ('XE_DISPATCHER_WAIT');
INSERT INTO #eliminate_WS VALUES ('XE_TIMER_EVENT');
INSERT INTO HistoryOfWaitStatistics
SELECT
(SELECT sqlserver_start_time FROM sys.dm_os_sys_info ) as SQLStartTime,GETDATE() AS Dt,Wait_type as WaitType,
wait_time_ms / 1000. AS WaitTimeSecond,
(wait_time_ms - signal_wait_time_ms)/1000. AS ResourcesWaitSecond,
signal_wait_time_ms/1000. AS SignalWaitSecond
FROM sys.dm_os_wait_stats
WHERE wait_type IN(SELECT wait_type FROM #eliminate_WS) Setelah data historis disimpan, kami membuka Power BI dan mengembangkan dasbor statistik tunggu kami.
Klik Dapatkan Data dan pilih SQL Server :
Atur pengaturan koneksi dan kemudian tulis kueri ke pernyataan SQL (opsional, memerlukan database) . Klik Oke .
Klik Impor dari Marketplace
Temukan Sparkline oleh OKViz komponen visual dan Tambah Power BI
Tambahkan Sparkline ke panel desain Power BI dan seret dan lepas kolom kumpulan data seperti pada gambar di bawah ini:
Tambahkan dua komponen tabel untuk difilter:SQLStartTime dan Tipe Tunggu . Akhirnya, dasbor harus seperti ini:
Cara Mendiagnosis Masalah Resource Wait:
Pada bagian ini, kami akan menyebutkan metodologi dan disiplin dalam mendiagnosis masalah statistik tunggu. Khususnya, kita harus mencari tahu satu hal tentang statistik tunggu:ini hanya mendefinisikan struktur utama masalah tetapi tidak pernah memberikan detail. Untuk alasan ini, kita perlu meneliti detail dan alasan tunggu. Oleh karena itu, "statistik tunggu" memungkinkan kami mengubah penelitian kami ke arah ini. Setelah itu, kita harus menggunakan alat lain (PerfMon, Acara yang Diperpanjang, alat pemantauan pihak ketiga, dll.) dan DMV lain untuk menentukan masalah yang sebenarnya.
Dengan asumsi bahwa, kami mengamati ASYNC_NETWORK_IO di SQL Server, penantian sumber daya ini terkait dengan koneksi jaringan yang lambat dari sisi klien ke sisi server. Tetapi informasi ini tidak membantu memecahkan masalah penyebab utama masalah karena kami mungkin memiliki beberapa konfigurasi jaringan antara sisi server dan klien. Untuk contoh ini kita perlu melihat:
• Kueri kumpulan hasil besar
• Konfigurasi Kartu Antarmuka Jaringan
• Pengaturan lingkungan jaringan antara sisi server ke sisi klien.
• Periksa bandwidth adaptor jaringan.
Seperti yang Anda lihat dalam contoh, kita perlu menyelesaikan beberapa tugas untuk mendefinisikan masalah yang sebenarnya. Statistik tunggu tidak menunjukkan target masalah.
Kesimpulan
Dalam posting ini, kami berbicara tentang konsep utama tampilan manajemen dinamis sys.dm_os_wait_stats. Pada saat yang sama, kami membahas kesederhanaan penggunaan dan poin penting yang perlu diperhatikan.
Alat yang berguna:
dbForge Monitor – add-in untuk Microsoft SQL Server Management Studio yang memungkinkan Anda melacak dan menganalisis kinerja SQL Server.
