Dasar-dasar sys.dm_exec

Pemantauan kinerja dan pemecahan masalah di SQL Server adalah topik yang luas. Di SQL Server 2005, tampilan manajemen dinamis, juga dikenal sebagai DMV, telah diperkenalkan dan menjadi alat bantu penting untuk mendiagnosis masalah kinerja SQL Server. Pada saat yang sama, kita dapat menggunakan tampilan manajemen dinamis untuk Azure SQL Database. Beberapa dari mereka dapat berbeda dari database SQL Server di tempat tetapi logika kerjanya masih sama. Microsoft memiliki dokumentasi yang sangat baik tentang tampilan manajemen dinamis. Satu-satunya hal, Anda perlu berhati-hati tentang versi dan validasi produk dari tampilan manajemen dinamis. Seperti sys.dm_exec_request tersedia untuk SQL Server 2008 dan versi yang lebih baru dan untuk database Azure SQL tetapi sys.dm_db_wait_stats hanya valid untuk database Azure SQL.

Dalam posting ini, kita akan berbicara tentang dasar-dasar sys.dm_exec_request. sys.dm_exec_requests adalah tampilan manajemen dinamis yang hanya mengembalikan permintaan yang sedang dieksekusi. Ini berarti bahwa ketika Anda menjalankan kueri sys.dm_exec_requests, permintaan tersebut memotret permintaan yang sedang berjalan pada waktu itu dan tidak menyertakan data historis apa pun. Oleh karena itu, tampilan ini sangat berguna untuk memantau permintaan waktu nyata. Dengan kata lain, ini memberikan jawaban untuk “apa yang terjadi di server saya barusan?” Pandangan ini mencakup banyak detail tetapi kita akan membahas yang paling penting.

id_sesi :Nilai ini menentukan nomor identifikasi sesi. Di SQL Server, ID sesi yang sama dengan atau kurang dari 50 didedikasikan untuk proses latar belakang.

waktu_mulai :Nilai ini menentukan tanggal dan waktu mulai permintaan.

status :Nilai ini mendefinisikan status permintaan. Status yang tersedia adalah:

latar belakang
berlari
dapat dijalankan
tidur
ditangguhkan

SELECT DISTINCT status
FROM sys.dm_exec_requests
WHERE session_id <>@@SPID

latar belakang :Jenis status ini mendefinisikan proses latar belakang. Beberapa di antaranya adalah LAZY WRITER, CHECKPOINT, dan LOG WRITER.

select session_id, command, os_thread_id from sys.dm_exec_requests as r
 join sys.dm_os_workers as w on r.task_address = w.task_address
 join sys.dm_os_threads as t on t.thread_address = w.thread_address
 where session_id <= 50
 order by session_id

berlari :Jenis status ini mendefinisikan bahwa permintaan sedang diproses oleh CPU.

 select * from sys.dm_exec_requests where status='running'
 and session_id <>@@SPID

dapat dijalankan :Jenis status ini secara sederhana dapat didefinisikan sebagai permintaan yang menunggu di antrian CPU untuk dijalankan. Jika Anda mendeteksi banyak proses yang dapat dijalankan di sys.dm_exec_requests, itu bisa menjadi gejala tekanan CPU. Metrik ini tidak cukup untuk mendiagnosis masalah kinerja CPU ini. Karena alasan ini, kami perlu mendukung kasus ini dengan lebih banyak bukti. Ini penting bagi kami untuk membuktikan teori kami. Tampilan manajemen dinamis sys.dm_os_wait_stats menyertakan kolom yang merupakan signal_wait_time_ms. Nilai kolom ini dapat menjadi bantuan untuk menentukan masalah CPU. Kueri berikut menunjukkan kepada kita persentase Signalwait. Jika metrik ini memiliki nilai tinggi, kemungkinan besar Anda menghadapi masalah kinerja CPU. Anda dapat memperdalam ulasan Anda dengan cara ini.

