Analisis MS SQL Server untuk Mereka yang Melihatnya untuk Pertama Kali

Masalah Apa yang Akan Kami Pertimbangkan?

Jika server memberi tahu “tidak ada lagi ruang di drive E” – tidak diperlukan analisis mendalam. Kami tidak akan mempertimbangkan kesalahan, yang solusinya terlihat jelas dari teks pesan dan untuk itu Google segera memberikan tautan ke MSDN dengan solusinya.

Mari kita periksa masalah yang tidak jelas bagi Google, seperti, misalnya, penurunan kinerja yang tiba-tiba atau tidak adanya koneksi. Pertimbangkan alat utama untuk penyesuaian dan analisis. Mari kita lihat di mana log dan informasi berguna lainnya berada. Bahkan, saya akan mencoba mengumpulkan dalam satu artikel semua informasi yang diperlukan untuk memulai dengan cepat.

Pertama-tama

Kita akan mulai dengan pertanyaan yang paling sering dan membahasnya secara terpisah.

Jika database Anda tiba-tiba, tanpa alasan yang jelas, mulai bekerja dengan lambat, tetapi Anda tidak mengubah apa pun – pertama-tama, perbarui statistik dan bangun kembali indeks.

Di Internet, ada banyak metode seperti ini, contoh skrip disediakan. Saya akan berasumsi bahwa semua metode itu untuk para profesional. Baiklah, saya akan menjelaskan cara paling sederhana:Anda hanya perlu mouse untuk mengimplementasikannya.

Singkatan

SSMS adalah aplikasi dari Microsoft SQL Server Management Studio. Mulai dari versi 2016, tersedia gratis di situs web MS sebagai aplikasi mandiri. docs.microsoft.com/en-us/sql/ssms/download-sql-server-management-studio-ssms

Profiler adalah aplikasi “SQL Server Profiler” yang diinstal dengan SSMS.
Monitor Kinerja adalah snap-in panel kontrol yang memungkinkan Anda memantau penghitung kinerja, mencatat, dan melihat riwayat pengukuran.

Pembaruan statistik menggunakan “paket layanan”:

jalankan SSMS;
menghubungkan ke server yang diperlukan;
perluas pohon di Object Inspector:Management\Maintenance Plans (Service Plans);
klik kanan node dan pilih “Maintenance Plan Wizard”;
di wizard, tandai tugas yang diperlukan:bangun kembali indeks dan perbarui statistik

Anda dapat menandai kedua tugas sekaligus atau membuat dua rencana pemeliharaan dengan masing-masing satu tugas (lihat “catatan penting” di bawah);
selanjutnya, kami memeriksa DB yang diperlukan (atau beberapa database). Kami melakukan ini untuk setiap tugas (jika dua tugas dipilih, akan ada dua dialog dengan pilihan database);
Selanjutnya, Selanjutnya, Selesai.

Setelah tindakan ini, "rencana pemeliharaan" akan dibuat (tidak dijalankan). Anda dapat menjalankannya secara manual dengan mengklik kanan dan memilih "Execute". Atau, Anda mengonfigurasi peluncuran melalui Agen SQL.

Catatan penting:

Memperbarui statistik adalah operasi tanpa pemblokiran. Anda dapat melakukannya dalam mode kerja.
Pembangunan kembali indeks adalah operasi pemblokiran. Anda hanya dapat menjalankannya di luar jam kerja. Ada pengecualian — edisi Enterprise dari server memungkinkan eksekusi "pembangunan kembali online". Opsi ini dapat diaktifkan di pengaturan tugas. Harap perhatikan bahwa ada tanda centang di semua edisi, tetapi hanya berfungsi di Perusahaan.
Tentu saja, tugas-tugas ini harus dilakukan secara teratur. Saya menyarankan cara mudah untuk menentukan seberapa sering Anda melakukan ini:

– Dengan masalah pertama, jalankan rencana pemeliharaan;

– Jika terbantu, tunggu sampai masalah muncul kembali (biasanya sampai penutupan bulanan berikutnya/perhitungan gaji/dll transaksi massal);

– Periode yang dihasilkan dari operasi normal akan menjadi titik referensi Anda;

– Misalnya, konfigurasikan eksekusi rencana pemeliharaan dua kali lebih sering.

Server Lambat – Apa Yang Harus Anda Lakukan?

Sumber daya yang digunakan oleh server

Seperti program lainnya, server membutuhkan waktu prosesor, data pada disk, jumlah RAM, dan bandwidth jaringan.

Pengelola Tugas akan membantu Anda menilai kekurangan sumber daya yang diberikan pada perkiraan pertama, tidak peduli seberapa buruk kedengarannya.

CPU Muat

Bahkan anak sekolah dapat memeriksa pemanfaatannya di Manajer. Kami hanya perlu memastikan bahwa jika prosesor dimuat, maka itu adalah proses sqlserver.exe.

