Dalam proses pemantauan kinerja atau pemecahan masalah masalah seperti kelambatan sistem, mungkin perlu untuk menemukan atau menangkap kueri yang memiliki durasi tinggi, CPU tinggi, atau menghasilkan I/O yang signifikan selama eksekusi. Anda dapat menggunakan DMV atau Penyimpanan Kueri untuk mendapatkan informasi tentang kinerja kueri, tetapi informasi di kedua sumber merupakan kumpulan. DMV mewakili rata-rata CPU, I/O, durasi, dll. untuk kueri hanya selama kueri tersebut berada dalam cache. Penyimpanan Kueri juga menyediakan metrik rata-rata untuk berbagai sumber daya, tetapi metrik ini dikumpulkan selama jangka waktu tertentu (mis. 30 menit atau satu jam). Tentu saja ada solusi pemantauan pihak ketiga yang lebih dari mampu memberi Anda semua ini dan lebih banyak lagi (seperti SentryOne), tetapi untuk posting ini saya ingin fokus pada alat asli.
Jika Anda ingin memahami kinerja kueri untuk masing-masing eksekusi guna menentukan kueri yang tepat atau kumpulan kueri yang mungkin menjadi masalah, opsi termudah adalah menggunakan Peristiwa yang Diperpanjang. Dan salah satu cara tercepat untuk memulai adalah dengan menggunakan XEvent Profiler, yang tersedia melalui SQL Server Management Studio (mulai dari versi 17.3):
XEvent Profiler di SSMS
Penggunaan Dasar
Ada dua opsi untuk XEvent Profiler:Standar dan TSQL. Untuk menggunakan salah satunya, cukup klik dua kali pada namanya. Di balik layar, sesi acara yang ditentukan secara internal dibuat (jika belum ada) dan dimulai, dan Penampil Data Langsung segera terbuka dengan fokus. Perhatikan bahwa setelah Anda memulai sesi, sesi itu juga akan muncul di bawah Manajemen | Acara yang Diperpanjang | Sesi. Dengan asumsi Anda memiliki aktivitas terhadap server, Anda akan mulai memiliki entri yang muncul di penampil dalam lima detik atau kurang.
Penampil Data Langsung (setelah mengklik dua kali untuk memulai sesi Standar)
Sesi Standar dan TSQL berbagi beberapa acara, dengan Standar memiliki lebih banyak secara total. Berikut daftar acara untuk masing-masing acara:
Standard TSQL
sql_batch_starting sql_batch_starting
sql_batch_completed
rpc_starting
rpc_completed
logout logout
login login
existing_connection existing_connection
attention Jika Anda ingin memahami informasi tentang eksekusi kueri, seperti berapa lama kueri dijalankan, atau berapa banyak I/O yang dikonsumsi, maka Standar adalah opsi yang lebih baik karena dua peristiwa yang diselesaikan. Untuk kedua sesi, satu-satunya filter adalah mengecualikan kueri sistem untuk peristiwa batch, rpc, dan perhatian.
Melihat dan Menyimpan Data
Jika kita memulai sesi Standar dan menjalankan beberapa kueri, di penampil kita melihat acara, teks kueri, dan informasi berguna lainnya seperti cpu_time, logical_reads, dan durasi. Salah satu keuntungan menggunakan rpc_completed dan sql_batch_completed adalah parameter input muncul. Dalam kasus di mana ada prosedur tersimpan yang memiliki variasi kinerja yang besar, menangkap parameter input bisa sangat berguna karena kami dapat mencocokkan eksekusi yang membutuhkan waktu lebih lama dengan nilai tertentu yang diteruskan ke prosedur tersimpan. Untuk menemukan parameter tersebut, kita perlu mengurutkan data berdasarkan durasi, yang tidak dapat kita lakukan saat data feed aktif. Untuk melakukan analisis apa pun, umpan data harus dihentikan.
Menghentikan Umpan Data di Penampil Langsung
Sekarang setelah kueri saya tidak lagi bergulir dengan kabur, saya dapat mengklik kolom durasi untuk mengurutkan acara saya. Pertama kali saya klik akan mengurutkan dalam urutan menaik, dan karena saya malas dan tidak ingin menggulir ke bawah, saya akan mengklik lagi untuk mengurutkan dalam urutan menurun.
Acara diurutkan menurut durasi menurun
Sekarang saya dapat melihat semua peristiwa yang telah saya tangkap dalam urutan durasi tertinggi hingga terendah. Jika saya mencari prosedur tersimpan tertentu yang lambat, saya dapat menggulir ke bawah sampai saya menemukannya (yang mungkin menyakitkan), atau saya dapat mengelompokkan atau memfilter data. Pengelompokan lebih mudah di sini, karena saya tahu nama prosedur tersimpan.
Nama_objek ditampilkan di bagian atas penampil, tetapi mengklik acara rpc_completed menunjukkan semua elemen yang ditangkap di panel Detail. Klik kanan pada object_name, yang akan menyorotnya, dan pilih Show Column in Table.
Tambahkan nama_objek ke penampil data
Di panel atas saya sekarang dapat mengklik kanan pada object_name dan memilih Group by this Column. Jika saya memperluas acara di bawah usp_GetPersonInfo dan kemudian mengurutkan lagi berdasarkan durasi, sekarang saya melihat bahwa eksekusi dengan PersonID=3133 memiliki durasi tertinggi.
Acara dikelompokkan menurut object_name, usp_GetPersonInfo diurutkan menurut durasi menurun
Untuk memfilter data:Gunakan tombol Filter…, opsi menu (Extended Events | Filters…), atau CTRL + R untuk membuka jendela guna mengurangi kumpulan hasil berdasarkan bidang berbeda yang ditampilkan. Dalam hal ini kami memfilter pada object_name =usp_GetPersonInfo, tetapi Anda juga dapat memfilter pada bidang seperti server_principal_name atau client_app_name, seperti yang dikumpulkan.
Perlu ditunjukkan bahwa sesi Standar atau TSQL tidak menulis ke file. Faktanya, tidak ada target untuk kedua sesi acara (jika Anda tidak tahu bahwa Anda dapat membuat sesi acara tanpa target, sekarang Anda tahu). Jika Anda ingin menyimpan data ini untuk analisis lebih lanjut, Anda perlu melakukan salah satu hal berikut:
- Hentikan feed data dan simpan output ke file melalui menu Extended Events (Ekspor ke | File XEL…)
- Hentikan data feed dan simpan output ke tabel di database melalui menu Extended Events (Ekspor ke | Tabel…)
- Ubah sesi acara dan tambahkan event_file sebagai target.
Opsi 1 adalah rekomendasi saya, karena ini membuat file di disk yang dapat Anda bagikan dengan orang lain dan tinjau nanti di Management Studio untuk analisis lebih lanjut. Dalam Management Studio, Anda memiliki kemampuan untuk memfilter data yang tidak relevan, mengurutkan menurut satu atau beberapa kolom, mengelompokkan data, dan melakukan penghitungan (misalnya rata-rata). Anda dapat melakukan ini jika data berupa tabel, tetapi Anda harus menulis TSQL; menganalisis data di UI lebih mudah dan lebih cepat.
Mengubah Sesi XEvent Profiler
Anda dapat mengubah sesi acara Standar dan TSQL dan perubahan yang Anda buat akan tetap ada melalui mulai ulang instans. Namun, jika sesi acara dihentikan (setelah Anda melakukan modifikasi), sesi tersebut akan diatur ulang kembali ke default. Jika Anda mendapati diri Anda terus-menerus membuat perubahan yang sama, saya sarankan Anda membuat skrip perubahan dan membuat sesi acara baru yang juga akan tetap ada saat dimulai ulang. Sebagai contoh, jika kita melihat output yang diambil sejauh ini, kita dapat melihat bahwa baik query adhoc dan prosedur tersimpan telah dieksekusi. Dan meskipun bagus bahwa saya dapat melihat parameter input yang berbeda untuk prosedur tersimpan, saya tidak melihat pernyataan individual yang dijalankan dengan rangkaian peristiwa ini. Untuk mendapatkan informasi itu, saya perlu menambahkan acara sp_statement_completed.
Pahami bahwa sesi acara Standar dan TSQL dirancang agar ringan. Peristiwa statement_completed akan diaktifkan lebih sering daripada peristiwa batch dan rpc, sehingga mungkin ada lebih banyak overhead saat peristiwa ini menjadi bagian dari sesi acara. Saat menggunakan peristiwa pernyataan, saya sangat merekomendasikan termasuk predikat tambahan. Sebagai pengingat, acara rpc dan batch hanya menyaring kueri sistem – tidak ada predikat lain. Secara umum, saya juga merekomendasikan predikat tambahan untuk acara ini, terutama untuk beban kerja bervolume tinggi.
Jika Anda khawatir apakah menjalankan sesi Standar atau TSQL akan menyebabkan penurunan kinerja pada sistem Anda, pahami bahwa Live Data Viewer akan terputus jika membuat terlalu banyak overhead pada sistem. Ini adalah keamanan yang hebat, tetapi saya akan tetap bijaksana saat menggunakan sesi acara ini. Saya percaya mereka adalah langkah pertama yang fantastis untuk pemecahan masalah, terutama bagi mereka yang baru mengenal SQL Server atau Extended Events. Namun, jika Anda membuka Live Data Viewer dan meninggalkan mesin Anda, sesi acara akan terus berjalan . Menghentikan atau menutup Live Data Viewer akan menghentikan sesi acara, yang saya sarankan saat Anda selesai dengan pengumpulan data atau pemecahan masalah.
Untuk sesi acara yang ingin Anda jalankan untuk jangka waktu yang lebih lama, buat sesi acara terpisah yang menulis ke target event_file dan memiliki predikat yang sesuai. Jika Anda memerlukan informasi lebih lanjut tentang memulai dengan Acara yang Diperpanjang, lihat sesi yang saya berikan di SQLBits tahun lalu tentang migrasi dari Profiler ke Acara yang Diperpanjang.