---https://sqlserverperformance.wordpress.com/page/146/
---Glenn Berry's SQL Server Performance 

SELECT signal_wait_time_ms=SUM(signal_wait_time_ms)
              ,'%signal (cpu) waits' = CAST(100.0 * SUM(signal_wait_time_ms) / SUM (wait_time_ms) AS NUMERIC(20,2))
              ,resource_wait_time_ms=SUM(wait_time_ms - signal_wait_time_ms)
              ,'%resource waits'= CAST(100.0 * SUM(wait_time_ms - signal_wait_time_ms) / SUM (wait_time_ms) AS NUMERIC(20,2))
FROM sys.dm_os_wait_stats;

ditangguhkan :Jenis status ini mendefinisikan proses menunggu beberapa sumber daya. Ini bisa berupa I/O, LOCK, dan LATCH dll. Seperti disebutkan di atas, kita dapat menggunakan sys.dm_os_wait_stats tampilan manajemen dinamis untuk mendeteksi wait_time_ms.

tidur :Artinya permintaan terhubung ke SQL Server tetapi saat ini tidak menjalankan perintah apa pun.

perintah :Kolom ini mendefinisikan jenis perintah yang sedang dieksekusi. Pada saat yang sama, kita dapat menemukan informasi tambahan untuk perintah tertentu yang merupakan rasio penyelesaian. Menurut buku online, ini adalah;

ALTER INDEX REORGANIZE

Opsi AUTO_SHRINK dengan ALTER DATABASE

CADANGAN DATABASE

DBCC CHECKDB

DBCC CHECKFILEGROUP

DBCC CHECKTABLE

DBCC INDEXDEFRAG

DBCC SHRINKDATABASE

DBCC SHRINKFILE

PEMULIHAN

KEMBALIKAN DATABASE

KEMBALI

ENKRIPSI TDE

Demo :

Hubungkan database master dan mulai pencadangan untuk database apa pun.
```
BACKUP DATABASE WideWorldImporters TO DISK ='NUL'
```
Kiat :Saat Anda mengambil cadangan basis data ke perangkat "NUL", SQL Server tidak menulis file cadangan di mana pun dan Anda menghindari penghapusan file cadangan uji. Tetapi jangan gunakan perintah ini di lingkungan produksi Anda. Ini dapat menyebabkan putusnya rantai LSN.

Jalankan kueri berikut:

SELECT command,percent_complete ,*
FROM sys.dm_exec_requests
WHERE session_id <>@@SPID
and session_id>50 and command='BACKUP DATABASE'

sql_handle :Nilai ini mendefinisikan pernyataan SQL dari permintaan. Tetapi nilai ini dalam format bitmap. Untuk alasan ini, kita perlu menggunakan fungsi nilai tabel sys.dm_exec_sql_text untuk mengubah nilai menjadi teks yang bermakna.

select session_id ,command , sqltxt.text ,database_id
from sys.dm_exec_requests req
CROSS APPLY sys.dm_exec_sql_text(req.sql_handle) as sqltxt
where session_id<>@@SPID AND session_id>50

database_id :Nilai ini menentukan database mana yang membuat permintaan. Kita dapat menggabungkan bidang ini dengan sys.databases untuk mendapatkan nama database.

select session_id ,command , sqltxt.text ,db.name
from sys.dm_exec_requests req
CROSS APPLY sys.dm_exec_sql_text(req.sql_handle) as sqltxt
inner join sys.databases db on db.database_id = req.database_id
where session_id<>@@SPID AND session_id>50

tipe_tunggu :Nilai ini mendefinisikan tipe menunggu permintaan saat ini. Jika durasi eksekusi kueri lebih lama dari yang diharapkan, Anda dapat memeriksa dan menentukan jenis kueri tunggu.

tingkat_isolasi_transaksi :Nilai ini menentukan tingkat transaksi dari kueri yang dikirimkan:

