Microsoft tidak terbiasa mencela hal-hal akhir-akhir ini, tetapi ketika mereka melakukannya, itu karena suatu alasan – dan tentu saja bukan karena mereka ingin membuat hidup Anda lebih sulit. Sebaliknya, hampir selalu karena mereka telah mengembangkan cara yang lebih baik dan lebih modern untuk memecahkan masalah yang sama.
Tapi kebiasaan sulit dihilangkan; tanya saya bagaimana saya tahu. Terlalu sering, saya melihat orang-orang berpegang teguh pada cara yang lebih tua untuk menyelesaikan beberapa tugas, meskipun ada cara yang lebih baik.
Saya ingin membagikan beberapa contoh terbaru yang membantu mengilustrasikan bagaimana penggunaan fitur SQL Server yang sudah usang terus mengganggu kita. Di bagian pertama ini, saya ingin berbicara tentang…
proses sistem
Tabel sistem sys.sysprocesses digantikan jauh di SQL Server 2005 oleh satu set tampilan manajemen dinamis (DMV), terutama sys.dm_exec_requests , sys.dm_exec_sessions , dan sys.dm_exec_connections . Dokumentasi resmi untuk sys.sysprocesses memperingatkan:
Contoh terbaru
Baru-baru ini salah satu tim kami sedang menyelidiki masalah latensi pembaca log. Kami sangat memperhatikan latensi di sini, bersama dengan transaksi yang berjalan lama, karena dampak hilir terhadap teknologi yang menggunakan pembaca log – seperti Grup Ketersediaan dan replikasi transaksional. Peringatan pertama kami biasanya terlihat di dasbor yang memplot latensi pembaca log terhadap durasi transaksi (saya akan menjelaskan titik waktu yang saya beri label t0 dan t1 sebentar lagi):
Mereka menentukan, katakanlah pada waktu t0 , bahwa sesi tertentu memiliki transaksi terbuka yang memblokir proses pembaca log. Mereka pertama-tama memeriksa output DBCC INPUTBUFFER , untuk mencoba menentukan apa yang terakhir dilakukan sesi ini, tetapi hasilnya hanya menunjukkan bahwa mereka juga mengeluarkan kumpulan lain selama transaksi mereka:
event_type parameters event_info -------------- ---------- --------------- Language Event 0 SET ROWCOUNT 0;
Perhatikan bahwa DBCC INPUTBUFFER juga memiliki pengganti yang lebih mumpuni dalam versi modern:sys.dm_exec_input_buffer . Dan meskipun tidak memiliki peringatan penghentian eksplisit, dokumentasi resmi untuk DBCC perintah memiliki dorongan lembut ini:
Setelah tidak mendapatkan apa-apa dari buffer input, mereka menanyakan sys.sysprocesses :
SELECT spid, [status], open_tran, waittime, [cpu], physical_io, memusage, last_batch FROM sys.sysprocesses WHERE spid = 107;
Hasilnya juga tidak berguna, setidaknya dalam hal menentukan apa yang telah dilakukan sesi untuk menjaga transaksi mereka tetap terbuka dan mengganggu pembaca log:
Saya menyoroti physical_io kolom karena nilai ini memicu diskusi tentang apakah mereka ingin mengambil risiko membunuh sesi tidur atau tidak. Pemikirannya adalah, jika semua I/O fisik tersebut ditulis, menghentikan transaksi dapat mengakibatkan rollback yang panjang dan mengganggu – berpotensi membuat masalah menjadi lebih buruk. Saya tidak akan menyebutkan waktu sebenarnya, tetapi anggap saja ini berubah menjadi percakapan yang berkepanjangan, dan meninggalkan sistem dalam keadaan ini dari waktu t0 ke waktu t1 pada grafik di atas.
Mengapa ini menjadi masalah
Masalah dalam kasus khusus ini adalah bahwa mereka menghabiskan waktu untuk merenungkan keputusan berdasarkan informasi yang tidak lengkap. Apakah I/O itu membaca atau menulis? Jika pengguna memiliki transaksi terbuka dan hanya membaca banyak data, dampak pembatalan transaksi itu jauh lebih kecil daripada jika mereka berubah banyak datanya. Jadi, alih-alih sys.sysprocesses , mari kita lihat apa DMV yang lebih modern, sys.dm_exec_sessions , dapat menunjukkan kepada kami tentang sesi ini:
SELECT session_id, [status], open_transaction_count, cpu_time, [reads], writes, logical_reads, last_request_start_time, last_request_end_time FROM sys.dm_exec_sessions WHERE session_id = 107;
Hasil:
Di sini kita melihat bahwa sys.dm_exec_sessions memecah I/O fisik secara terpisah menjadi membaca dan menulis. Ini memungkinkan kami membuat keputusan yang jauh lebih tepat, jauh lebih cepat daripada t1 - t0 , tentang potensi dampak rollback. Jika I/O semua menulis, dan tergantung pada seberapa tinggi angkanya, kami mungkin sedikit lebih ragu dan mungkin menghabiskan waktu untuk mencoba menemukan pengguna (sehingga kami dapat memukul buku-buku jari mereka atau bertanya kepada mereka mengapa mereka memiliki transaksi terbuka ). Jika kita tahu itu sebagian besar dibaca, kita dapat condong ke arah mematikan sesi dan memaksa transaksi untuk mundur.
Oke, sys.sysprocesses memiliki dbid dan waittime . Tapi dbid tidak dapat diandalkan dan sedikit berguna, terutama untuk kueri lintas basis data; ada banyak info yang lebih baik di sys.dm_tran_locks . Info tunggu (waktu dan jenis tunggu terakhir) dapat ditemukan di sys.dm_exec_requests , tetapi info lebih detail ditawarkan di sys.dm_exec_session_wait_stats (ditambahkan di SQL Server 2016). Alasan yang sering saya dengar adalah sys.dm_exec_sessions tidak ada open_tran , tapi open_transaction_count telah ditambahkan kembali di SQL Server 2012. Jadi hanya ada sedikit alasan untuk berpikir tentang menggunakan sys.sysprocesses hari ini.
Jika Anda ingin mengetahui seberapa sering sys.sysprocesses telah direferensikan sejak SQL Server dimulai ulang terakhir, Anda dapat menjalankan kueri ini terhadap penghitung kinerja DMV:
SELECT instance_name, cntr_value
FROM sys.dm_os_performance_counters
WHERE [object_name] LIKE N'%:Deprecated Features%'
AND instance_name = N'sysprocesses'
ORDER BY cntr_value DESC;
Jika Anda benar-benar ingin menghindari tidur malam ini, atau Anda hanya ingin terus-menerus menambahkan hal-hal yang Anda khawatirkan ke dalam daftar cucian, hapus predikat terhadap instance_name . Ini akan memberi Anda gambaran menakutkan dan tingkat tinggi tentang berapa banyak hal yang dijalankan oleh instance Anda yang pada akhirnya perlu Anda ubah.
Sementara itu, unduh sp_WhoIsActive , prosedur tersimpan Adam Machanic yang sangat berguna untuk memantau dan memecahkan masalah proses SQL Server secara real time. Kami telah menerapkan prosedur tersimpan ini ke setiap instans di lingkungan kami, dan Anda juga harus melakukannya, terlepas dari alat pemantauan canggih lainnya yang mungkin juga Anda gunakan.
Lain kali
Di Bagian 2, saya akan berbicara sedikit tentang SQL Server Profiler, sebuah aplikasi yang lebih banyak digunakan orang karena keakraban daripada apa pun – tanpa menyadari betapa berbahayanya itu.