Jika ini kasus Anda, Anda perlu membuka analisis aktivitas pengguna untuk memahami apa sebenarnya yang menyebabkan pemuatan (lihat di bawah).

Cakram Loa d

Banyak orang hanya melihat beban CPU tetapi lupa bahwa DBMS adalah penyimpan data. Volume data bertambah, kinerja prosesor meningkat sementara kecepatan HDD hampir sama. Dengan SSD situasinya lebih baik, tetapi menyimpan terabyte di dalamnya mahal.

Ternyata saya sering menghadapi situasi di mana sistem disk menjadi penghambat, bukan CPU.

Untuk disk, metrik berikut penting:

rata-rata panjang antrian (operasi I/O yang luar biasa, jumlah);
kecepatan baca-tulis (dalam Mb/s).

Versi server dari Pengelola Tugas, sebagai aturan (tergantung pada versi sistem), menunjukkan keduanya. Jika tidak, jalankan snap-in Performance Monitor (monitor sistem). Kami tertarik dengan penghitung berikut:

Disk fisik (logis)/Waktu baca (tulis) rata-rata
Disk fisik (logis)/Panjang antrean disk rata-rata
Kecepatan disk/disk fisik (logis)

Untuk detail lebih lanjut, Anda dapat membaca manual pabrikan, misalnya, di sini:social.technet.microsoft.com/wiki/contents/articles/3214.monitoring-disk-usage.aspx.

Singkatnya:

Antrian tidak boleh melebihi 1. Semburan pendek diperbolehkan jika cepat mereda. Semburan dapat berbeda tergantung pada sistem Anda. Untuk mirror RAID sederhana dari dua HDD – antrian lebih dari 10-20 adalah masalah. Untuk perpustakaan keren dengan super caching, saya melihat ledakan hingga 600-800 yang langsung diselesaikan tanpa menyebabkan penundaan.
Nilai tukar normal juga tergantung pada jenis sistem disk. HDD (desktop) biasa mentransmisikan pada 50-100 MB/s. Pustaka disk yang bagus – dengan kecepatan 500 MB/dtk dan lebih banyak lagi. Untuk operasi acak kecil, kecepatannya kurang. Ini mungkin titik referensi Anda.
Parameter ini harus dipertimbangkan secara keseluruhan. Jika perpustakaan Anda mentransmisikan 50MB/dtk dan antrian 50 operasi berbaris — jelas, ada yang salah dengan perangkat kerasnya. Jika antrian berbaris saat transmisi mendekati maksimum – kemungkinan besar, disk tidak dapat disalahkan – mereka tidak bisa berbuat lebih banyak – kita perlu mencari cara untuk mengurangi beban.
Pemuatan harus diperiksa secara terpisah pada disk (jika ada beberapa) dan dibandingkan dengan lokasi file server. Task Manager dapat menampilkan file yang paling aktif digunakan. Ini dapat digunakan untuk memastikan bahwa beban disebabkan oleh DBMS.

Apa yang dapat menyebabkan masalah sistem disk:

masalah dengan perangkat keras

cache hangus, performa turun drastis;
sistem disk digunakan oleh sesuatu yang lain;

Kekurangan RAM. bertukar. ching rusak, kinerja menurun (lihat bagian tentang RAM di bawah).
Beban pengguna meningkat. Penting untuk mengevaluasi pekerjaan pengguna (kueri bermasalah/fungsi baru/peningkatan jumlah pengguna/peningkatan jumlah data/dll).
Fragmentasi data database (lihat pembangunan kembali indeks di atas), fragmentasi file sistem.
Sistem disk telah mencapai kemampuan maksimalnya.

Dalam hal opsi terakhir – jangan membuang perangkat keras sekaligus. Terkadang, Anda bisa mendapatkan sedikit lebih banyak dari sistem jika Anda mendekati masalah dengan bijak. Periksa lokasi file sistem untuk memenuhi persyaratan yang disarankan:

Jangan mencampur file OS dengan file data database. Simpan pada media fisik yang berbeda sehingga sistem tidak bersaing dengan DBMS untuk I/O.
Basis data terdiri dari dua jenis file:data (*.mdf, *.ndf) dan log (*.ldf).
File data, sebagai suatu peraturan, sebagian besar digunakan untuk membaca. Log berfungsi untuk menulis (di mana penulisannya berurutan). Oleh karena itu, disarankan untuk menyimpan log dan data pada media fisik yang berbeda sehingga pencatatan tidak mengganggu pembacaan data (sebagai aturan, operasi tulis lebih diutamakan daripada pembacaan).
MS SQL dapat menggunakan "tabel sementara" untuk pemrosesan kueri. Mereka disimpan dalam database sistem tempdb. Jika Anda memiliki beban tinggi pada file database ini, Anda dapat mencoba merendernya pada media yang terpisah secara fisik.

Meringkas masalah dengan lokasi file, gunakan prinsip "membagi dan menaklukkan". Evaluasi file mana yang diakses dan coba mendistribusikannya ke media yang berbeda. Juga, gunakan fitur sistem RAID. Misalnya, RAID-5 membaca lebih cepat daripada menulis – yang bagus untuk file data.

Mari kita jelajahi cara mengambil informasi tentang kinerja pengguna:siapa yang membuat apa, dan berapa banyak sumber daya yang dikonsumsi

Saya membagi tugas mengaudit aktivitas pengguna ke dalam grup berikut:

Tugas menganalisis permintaan tertentu.
Tugas menganalisis beban dari aplikasi dalam kondisi tertentu (misalnya, saat pengguna mengklik tombol di aplikasi pihak ketiga yang kompatibel dengan database).
Tugas menganalisis situasi saat ini.

Mari kita pertimbangkan masing-masing secara mendetail.

Peringatan

Analisis kinerja memerlukan pemahaman yang mendalam tentang struktur dan prinsip pengoperasian server database dan sistem operasi. Itu sebabnya membaca artikel ini saja tidak akan menjadikan Anda seorang profesional.

Kriteria dan penghitung yang dipertimbangkan dalam sistem nyata sangat bergantung satu sama lain. Misalnya, beban HDD yang tinggi sering kali disebabkan oleh kurangnya RAM. Bahkan jika Anda melakukan beberapa pengukuran, ini tidak cukup untuk menilai masalah secara wajar.

Tujuan dari artikel ini adalah untuk memperkenalkan hal-hal penting tentang contoh-contoh sederhana. Anda tidak harus mempertimbangkan rekomendasi saya sebagai panduan. Saya sarankan Anda menggunakannya sebagai tugas pelatihan yang dapat menjelaskan aliran pemikiran.

Saya harap Anda akan belajar bagaimana merasionalisasi kesimpulan Anda tentang kinerja server dalam angka.

Alih-alih mengatakan "server melambat", Anda akan memberikan nilai spesifik dari indikator tertentu.

Analisis P artikular R berkuda

Poin pertama cukup sederhana, mari kita bahas secara singkat. Kami akan mempertimbangkan beberapa masalah yang kurang jelas.

Selain hasil kueri, SSMS memungkinkan pengambilan informasi tambahan tentang eksekusi kueri:

Anda dapat memperoleh rencana kueri dengan mengklik tombol “Tampilkan Perkiraan Rencana Eksekusi” dan “Sertakan Rencana Eksekusi Aktual”. Perbedaan di antara mereka adalah bahwa rencana estimasi dibangun tanpa eksekusi kueri. Dengan demikian, informasi tentang jumlah baris yang diproses akan diperkirakan. Dalam rencana aktual, akan ada data perkiraan dan data aktual. Perbedaan yang kuat dari nilai-nilai ini menunjukkan bahwa statistik tidak relevan. Namun, analisis rencana adalah subjek untuk artikel lain – sejauh ini, kami tidak akan membahas lebih dalam.
Kita bisa mendapatkan pengukuran biaya prosesor dan operasi disk server. Untuk melakukan ini, perlu mengaktifkan opsi SET. Anda dapat melakukannya di kotak dialog 'Opsi kueri' seperti ini:

Atau dengan perintah SET langsung dalam kueri:

      SET STATISTICS IO ON
      SET STATISTICS TIME ON
      SELECT * FROM Production.Product p
      JOIN Production.ProductDocument pd ON p.ProductID = pd.ProductID
      JOIN Production.ProductProductPhoto ppp ON p.ProductID = ppp.ProductID

Hasilnya, kami akan mendapatkan data tentang waktu yang dihabiskan untuk kompilasi dan eksekusi, serta jumlah operasi disk.

Time of SQL Server parsing and compilation:
CPU time = 16 ms, elapsed time = 89 ms.
 
SQL Server performance time:
CPU time = 0 ms, time spent = 0 ms.
 
SQL Server performance time:
CPU time = 0 ms, time spent = 0 ms.
(32 row(s) affected)
The «ProductProductPhoto» table. The number of views is 32, logic reads – 96, physical reads 5, read-ahead reads 0, lob of logical reads 0, lob of physical reads 0, lob of read-ahead reads 0.
The ‘Product’ table. The number of views is 0, logic reads – 64, physical reads – 0, read-ahead reads – 0, lob of logical reads – 0, lob of physical reads – 0, lob of readahead reads – 0.
The «ProductDocument» table. The number of views is 1, logical reads – 3, physical reads – 1, read-ahead reads -, lob of logical reads – 0, lob of physical reads – 0, lob of readahead reads – 0.
Time of SQL activity:
CPU time = 15 ms, spent time = 35 ms.

Saya ingin menarik perhatian Anda pada waktu kompilasi, pembacaan logis 96, dan pembacaan fisik 5. Saat menjalankan kueri yang sama untuk kedua kalinya dan selanjutnya, pembacaan fisik mungkin berkurang, dan kompilasi ulang mungkin tidak diperlukan. Karena fakta ini, sering terjadi bahwa kueri dieksekusi lebih cepat selama waktu kedua dan berikutnya daripada untuk pertama kalinya. Alasannya, seperti yang Anda pahami, adalah dalam menyimpan data dan menyusun rencana kueri.

Tombol «Sertakan Statistik Klien» menampilkan informasi tentang pertukaran jaringan, jumlah operasi yang dijalankan dan total waktu eksekusi, termasuk biaya pertukaran jaringan dan pemrosesan oleh klien. Contoh menunjukkan bahwa dibutuhkan lebih banyak waktu untuk mengeksekusi kueri untuk pertama kalinya:

Di SSMS 2016, ada tombol «Sertakan Statistik Kueri Langsung». Ini menampilkan gambar seperti dalam kasus rencana kueri tetapi berisi digit non-acak dari baris yang diproses, yang berubah di layar saat menjalankan kueri. Gambarnya sangat jelas – panah yang berkedip dan angka yang berjalan, Anda dapat langsung melihat di mana waktu yang terbuang. Tombol ini juga berfungsi untuk SQL Server 2014 dan yang lebih baru.

Singkatnya:

Periksa biaya CPU menggunakan SET STATISTICS TIME ON.
Pengoperasian disk:AKTIFKAN STATISTIK IO. Jangan lupa bahwa pembacaan logika adalah operasi baca yang diselesaikan dalam cache disk tanpa mengakses sistem disk secara fisik. “Membaca fisik” membutuhkan lebih banyak waktu.
Evaluasi volume lalu lintas jaringan menggunakan «Sertakan Statistik Klien».
Analisis algoritme eksekusi kueri menurut rencana eksekusi menggunakan «Sertakan Rencana Eksekusi Aktual» dan «Sertakan Statistik Kueri Langsung».

Menganalisis Beban Aplikasi

Disini kita akan menggunakan SQL Server Profiler. Setelah meluncurkan dan menghubungkan ke server, perlu untuk memilih peristiwa log. Untuk melakukan ini, jalankan pembuatan profil dengan templat penelusuran standar. Di Umum tab di Gunakan template bidang, pilih Standar (default) dan klik Jalankan .

Cara yang lebih rumit adalah menambahkan/menjatuhkan filter atau acara ke/dari template yang dipilih. Opsi ini dapat ditemukan pada tab kedua dari menu dialog. Untuk melihat rangkaian lengkap acara yang memungkinkan dan kolom yang dapat dipilih, pilih Tampilkan Semua Acara dan Tampilkan Semua Kolom kotak centang.

Kami akan membutuhkan acara berikut:

Prosedur Tersimpan \ RPC:Selesai
TSQL \ SQL:BatchCompleted

Peristiwa ini memantau semua panggilan SQL eksternal ke server. Mereka muncul setelah selesainya pemrosesan kueri. Ada acara serupa yang melacak awal SQL Server:

Prosedur Tersimpan \ RPC:Memulai
TSQL \ SQL:BatchStarting

Namun, kami tidak memerlukan prosedur ini karena tidak berisi informasi tentang sumber daya server yang dihabiskan untuk eksekusi kueri. Jelas bahwa informasi tersebut hanya tersedia setelah selesainya proses eksekusi. Jadi, kolom dengan data pada CPU, Baca, Tulis di *Memulai acara akan kosong.

Acara berikut mungkin menarik bagi kami juga, namun sejauh ini kami tidak akan mengaktifkannya:

Prosedur Tersimpan \ SP:Starting (*Selesai) memantau panggilan internal ke prosedur tersimpan bukan dari klien, tetapi dalam permintaan saat ini atau prosedur lain.
Prosedur Tersimpan \ SP:StmtStarting (*Selesai) melacak awal setiap pernyataan dalam prosedur tersimpan. Jika ada siklus dalam prosedur, jumlah kejadian untuk perintah dalam siklus akan sama dengan jumlah iterasi dalam siklus.
TSQL \ SQL:StmtStarting (*Completed) memonitor awal setiap pernyataan dalam SQL-batch. Jika ada beberapa perintah dalam kueri Anda, masing-masing akan berisi satu peristiwa. Dengan demikian, ini berfungsi untuk perintah yang terletak di kueri.

Peristiwa ini nyaman untuk memantau proses eksekusi.

Oleh C kolom

Kolom mana yang harus dipilih jelas dari nama tombol. Kami akan membutuhkan yang berikut ini:

TextData, BinaryData berisi teks kueri.
CPU, Membaca, Menulis, Durasi menampilkan data konsumsi sumber daya.
StartTime, EndTime adalah waktu untuk memulai dan menyelesaikan proses eksekusi. Mereka nyaman untuk menyortir.

Tambahkan kolom lain berdasarkan preferensi Anda.

Filter Kolom… tombol membuka kotak dialog untuk mengonfigurasi filter acara. Jika Anda tertarik dengan aktivitas pengguna tertentu, Anda dapat mengatur filter berdasarkan nomor SID atau nama pengguna. Sayangnya, dalam kasus menghubungkan aplikasi melalui server aplikasi dengan tarikan koneksi, pemantauan pengguna tertentu menjadi lebih rumit.

Anda dapat menggunakan filter untuk pemilihan hanya kueri yang rumit (Durasi>X), kueri yang menyebabkan penulisan intensif (Tulis>Y), serta pemilihan konten kueri, dll.

Apa lagi yang kita butuhkan dari profiler? Tentu saja, rencana eksekusi!

Hal ini diperlukan untuk menambahkan acara «Performance \ Showplan XML Statistics Profile» ke tracing. Saat menjalankan kueri kami, kami akan mendapatkan gambar berikut:

Teks kueri:

Rencana eksekusi:

Dan Bukan Itu Saja

Dimungkinkan untuk menyimpan jejak ke file atau tabel database. Pengaturan pelacakan dapat disimpan sebagai template pribadi untuk dijalankan dengan cepat. Anda dapat menjalankan pelacakan tanpa profiler, cukup dengan menggunakan kode T-SQL, dan prosedur sp_trace_create, sp_trace_setevent, sp_trace_setstatus, sp_trace_getdata. Anda dapat menemukan contoh di sini. Pendekatan ini dapat berguna, misalnya, untuk secara otomatis mulai menyimpan jejak ke file pada jadwal. Anda dapat memiliki puncak licik di profiler untuk melihat cara menggunakan perintah ini. Anda dapat menjalankan dua jejak dan di salah satunya melacak apa yang terjadi ketika yang kedua dimulai. Pastikan tidak ada filter pada kolom “ApplicationName” pada profiler itu sendiri.

Daftar peristiwa yang dipantau oleh profiler sangat besar dan tidak terbatas pada menerima teks kueri. Ada acara yang melacak pemindaian penuh, kompilasi ulang, pertumbuhan otomatis, kebuntuan, dan banyak lagi.

Menganalisis Aktivitas Pengguna di Server

Ada situasi yang berbeda. Sebuah query dapat bertahan dalam 'eksekusi' untuk waktu yang lama dan tidak jelas apakah akan selesai atau tidak. Saya ingin menganalisis kueri bermasalah secara terpisah; namun, pertama-tama kita harus menentukan apa kuerinya. Tidak ada gunanya menangkapnya dengan profiler – kami telah melewatkan acara awal, dan tidak jelas berapa lama menunggu proses selesai.

Mari kita cari tahu

Anda mungkin pernah mendengar tentang 'Monitor Aktivitas'. Edisi yang lebih tinggi memiliki fungsionalitas yang sangat kaya. Bagaimana itu bisa membantu kita? Activity Monitor mencakup banyak fitur yang berguna dan menarik. Kami akan mendapatkan semua yang kami butuhkan dari tampilan dan fungsi sistem. Monitor itu sendiri berguna karena Anda dapat mengatur profiler di dalamnya dan melihat kueri apa yang dijalankannya.

Kami membutuhkan:

dm_exec_sessions memberikan informasi tentang sesi pengguna yang terhubung. Dalam artikel kami, bidang yang berguna adalah bidang yang mengidentifikasi pengguna (nama_login, waktu_login, nama_host, nama_program, ...) dan bidang dengan informasi tentang sumber daya yang dihabiskan (waktu_cpu, membaca, menulis, penggunaan_memori, ...)
dm_exec_requests memberikan informasi tentang kueri yang dieksekusi saat ini.
session_id adalah pengidentifikasi sesi untuk ditautkan ke tampilan sebelumnya.
start_time adalah waktu untuk menjalankan tampilan.
perintah adalah bidang yang berisi jenis perintah yang dieksekusi. Untuk pertanyaan pengguna, pilih/perbarui/hapus/
sql_handle, statement_start_offset, statement_end_offset memberikan informasi untuk mengambil teks kueri:handle, serta posisi awal dan akhir dalam teks kueri, yang berarti bagian yang sedang dieksekusi (untuk kasus ketika kueri Anda berisi beberapa perintah).
plan_handle adalah pegangan dari rencana yang dihasilkan.
blocking_session_id menunjukkan jumlah sesi yang menyebabkan pemblokiran jika ada blok yang mencegah eksekusi kueri
wait_type, wait_time, wait_resource adalah kolom dengan informasi tentang alasan dan durasi menunggu. Untuk beberapa jenis menunggu, misalnya, penguncian data, perlu untuk menunjukkan kode tambahan untuk sumber daya yang diblokir.
percent_complete adalah persentase penyelesaian. Sayangnya, ini hanya tersedia untuk perintah dengan kemajuan yang dapat diprediksi dengan jelas (misalnya, pencadangan atau pemulihan).
cpu_time, reads, writes, logical_reads, grant_query_memory adalah biaya sumber daya.
dm_exec_sql_text(sql_handle | plan_handle), sys.dm_exec_query_plan(plan_handle) adalah fungsi untuk mendapatkan teks dan rencana eksekusi. Di bawah ini, kami akan mempertimbangkan contoh penggunaannya.
dm_exec_query_stats adalah ringkasan statistik dari eksekusi kueri. Ini menampilkan kueri, jumlah eksekusi, dan volume sumber daya yang dihabiskan.

Catatan Penting

Daftar di atas hanyalah sebagian kecil. Daftar lengkap semua tampilan dan fungsi sistem dijelaskan dalam dokumentasi. Juga, ada gambar indah yang menunjukkan diagram hubungan antara objek utama.

Teks kueri, rencananya, dan statistik eksekusi adalah data yang disimpan dalam cache prosedur. Mereka tersedia selama eksekusi. Kemudian, ketersediaan tidak dijamin dan tergantung pada beban cache. Ya, cache dapat dibersihkan secara manual. Terkadang, direkomendasikan ketika rencana eksekusi 'terbalik'. Namun, ada banyak nuansa.

Bidang "perintah" tidak ada artinya untuk permintaan pengguna, karena kami bisa mendapatkan teks lengkapnya. Namun, sangat penting untuk memperoleh informasi tentang proses sistem. Sebagai aturan, mereka melakukan beberapa tugas internal dan tidak memiliki teks SQL. Untuk proses seperti itu, informasi tentang perintah adalah satu-satunya petunjuk dari jenis aktivitas.

Dalam komentar di artikel sebelumnya, ada pertanyaan tentang apa yang terlibat dalam server ketika seharusnya tidak berfungsi. Jawabannya mungkin dalam arti bidang ini. Dalam praktik saya, bidang "perintah" selalu memberikan sesuatu yang cukup dapat dimengerti untuk proses sistem aktif:autoshrink / autogrow / checkpoint / logwriter / dll.

Cara Menggunakannya

Kami akan pergi ke bagian praktis. Saya akan memberikan beberapa contoh penggunaannya. Kemungkinan server tidak terbatas – Anda dapat memikirkan contoh Anda sendiri.

Contoh 1. Proses apa yang menghabiskan CPU/baca/tulis/memori

Pertama, lihat sesi yang menghabiskan lebih banyak sumber daya, misalnya, CPU. Anda dapat menemukan informasi ini di sys.dm_exec_sessions. Namun, data pada CPU, termasuk membaca dan menulis, bersifat kumulatif. Artinya nomor tersebut berisi total untuk semua waktu koneksi. Jelas bahwa pengguna yang terhubung sebulan yang lalu dan tidak terputus akan memiliki nilai yang lebih tinggi. Ini tidak berarti bahwa mereka membebani sistem.

Kode dengan algoritme berikut dapat memecahkan masalah ini:

Pilih dan simpan di tabel sementara
Tunggu beberapa saat
Pilih untuk kedua kalinya
Bandingkan hasil ini. Perbedaannya akan menunjukkan biaya yang dikeluarkan pada langkah 2.
Untuk memudahkan, selisihnya dapat dibagi dengan durasi langkah 2 untuk mendapatkan rata-rata “biaya per detik”.

if object_id('tempdb..#tmp') is NULL
BEGIN
        SELECT * into #tmp from sys.dm_exec_sessions s
        PRINT 'wait for a second to collect statistics at the first run '
        -- we do not wait for the next launches, because we compare with the result of the previous launch
        WAITFOR DELAY '00:00:01';
END
if object_id('tempdb..#tmp1') is not null drop table #tmp1

declare @d datetime
declare @dd float
select @d = crdate from tempdb.dbo.sysobjects where id=object_id('tempdb..#tmp')

select * into #tmp1 from sys.dm_exec_sessions s
select @dd=datediff(ms,@d,getdate())
select @dd AS [time interval, ms]

SELECT TOP 30 s.session_id, s.host_name, db_name(s.database_id) as db, s.login_name,s.login_time,s.program_name,
       s.cpu_time-isnull(t.cpu_time,0) as cpu_Diff, convert(numeric(16,2),(s.cpu_time-isnull(t.cpu_time,0))/@dd*1000) as cpu_sec,
       s.reads+s.writes-isnull(t.reads,0)-isnull(t.writes,0) as totIO_Diff, convert(numeric(16,2),(s.reads+s.writes-isnull(t.reads,0)-isnull(t.writes,0))/@dd*1000) as totIO_sec,
       s.reads-isnull(t.reads,0) as reads_Diff, convert(numeric(16,2),(s.reads-isnull(t.reads,0))/@dd*1000) as reads_sec,
       s.writes-isnull(t.writes,0) as writes_Diff, convert(numeric(16,2),(s.writes-isnull(t.writes,0))/@dd*1000) as writes_sec,
       s.logical_reads-isnull(t.logical_reads,0) as logical_reads_Diff, convert(numeric(16,2),(s.logical_reads-isnull(t.logical_reads,0))/@dd*1000) as logical_reads_sec,
       s.memory_usage, s.memory_usage-isnull(t.memory_usage,0) as [mem_D],
      s.nt_user_name,s.nt_domain
from #tmp1 s
LEFT join #tmp t on s.session_id=t.session_id
order BY
cpu_Diff desc
--totIO_Diff desc
--logical_reads_Diff desc

drop table #tmp
GO
select * into #tmp from #tmp1
drop table #tmp1

Saya menggunakan dua tabel dalam kode:#tmp – untuk pilihan pertama, dan #tmp1 – untuk yang kedua. Selama menjalankan pertama, skrip membuat dan mengisi #tmp dan #tmp1 pada interval satu detik, dan kemudian melakukan tugas lainnya. Dengan menjalankan berikutnya, skrip menggunakan hasil eksekusi sebelumnya sebagai dasar untuk perbandingan. Dengan demikian, durasi langkah 2 akan sama dengan durasi Anda menunggu antara skrip berjalan.

Coba jalankan, bahkan di server produksi. Skrip hanya akan membuat 'tabel sementara' (tersedia dalam sesi saat ini dan dihapus saat dinonaktifkan) dan tidak memiliki utas.

Mereka yang tidak suka mengeksekusi query di MS SSMS dapat membungkusnya dalam aplikasi yang ditulis dalam bahasa pemrograman favorit mereka. Saya akan menunjukkan cara melakukannya di MS Excel tanpa satu baris kode pun.

Di menu Data, sambungkan ke server. Jika Anda diminta untuk memilih tabel, pilih salah satu secara acak. Klik Berikutnya dan Selesai hingga Anda melihat dialog Impor Data. Di jendela itu, Anda perlu mengklik Properties. Di Properti, perlu untuk mengganti jenis perintah dengan nilai SQL dan memasukkan kueri yang dimodifikasi di bidang teks Perintah.

Anda harus sedikit mengubah kueri:

Tambahkan «SET NOCOUNT ON»
Ganti tabel sementara dengan tabel variabel
Penundaan akan berlangsung dalam 1 detik. Kolom dengan nilai rata-rata tidak diperlukan

Kueri untuk Excel yang dimodifikasi

SET NOCOUNT ON;
declare @tmp table(session_id   smallint primary key,login_time datetime,host_name nvarchar(256),program_name nvarchar(256),login_name nvarchar(256),nt_user_name       nvarchar(256),cpu_time  int,memory_usage        int,reads       bigint,writes   bigint,logical_reads    bigint,database_id      smallint)

declare @d datetime;
select @d=GETDATE()

INSERT INTO @tmp(session_id,login_time,host_name,program_name,login_name,nt_user_name,cpu_time,memory_usage,reads,writes,logical_reads,database_id)
SELECT session_id,login_time,host_name,program_name,login_name,nt_user_name,cpu_time,memory_usage,reads,writes,logical_reads,database_id
from sys.dm_exec_sessions s;

WAITFOR DELAY '00:00:01';

declare @dd float;
select @dd=datediff(ms,@d,getdate());

SELECT 
        s.session_id, s.host_name, db_name(s.database_id) as db, s.login_name,s.login_time,s.program_name,
        s.cpu_time-isnull(t.cpu_time,0) as cpu_Diff,
        s.reads+s.writes-isnull(t.reads,0)-isnull(t.writes,0) as totIO_Diff,
        s.reads-isnull(t.reads,0) as reads_Diff,
        s.writes-isnull(t.writes,0) as writes_Diff,
        s.logical_reads-isnull(t.logical_reads,0) as logical_reads_Diff,
        s.memory_usage, s.memory_usage-isnull(t.memory_usage,0) as [mem_Diff],
        s.nt_user_name,s.nt_domain
from sys.dm_exec_sessions s
left join @tmp t on s.session_id=t.session_id

Hasil:

Saat data muncul di Excel, Anda bisa mengurutkannya, sesuai kebutuhan. Untuk memperbarui informasi, klik 'Segarkan'. Dalam pengaturan buku kerja, Anda dapat menempatkan "pembaruan otomatis" dalam jangka waktu tertentu dan "pembaruan di awal". Anda dapat menyimpan file dan menyebarkannya ke kolega Anda. Jadi, kami membuat alat yang nyaman dan sederhana.

Contoh 2. Untuk apa sesi menghabiskan sumber daya?

Sekarang, kita akan menentukan apa yang sebenarnya dilakukan oleh sesi masalah. Untuk melakukannya, gunakan sys.dm_exec_requests dan fungsi untuk menerima teks kueri dan rencana kueri.

Kueri dan rencana eksekusi menurut nomor sesi

DECLARE @sql_handle varbinary(64)
DECLARE @plan_handle varbinary(64)
DECLARE @sid INT
Declare @statement_start_offset int, @statement_end_offset INT, @session_id SMALLINT

-- for the information by a particular user – indicate a session number
SELECT @sid=182

-- receive state variables for further processing
IF @sid IS NOT NULL
SELECT @sql_handle=der.sql_handle, @plan_handle=der.plan_handle, @statement_start_offset=der.statement_start_offset, @statement_end_offset=der.statement_end_offset, @session_id = der.session_id
FROM sys.dm_exec_requests der WHERE [email protected]

-- print the text of the query being executed 
DECLARE @txt VARCHAR(max)
IF @sql_handle IS NOT NULL
SELECT @txt=[text] FROM sys.dm_exec_sql_text(@sql_handle)
PRINT @txt
-- output the plan of the batch/procedure being executed
IF @plan_handle IS NOT NULL
select * from sys.dm_exec_query_plan(@plan_handle)
-- and the plan of the query being executed within the batch/procedure
IF @plan_handle IS NOT NULL
SELECT dbid, objectid, number, encrypted, CAST(query_plan AS XML) AS planxml
from sys.dm_exec_text_query_plan(@plan_handle, @statement_start_offset, @statement_end_offset)

Masukkan nomor sesi ke dalam kueri dan jalankan. After execution, there will be plans on the Results tab (the first one is for the whole query, and the second one is for the current step if there are several steps in the query) and the query text on the Messages tab. To view the plan, you need to click the text that looks like the URL in the row. The plan will be opened in a separate tab. Sometimes, it happens that the plan is opened not in a graphical form, but in the form of XML-text. This may happen because the MS SSMS version is lower than the server. Delete the “Version” and “Build” from the first row and then save the result XML to a file with the .sqlplan extension. After that, open it separately. If this does not help, I remind you that the 2016 studio is officially available for free on the MS website.

It is obvious that the result plan will be an estimated one, as the query is being executed. Still, it is possible to receive some execution statistics. To do this, use the sys.dm_exec_query_stats view with the filter by our handles.

Add this information at the end of the previous query

-- plan statistics 
IF @sql_handle IS NOT NULL
SELECT * FROM sys.dm_exec_query_stats QS WHERE [email protected]_handle

As a result, we will get the information about the steps of the executed query:how many times they were executed and what resources were spent. This information is added to the statistics only after the execution process is completed. The statistics are not tied to the user but are maintained within the whole server. If different users execute the same query, the statistics will be total for all users.

Example 3. Can I see all of them?

Let’s combine the system views we considered with the functions in one query. It can be useful for evaluating the whole situation.

-- receive a list of all current queries
SELECT LEFT((SELECT [text] FROM sys.dm_exec_sql_text(der.sql_handle)),500) AS txt
--,(select top 1 1 from sys.dm_exec_query_profiles where session_id=der.session_id) as HasLiveStat
,der.blocking_session_id as blocker, DB_NAME(der.database_id) AS База, s.login_name, *
from sys.dm_exec_requests der
left join sys.dm_exec_sessions s ON s.session_id = der.session_id
WHERE der.session_id<>@@SPID
-- AND der.session_id>50

The query outputs a list of active sessions and texts of their queries. For system processes, usually, there is no query; however, the command field is filled up. You can see the information about blocks and waits, and mix this query with example 1 in order to sort by the load. Still, be careful, query texts may be large. Their massive selection can be resource-intensive and lead to a huge traffic increase. In the example, I limited the result query to the first 500 characters but did not execute the plan.

Conclusion

It would be great to get Live Query Statistics for an arbitrary session. According to the manufacturer, now, monitoring statistics requires many resources and therefore, it is disabled by default. Its enabling is not a problem, but additional manipulations complicate the process and reduce the practical benefit.

In this article, we analyzed user activity in the following ways:using possibilities MS SSMS, profiler, direct calls to system views. All these methods allow estimating costs on executing a query and getting the execution plan. Each method is suitable for a particular situation. Thus, the best solution is to combine them.