0=Tidak ditentukan

1=BacaTidak Dikomit

2=BacaDikomit

3=Dapat diulang

4=Serializable

5=Snapshot

select session_id ,command , sqltxt.text ,db.name,req.status,wait_type ,transaction_isolation_level,
CASE transaction_isolation_level
WHEN 0 THEN 'Unspecified'
WHEN 1 THEN 'ReadUncomitted'
WHEN 2 THEN 'ReadCommitted'
WHEN 3 THEN 'Repeatable'
WHEN 4 THEN 'Serializable'
WHEN 5 THEN 'Snapshot'
END
AS isolation_level_name
from sys.dm_exec_requests req
CROSS APPLY sys.dm_exec_sql_text(req.sql_handle) as sqltxt
inner join sys.databases db on db.database_id = req.database_id
where session_id<>@@SPID AND session_id>50

blocking_session_id :Ini adalah id sesi yang memblokir permintaan. Jika kolom ini NULL, permintaan belum memblokir sesi apa pun.

Demo :

Buka SQL Server Management Studio dan jalankan kueri berikut.

DROP TABLE IF EXISTS TestPerfomon
GO
CREATE TABLE TestPerfomon
(ID INT ,
Nm VARCHAR(100))

INSERT INTO TestPerfomon
VALUES(1,1)
GO
BEGIN TRAN
UPDATE TestPerfomon SET Nm='2'
WHERE ID=1

SELECT @@SPID AS blocking_session_id

Buka jendela kueri baru dan jalankan kueri berikut.

SET TRANSACTION ISOLATION LEVEL Serializable
BEGIN TRAN
UPDATE TestPerfomon SET Nm='3'
WHERE ID=1

Buka jendela kueri baru lainnya dan jalankan kueri DMV ini.

select session_id ,command , sqltxt.text ,db.name,req.status,wait_type ,transaction_isolation_level,
CASE transaction_isolation_level
WHEN 0 THEN 'Unspecified'
WHEN 1 THEN 'ReadUncomitted'
WHEN 2 THEN 'ReadCommitted'
WHEN 3 THEN 'Repeatable'
WHEN 4 THEN 'Serializable'
WHEN 5 THEN 'Snapshot'
END
AS isolation_level_name ,
blocking_session_id
from sys.dm_exec_requests req
CROSS APPLY sys.dm_exec_sql_text(req.sql_handle) as sqltxt
inner join sys.databases db on db.database_id = req.database_id
where session_id<>@@SPID AND session_id>50

Dengan demonstrasi ini, kami menemukan alasan mengapa kueri kedua diblokir dan sesi mana yang memblokir permintaan tersebut. Saat menjalankan sp_BlitzWho 65, Anda dapat mengetahui detail pemblokiran dan detail sesi yang diblokir.

sp_BlitzWho 65

Dalam demonstrasi ini, kami mendapatkan detail sesi pemblokiran dan pemblokiran dan pada saat yang sama, kami mendapatkan detail tentang sesi ini. Ini adalah demonstrasi yang sangat mendasar tetapi menunjukkan bagaimana masalah tersebut dapat diselesaikan.

Dalam posting ini, kami berbicara tentang sys.sys.dm_exec_requests. Tampilan manajemen dinamis ini memberi kami fleksibilitas untuk mendapatkan snapshot selama anak tangga permintaan saat ini. Selain itu, data detail ini dapat membantu atau memandu kami melalui proses menemukan masalah.

Referensi

sys.dm_exec_requests (Transact-SQL)
Memantau Azure SQL Database menggunakan tampilan manajemen dinamis
sys.dm_db_wait_stats (Database SQL Azure)

Alat yang berguna:

dbForge Monitor – add-in untuk Microsoft SQL Server Management Studio yang memungkinkan Anda melacak dan menganalisis kinerja SQL Server.

Dasar-dasar sys.dm_exec_requests

Alat yang berguna: