SQL Server Activity Monitor: Panduan Lengkap untuk DBA [2026]

1. Pengantar

1.1 Apa SQL Server Monitor Aktivitas?

SQL Server Activity Monitor adalah alat diagnostik bawaan di dalam SQL Server Studio Manajemen yang menampilkan informasi tentang SQL Server proses dan pengaruhnya terhadap kinerja server. Ini memungkinkan Anda untuk melacak SQL Server proses, memantau waktu tunggu sumber daya, menganalisis kueri mahal, dan mengamati pola I/O—semuanya dari satu antarmuka.

1.2 Mengapa Menggunakan SQL Server Monitor Aktivitas?

Activity Monitor berfungsi sebagai garis pertahanan pertama Anda saat memecahkan masalah kinerja. Activity Monitor memberikan visibilitas langsung terhadap apa yang terjadi di SQL Server contoh tanpa memerlukan kueri T-SQL yang rumit atau alat pihak ketiga.

Alat ini unggul dalam membantu Anda mengidentifikasi masalah umum dengan cepat seperti sesi yang terblokir, kueri yang membutuhkan CPU intensif, eksekusi kueri yang berlebihan, dan kemacetan I/O. Ketika pengguna melaporkan bahwa suatu aplikasi lambat atau tidak responsif, Activity Monitor membantu Anda menentukan apakah server basis data adalah penyebabnya.

Untuk administrator basis data yang tidak bekerja dengan SQL Server Setiap hari, Activity Monitor menawarkan titik masuk yang mudah diakses untuk memahami aktivitas server. Bahkan DBA berpengalaman pun menggunakannya sebagai titik awal untuk investigasi kinerja.

1.3 Monitor Aktivitas vs Alat Pemantauan Lainnya

Meskipun Activity Monitor berharga, penting untuk memahami bagaimana ia dibandingkan dengan opsi pemantauan lainnya:

Monitor Aktivitas vs sp_WhoIsActive: Activity Monitor menyediakan antarmuka grafis dengan beberapa panel, sementara sp_WhoIsActive merupakan prosedur tersimpan komprehensif yang menawarkan informasi lebih terperinci dalam satu set hasil. sp_WhoIsActive menunjukkan jenis tunggu spesifik yang dikelompokkan bersama oleh Activity Monitor dan menyediakan informasi pemblokiran yang lebih terperinci.

Monitor Aktivitas vs sp_who2: Perintah sp_who2 tradisional menampilkan informasi sesi dasar, tetapi Activity Monitor melangkah lebih jauh dengan menampilkan statistik tunggu, kueri mahal, dan metrik I/O dalam format visual yang terorganisasi.

Monitor Aktivitas vs Alat Pihak Ketiga: Solusi pemantauan komersial seperti SolarWinds Database Performance Analyzer menawarkan pelacakan historis, peringatan, dan analitik canggih yang tidak dimiliki Activity Monitor. Namun, Activity Monitor tidak memerlukan biaya atau instalasi tambahan.

1.4 Manfaat Utama bagi Administrator Basis Data

Activity Monitor menawarkan beberapa keuntungan yang menjadikannya alat DBA yang penting:

• Biaya Nol: Sebagai bawaan SQL Server Fitur Management Studio, tidak ada biaya lisensi atau upaya penerapan yang diperlukan.
• Pemantauan Waktu Nyata: Lihat aktivitas server saat ini saat itu terjadi, dengan interval penyegaran yang dapat dikonfigurasi dari 1 detik hingga 1 jam.
• Tindakan Terpadu: Klik kanan pada proses untuk menghentikan sesi, melihat detail kueri, atau meluncurkan SQL Server Jejak profiler—semuanya dari dalam alat.
• Berbagai Perspektif: Lihat kesehatan server dari berbagai sudut melalui lima panel khusus, yang masing-masing berfokus pada aspek kinerja tertentu.
• Pemecahan Masalah Cepat: Identifikasi masalah kinerja yang paling umum dalam hitungan menit, mempercepat waktu rata-rata penyelesaian masalah.
• Hambatan Masuk Rendah: Tidak diperlukan pengetahuan tingkat lanjut untuk mulai menggunakan alat ini secara efektif, meskipun lebih dalam SQL Server keahlian membantu dalam penafsiran.

2. Memulai Menggunakan Activity Monitor

Sebelum Anda dapat memanfaatkan Activity Monitor secara efektif, Anda perlu memahami prasyarat, izin yang diperlukan, dan berbagai metode untuk meluncurkan alat tersebut.

2.1 Prasyarat dan Persyaratan Sistem

Untuk menggunakan SQL Server Monitor Aktivitas, Anda perlu SQL Server Management Studio (SSMS) yang terpasang di komputer lokal Anda atau server jump. Alat Activity Monitor didesain ulang secara signifikan di SQL Server 2008, sehingga informasi dalam panduan ini berlaku untuk SQL Server Versi 2008 dan yang lebih baru.

Anda harus memiliki konektivitas jaringan ke SQL Server instance yang ingin Anda pantau. Untuk basis data yang dihosting di cloud, Anda biasanya memerlukan koneksi VPN atau aturan firewall yang dikonfigurasi dengan benar untuk mengakses instance tersebut.

Activity Monitor berfungsi dengan semua edisi SQL Server, termasuk Express, Standard, dan Enterprise. Alat ini sendiri berjalan di mesin klien Anda dalam SSMS, sehingga sumber daya server hanya terpengaruh oleh kueri pemantauan yang dijalankannya.

2.2 Izin yang Diperlukan

Izin yang tepat sangat penting agar Monitor Aktivitas berfungsi dengan baik. Tanpa izin yang sesuai, Anda mungkin melihat tampilan kosong atau menerima pesan kesalahan akses ditolak.

2.2.1 LIHAT STATUS SERVER Izin

The LIHAT STATUS SERVER Izin merupakan persyaratan utama untuk menggunakan Activity Monitor. Izin tingkat server ini memungkinkan Anda melihat semua proses aktif dan metrik terkaitnya.

Untuk memberikan izin ini, administrator server dapat menjalankan:

GRANT VIEW SERVER STATE TO [YourLoginName];

Tanpa VIEW SERVER STATE, Activity Monitor mungkin terbuka tetapi tidak menampilkan data apa pun di panelnya.

2.2.2 Izin Tingkat Basis Data

Untuk melihat informasi di panel I/O Berkas Data, Anda memerlukan izin tambahan. Secara spesifik, Anda harus memiliki salah satu kombinasi berikut:

• BUAT DATABASE izin, atau
• UBAH DATABASE APAPUN izin, atau
• LIHAT DEFINISI APAPUN izin

Izin ini harus digabungkan dengan LIHAT STATUS SERVER untuk fungsionalitas Monitor Aktivitas penuh.

2.2.3 Pemecahan Masalah Izin

Jika Activity Monitor terbuka tetapi tidak menampilkan data, penyebab paling umum adalah masalah izin. Periksa apakah login Anda memiliki hak akses VIEW SERVER STATE di tingkat server. Anda dapat memverifikasi izin Anda dengan menjalankan perintah berikut:

SELECT * FROM fn_my_permissions(NULL, 'SERVER');

Cari "VIEW SERVER STATE" di kolom permission_name. Jika tidak ada, hubungi administrator basis data Anda untuk mendapatkan izin tersebut.

2.3 Cara Membuka Monitor Aktivitas di SSMS

SQL Server Management Studio menyediakan empat metode berbeda untuk meluncurkan Activity Monitor, memberi Anda fleksibilitas berdasarkan preferensi alur kerja Anda.

2.3.1 Metode 1: Dari Toolbar

Cara tercepat untuk membuka Activity Monitor adalah menggunakan ikon toolbar:

1. Sambungkan ke SQL Server contoh di SQL Server Studio Manajemen.
2. Temukan ikon Activity Monitor di toolbar standar (ikon tersebut menyerupai diagram batang dengan tombol putar berwarna hijau).
3. Klik ikon untuk meluncurkan Activity Monitor.

Metode ini paling cepat jika Anda sudah bekerja di SSMS dan perlu memeriksa aktivitas server dengan cepat.

2.3.2 Metode 2: Dari Object Explorer

Anda juga dapat meluncurkan Activity Monitor langsung dari Object Explorer:

1. Di Object Explorer, temukan SQL Server contoh yang ingin Anda pantau.
2. Klik kanan pada nama instans.
3. Pilih Activity Monitor dari menu konteks

Metode ini berguna saat menghubungkan ke beberapa server, karena memastikan Anda memantau instansi yang benar.

2.3.3 Metode 3: Menggunakan Pintasan Keyboard

Untuk pengguna yang fokus pada keyboard, SQL Server Management Studio menyediakan pintasan khusus:

1. Pastikan SSMS adalah jendela aktif dan Anda terhubung ke suatu instansi.
2. Media Ctrl + lain + A.
3. Activity Monitor akan terbuka untuk contoh yang sedang dipilih di Object Explorer.

Perhatikan bahwa Activity Monitor akan terhubung ke instansi server mana pun yang telah Anda pilih di Object Explorer, jadi pastikan Anda telah memilih instansi yang benar sebelum menggunakan pintasan ini.

2.3.4 Metode 4: Dari Menu Opsi (Konfigurasi Startup)

Jika Anda sering menggunakan Activity Monitor, Anda dapat mengkonfigurasi SSMS untuk meluncurkannya secara otomatis setiap kali Anda memulai aplikasi:

1. In SQL Server Studio Manajemen, navigasikan ke Tools -> Opsi.
2. Di kotak dialog Opsi, perluas Lingkungan Hidup, Dan kemudian pilih startup.
3. Dari Saat startup daftar tarik-turun, pilih Buka Penjelajah Objek dan Monitor Aktivitas.
4. Pilih OK.

Saat berikutnya Anda meluncurkan SSMS dan terhubung ke server, Activity Monitor akan terbuka otomatis bersama Object Explorer.

3. Memahami Panel Monitor Aktivitas

Activity Monitor mengelompokkan informasi ke dalam lima panel yang dapat diperluas, masing-masing memberikan perspektif berbeda tentang aktivitas server. Memahami apa yang ditampilkan setiap panel sangat penting untuk pemecahan masalah yang efektif.

3.1 Panel Ikhtisar

Panel Ikhtisar menyajikan empat grafik waktu nyata yang memberi Anda gambaran singkat kesehatan Anda SQL Server Grafik ini diperbarui pada interval yang dapat dikonfigurasi dan membantu Anda mengidentifikasi pola abnormal secara sekilas.

3.1.1% Waktu Prosesor

Grafik ini menunjukkan persentase waktu yang dihabiskan prosesor untuk mengeksekusi thread non-idle untuk SQL Server contoh di semua CPU. Nilai tersebut mewakili SQL Serverpemanfaatan prosesor, bukan keseluruhan penggunaan CPU server.

Jika Anda secara konsisten melihat waktu prosesor berada di angka 100% atau mendekati 100%, server Anda mengalami keterbatasan CPU. Ini dapat mengindikasikan kueri yang tidak efisien, indeks yang hilang, atau kapasitas perangkat keras yang tidak mencukupi. Gunakan panel Kueri Mahal Terbaru untuk mengidentifikasi kueri mana yang paling banyak mengonsumsi CPU.

3.1.2 Tugas Menunggu

Metrik ini menampilkan jumlah tugas yang menunggu pelepasan sumber daya sebelum dapat dilanjutkan. Tugas mungkin menunggu CPU, I/O, memori, atau kunci.

Jumlah tugas yang menunggu secara konsisten tinggi menunjukkan adanya perebutan sumber daya. Panel "Resource Waits" memberikan detail lebih lanjut tentang jenis sumber daya yang menyebabkan waktu tunggu.

3.1.3 Input/Output Basis Data (MB/dtk)

Grafik ini menunjukkan laju transfer data antara memori dan disk. Grafik ini menggabungkan pembacaan dan penulisan data, diukur dalam megabita per detik.

Lonjakan I/O basis data dapat mengindikasikan kueri yang melakukan pemindaian tabel besar, aktivitas pencatatan yang berlebihan, atau operasi titik pemeriksaan. Panel I/O Berkas Data menguraikan aktivitas I/O berdasarkan basis data dan berkas.

3.1.4 Permintaan Batch/detik

Metrik ini mewakili jumlah SQL Server batch yang diterima oleh instans per detik. Satu batch dapat berupa satu pernyataan atau beberapa pernyataan yang dikirimkan bersamaan.

Nilai ini memberikan gambaran aktivitas server secara keseluruhan. Penurunan permintaan batch yang tiba-tiba selama jam kerja normal dapat mengindikasikan masalah konektivitas aplikasi atau masalah yang dihadapi pengguna.

3.1.5 Mengatur Interval Penyegaran

Anda dapat menyesuaikan seberapa sering Activity Monitor memperbarui datanya:

1. Klik kanan di mana saja di panel Ikhtisar.
2. Pilih Interval Penyegaran.
3. Pilih interval dari nilai yang telah ditentukan: 1 detik, 5 detik, 10 detik (default), 30 detik, 1 menit, atau 1 jam.

Menetapkan interval penyegaran di bawah 10 detik akan meningkatkan beban pemantauan di server Anda. Untuk sistem produksi dengan beban berat, pertimbangkan untuk menggunakan interval 30 detik atau lebih lama guna meminimalkan dampak.

3.2 Panel Proses

Panel Proses menampilkan informasi tentang sesi yang sedang berjalan di komputer Anda. SQL Server Misalnya. Panel ini penting untuk mengidentifikasi siapa yang melakukan apa dan menemukan masalah yang menghalangi.

3.2.1 Memahami Informasi Proses

Setiap baris di panel Proses mewakili sesi aktif di server. Panel ini menampilkan sesi dari semua basis data dan semua pengguna, memberikan Anda tampilan aktivitas server yang komprehensif.

Informasi yang ditampilkan mencakup nama login, nama aplikasi, nama host, basis data yang diakses, dan perintah saat ini. Ini membantu Anda menghubungkan aktivitas basis data dengan pengguna atau aplikasi tertentu.

3.2.2 Kolom Utama Dijelaskan

Memahami kolom-kolom utama membantu Anda menginterpretasikan informasi proses secara efektif:

• ID Sesi: Pengidentifikasi unik untuk setiap koneksi. Proses sistem menggunakan ID sesi negatif.
• Proses Pengguna: Menunjukkan apakah ini sesi pengguna (Ya) atau proses sistem (Tidak).
• Masuk: The SQL Server login atau akun Windows yang terkait dengan sesi tersebut.
• Database: Konteks basis data saat ini untuk sesi tersebut.
• Status Tugas: Menunjukkan apa yang sedang dilakukan sesi (BERJALAN, DITANGGUHKAN, TIDUR, dsb.).
• command: Jenis perintah yang sedang dieksekusi (SELECT, INSERT, UPDATE, dll.).
• Aplikasi: Nama aplikasi yang membuat koneksi.
• Waktu Tunggu: Berapa lama (dalam milidetik) sesi telah menunggu sumber daya.
• Jenis Tunggu: Jenis sumber daya spesifik yang ditunggu oleh sesi.
• Waktu CPU: Total waktu CPU yang dikonsumsi oleh sesi ini sejak terhubung.
• Penggunaan Memori: Jumlah memori (dalam KB) yang saat ini dialokasikan untuk sesi.

3.2.3 Proses Penyaringan dan Penyortiran

Panel Proses mencakup kemampuan penyaringan canggih untuk membantu Anda fokus pada sesi yang relevan:

1. Klik tanda panah tarik-turun pada tajuk kolom mana saja.
2. Filter menunjukkan nilai yang tersedia untuk kolom tersebut, termasuk Semua, Kosong, dan NonBlanks.
3. Pilih nilai tertentu untuk memfilter tampilan hanya ke sesi tersebut.

Misalnya, Anda dapat memfilter Status Tugas untuk hanya menampilkan sesi yang BERJALAN, atau filter Basis Data untuk melihat aktivitas terhadap basis data tertentu.

Anda juga dapat mengurutkan berdasarkan kolom mana pun dengan mengeklik tajuknya. Klik sekali untuk urutan menaik, dan klik dua kali untuk urutan menurun.

3.2.4 Mengidentifikasi Pemblokiran dan Sesi yang Diblokir

Panel Proses membantu Anda mengidentifikasi skenario pemblokiran di mana satu sesi mencegah sesi lain untuk melanjutkan:

• Diblokir Oleh: Menampilkan ID Sesi dari sesi yang memblokir sesi ini. Jika kolom ini berisi nilai, sesi tersebut sedang menunggu penguncian yang dilakukan oleh sesi lain.
• Pemblokir Kepala: Menampilkan '1' jika sesi ini memblokir sesi lain tetapi sesi itu sendiri tidak diblokir. Ini adalah akar penyebab rantai pemblokiran.

Untuk menyelidiki masalah pemblokiran, pertama-tama identifikasi pemblokir utama (sesi yang ditandai dengan '1' di kolom Pemblokir Utama), lalu periksa apa yang dilakukannya dan putuskan apakah akan membiarkannya selesai atau menghentikannya.

3.2.5 Tindakan Proses (Bunuh, Detail, Lacak)

Monitor Aktivitas memungkinkan Anda mengambil tindakan pada sesi individual:

1. Klik kanan pada sesi mana saja di panel Proses.
2. Anda akan melihat beberapa pilihan:
   • rincian: Menampilkan perintah terakhir yang dieksekusi oleh sesi ini.
   • Proses Pembunuhan: Mengakhiri sesi (gunakan dengan hati-hati).
   • Jejak Proses di SQL Server pembuat profil: Luncurkan SQL Server Profil dan secara otomatis menyaring untuk hanya menampilkan aktivitas dari sesi ini.

Opsi Detail menunjukkan teks perintah, tetapi perhatikan bahwa ini adalah terakhir Perintah dieksekusi—mungkin masih belum berjalan. Opsi Lacak sangat berguna ketika Anda perlu melihat urutan lengkap perintah yang sedang dieksekusi oleh suatu sesi.

3.3 Panel Tunggu Sumber Daya

Panel Resource Waits merangkum statistik penantian, menunjukkan jenis sumber daya apa yang paling sering ditunggu oleh sesi. Informasi ini sangat penting untuk mendiagnosis hambatan kinerja.

3.3.1 Memahami Statistik Tunggu

Ketika SQL Server Jika permintaan sumber daya (seperti kunci, waktu CPU, atau memori) tidak dapat segera dikabulkan, tugas yang diminta akan memasuki status tunggu. Statistik tunggu melacak periode tunggu ini dan membantu Anda memahami di mana server menghabiskan waktu menunggu, alih-alih bekerja.

Panel Resource Waits mengumpulkan data dari tampilan manajemen dinamis sistem seperti sys.dm_os_wait_stats dan sys.dm_exec_requests. Pada setiap interval penyegaran, panel ini menghitung selisih antara snapshot saat ini dan sebelumnya, yang menunjukkan tingkat akumulasi untuk setiap jenis tunggu.

3.3.2 Kategori Tunggu

Kelompok Monitor Aktivitas mengelompokkan ratusan jenis tunggu individual ke dalam kategori yang lebih luas untuk menyederhanakan interpretasi:

• CPU: Tugas menunggu waktu CPU tersedia.
• Kunci Penyangga: Menunggu objek sinkronisasi jangka pendek yang melindungi akses ke halaman data di memori. Kategori ini mencakup penantian kait halaman (PAGELATCH_*).
• Kunci: Penantian disebabkan oleh sesi yang menahan kunci yang dibutuhkan sesi lain.
• Оперативная память: Menunggu hibah memori yang dibutuhkan oleh operasi seperti penyortiran dan pembuatan hash.
• Jaringan I/O: Menunggu pengiriman data ke atau penerimaan data dari klien.
• SQL CLR: Penantian terkait dengan eksekusi Common Language Runtime.

Meskipun pengelompokan ini menyederhanakan tampilan, pengelompokan ini juga mengaburkan detail penting. Misalnya, "Buffer Latch" mungkin mengelompokkan PAGELATCH_SH, PAGELATCH_UP, dan PAGELATCH_EX, yang memiliki implikasi berbeda terhadap kinerja.

3.3.3 Menafsirkan Waktu Tunggu dan Tugas Tunggu

Panel Waktu Tunggu Sumber Daya menampilkan dua metrik utama untuk setiap kategori waktu tunggu:

• Waktu Tunggu Kumulatif (ms): Total milidetik yang terakumulasi selama interval penyegaran saat ini untuk kategori tunggu ini.
• Tugas Menunggu: Jumlah tugas yang saat ini menunggu sumber daya dalam kategori ini.

Nilai waktu tunggu sangat menarik. Jika Anda memiliki interval penyegaran 10 detik dan melihat waktu tunggu 20,000 ms untuk suatu kategori, hal ini menunjukkan adanya beberapa waktu tunggu bersamaan (20,000 ms / 10,000 ms = rata-rata 2 waktu tunggu bersamaan selama interval tersebut).

3.3.4 Mengidentifikasi Hambatan Kinerja

Gunakan panel Resource Waits untuk mengidentifikasi di mana server Anda menghabiskan sebagian besar waktu menunggu:

1. Perluas panel Waktu Tunggu Sumber Daya.
2. Amati kategori tunggu yang mengumpulkan waktu tunggu tertinggi.
3. Sortir dengan Waktu Tunggu Kumulatif untuk melihat sumber daya mana yang paling terbatas.

Penantian Buffer Latch yang tinggi sering kali mengindikasikan adanya perebutan halaman data di memori, yang mungkin mengindikasikan adanya kemacetan I/O atau perebutan tempdb. Penantian Lock yang tinggi mengindikasikan adanya masalah pemblokiran. Penantian Memori yang tinggi mengindikasikan pemberian memori yang tidak memadai untuk operasi kueri.

3.4 Panel I/O File Data

Panel I/O File Data memperlihatkan aktivitas disk untuk setiap file basis data di server Anda, membantu Anda mengidentifikasi hambatan I/O dan memahami pola penggunaan disk.

3.4.1 Memahami Metrik I/O

Panel I/O File Data menampilkan beberapa metrik untuk setiap file basis data:

• Database: Nama databasenya.
• Jenis File: Entah Data (termasuk tabel dan indeks) atau Log (log transaksi).
• Nama Logika: Nama file logis seperti yang didefinisikan dalam SQL Server.
• MB/detik Baca: Kecepatan data yang dibaca dari berkas ini.
• MB/detik Ditulis: Kecepatan data yang ditulis ke berkas ini.
• Waktu Respon (ms): Waktu respons rata-rata untuk operasi I/O pada berkas ini.

Metrik ini diperbarui pada interval yang sama dengan panel Ikhtisar, memberikan Anda visibilitas waktu nyata ke dalam aktivitas disk.

3.4.2 Mengidentifikasi Hambatan I/O

Perhatikan pola berikut yang menunjukkan masalah kinerja I/O:

• Waktu Respon Tinggi: Waktu respons yang konsisten di atas 15-20 ms menunjukkan subsistem disk yang lambat. Waktu respons di atas 50 ms menunjukkan adanya hambatan I/O yang serius.
• Beban tidak seimbang: Jika satu berkas data menunjukkan laju I/O yang jauh lebih tinggi daripada berkas lain dalam basis data yang sama, Anda dapat memperoleh manfaat dari penambahan berkas tambahan untuk mendistribusikan beban.
• Aktivitas Tempdb yang Berlebihan: Kecepatan I/O yang tinggi pada berkas tempdb sering kali mengindikasikan kueri yang menciptakan set hasil antara yang besar atau menggunakan rencana eksekusi yang tidak efisien.

3.4.3 Analisis Berkas Basis Data

Gunakan panel I/O File Data untuk memahami bagaimana database Anda menggunakan sumber daya disk:

1. Perluas panel I/O Berkas Data.
2. Sortir dengan MB/detik Baca or MB/detik Ditulis untuk mengidentifikasi file yang paling aktif.
3. Catat file apa pun dengan aktivitas tinggi secara konsisten atau waktu respons yang lama.
4. Periksa silang informasi ini dengan panel Kueri Mahal Terkini untuk mengidentifikasi kueri mana yang menggerakkan beban I/O.

3.5 Panel Kueri Mahal Terbaru

Panel Kueri Mahal Terbaru seringkali menjadi panel yang paling berharga untuk memecahkan masalah kinerja aplikasi. Panel ini menunjukkan kueri yang mengonsumsi sumber daya server secara signifikan, membantu Anda mengidentifikasi peluang pengoptimalan.

3.5.1 Memahami Metrik Kueri

Activity Monitor menampilkan beberapa metrik untuk setiap kueri mahal:

• Eksekusi/menit: Berapa kali kueri dijalankan pada menit terakhir.
• CPU (ms/detik): Waktu CPU yang dikonsumsi oleh kueri ini per detik.
• Pembacaan Fisik/detik: Jumlah pembacaan disk fisik per detik untuk kueri ini.
• Penulisan Logika/detik: Jumlah penulisan logis (ke cache buffer) per detik.
• Pembacaan Logika/detik: Jumlah pembacaan logis (dari cache buffer) per detik.
• Durasi Rata-rata (ms): Waktu eksekusi rata-rata untuk kueri ini.
• Jumlah Rencana: Jumlah rencana eksekusi dalam cache untuk kueri ini.

Metrik ini membantu Anda memahami tidak hanya kueri mana yang mahal, tetapi juga mengapa harganya mahal dan seberapa sering mereka beroperasi.

3.5.2 Opsi Penyortiran

Anda dapat mengurutkan panel Kueri Mahal Terbaru berdasarkan metrik yang berbeda untuk menemukan berbagai jenis masalah:

1. Klik tajuk kolom mana saja untuk mengurutkan berdasarkan metrik tersebut.
2. Strategi penyortiran umum meliputi:
   • Urutkan berdasarkan CPU: Temukan kueri yang paling banyak mengonsumsi waktu prosesor.
   • Urutkan berdasarkan Eksekusi/menit: Identifikasi kueri yang terlalu sering dijalankan.
   • Urutkan berdasarkan Bacaan Fisik: Temukan kueri yang menyebabkan I/O disk paling banyak.
   • Urutkan berdasarkan Durasi Rata-rata: Temukan kueri yang berjalan lama.

Saat memecahkan masalah kinerja, cobalah mengurutkan berdasarkan beberapa kolom untuk mendapatkan perspektif yang berbeda. Kueri dengan penggunaan CPU sedang tetapi eksekusi per menit yang sangat tinggi mungkin merupakan masalah utama Anda.

3.5.3 Melihat Teks Kueri

Untuk melihat pernyataan SQL sebenarnya di balik kueri yang mahal:

1. Klik kanan pada baris kueri di panel Kueri Mahal Terkini.
2. Pilih Edit Teks Kueri.
   
3. Jendela kueri baru terbuka, menampilkan pernyataan SQL lengkap.
   

Ini memungkinkan Anda memeriksa logika kueri dan mengidentifikasi potensi peluang pengoptimalan. Anda kemudian dapat menyalin teks kueri untuk menguji versi yang dimodifikasi.

3.5.4 Menganalisis Rencana Eksekusi

Rencana eksekusi menunjukkan kepada Anda bagaimana SQL Server mengeksekusi sebuah query, mengungkap inefisiensi seperti indeks yang hilang atau tipe gabungan yang tidak sesuai:

1. Klik kanan pada baris kueri di panel Kueri Mahal Terkini.
2. Pilih Tampilkan Rencana Eksekusi.
   
3. SQL Server Management Studio menampilkan representasi grafis tentang bagaimana kueri dijalankan.
   

Carilah operasi yang menghabiskan persentase besar biaya kueri, peringatan tentang statistik atau indeks yang hilang, dan operasi pemindaian tabel yang tidak terduga. Hal-hal ini sering menunjukkan di mana upaya optimasi harus difokuskan.

3.5.5 Mengidentifikasi Pertanyaan yang Bermasalah

Perhatikan pola berikut di panel Kueri Mahal Terkini:

• Eksekusi Berlebihan: Permintaan yang dijalankan ribuan kali per menit mungkin mengindikasikan masalah permintaan N+1 di mana kode aplikasi memanggil basis data di dalam suatu perulangan.
• Pembacaan Fisik Tinggi: Kueri dengan kecepatan baca fisik yang tinggi sering mengenai disk, yang menunjukkan adanya indeks yang hilang atau kueri yang ditulis dengan buruk.
• CPU Tinggi dengan Durasi Rendah: Banyak kueri cepat yang menghabiskan banyak CPU secara agregat dapat memengaruhi kinerja server seperti halnya beberapa kueri lambat.
• Jumlah Paket Ganda: Kueri dengan banyak rencana eksekusi mungkin mengalami masalah pengendus parameter atau kueri tak berparameter yang menyebabkan kembungnya cache rencana.

4. Menggunakan Activity Monitor untuk Pemecahan Masalah Performa

Activity Monitor benar-benar unggul jika digunakan secara sistematis untuk mendiagnosis dan mengatasi masalah kinerja. Bagian ini membahas skenario pemecahan masalah umum dan cara mengatasinya.

4.1 Mendiagnosis Eksekusi Query yang Berlebihan

Salah satu masalah kinerja yang paling umum adalah kueri yang dieksekusi jauh lebih sering daripada yang diperlukan, seringkali karena masalah desain aplikasi.

4.1.1 Mengidentifikasi Pertanyaan Berulang

Untuk menemukan kueri yang terlalu sering dijalankan:

1. Buka Activity Monitor dan perluas Pertanyaan Mahal Terbaru pane
2. Sortir dengan Eksekusi/menit (eksekusi per menit).
3. Cari kueri di bagian atas dengan jumlah eksekusi yang tampaknya sangat tinggi.
4. Klik kanan kueri yang dicurigai dan pilih Edit Teks Kueri untuk memeriksa pernyataan SQL.

Sebagai contoh, jika Anda melihat pernyataan SELECT sederhana dieksekusi 37,000 kali per menit, pertanyakan apakah aplikasi tersebut benar-benar perlu memanggil kueri ini sesering itu. Sebagian besar kueri yang dieksekusi lebih dari beberapa ribu kali per menit perlu diselidiki.

4.1.2 Analisis Akar Penyebab

Eksekusi kueri yang berlebihan biasanya disebabkan oleh masalah berikut:

• Masalah Kueri N+1: Kode aplikasi mengambil daftar item, lalu mengeksekusi kueri terpisah untuk setiap item guna mengambil data terkait. Hal ini menghasilkan N kueri tambahan, dengan N adalah jumlah item.
• Caching Hilang: Aplikasi tersebut melakukan query ke database untuk data yang jarang berubah, alih-alih menyimpannya dalam memori aplikasi.
• Loop Polling: Kode berulang kali menanyakan basis data untuk memeriksa perubahan status alih-alih menggunakan pemberitahuan perubahan atau antrean pesan.
• Ketidakefisienan ORM: Entity Framework dan alat serupa terkadang menghasilkan pola kueri yang tidak efisien saat pengembang tidak memahami bagaimana kode mereka diterjemahkan ke SQL.

Untuk menentukan akar permasalahan, telusuri kembali kueri ke kode aplikasi. Perhatikan Aplikasi ke Masuk kolom di panel Proses saat kueri dijalankan. Anda juga dapat mengklik kanan proses dan memilih Jejak Proses di SQL Server Profil untuk melihat pola panggilan.

4.1.3 Solusi dan Praktik Terbaik

Setelah Anda mengidentifikasi eksekusi kueri yang berlebihan, pertimbangkan solusi berikut:

• Pemrosesan Batch: Ubah kode aplikasi untuk mengambil beberapa item dalam satu kueri menggunakan gabungan atau klausa IN daripada menjalankan kueri terpisah dalam satu putaran.
• Pencadangan Hasil: Cache sering diakses, data yang jarang berubah dalam memori aplikasi dengan waktu kedaluwarsa yang sesuai.
• Memuat dengan penuh semangat: Konfigurasikan ORM untuk menggunakan strategi pemuatan cepat yang mengambil data terkait dalam kueri yang lebih sedikit dan lebih efisien.
• Parameterisasi Kueri: Pastikan kueri menggunakan parameter, bukan menggabungkan nilai, yang meningkatkan penggunaan kembali cache rencana dan mengurangi overhead kompilasi.

4.2 Menyelidiki Masalah Pemblokiran

Pemblokiran terjadi ketika satu sesi terkunci sehingga mencegah sesi lain berjalan. Hal ini mengakibatkan waktu respons aplikasi yang lambat dan pengguna yang frustrasi.

4.2.1 Mengidentifikasi Rantai Pemblokiran

Untuk mendeteksi dan menganalisis pemblokiran:

1. Buka Activity Monitor dan perluas proses pane
2. Cari sesi dengan nilai di Diblokir Oleh kolom—ini menunggu kunci yang dipegang oleh sesi lain.
3. Temukan sesi dengan '1' di Pemblokir Kepala kolom—ini adalah akar penyebab pemblokiran rantai.
4. Perhatikan ID sesi dari pemblokir kepala.
5. Klik kanan sesi pemblokir kepala dan pilih Detail untuk melihat perintah apa yang dijalankannya.

Memahami rantai pemblokiran sangatlah penting. Pemblokir utama adalah sesi yang perlu Anda selidiki, bukan sesi yang diblokir di hilir.

4.2.2 Memahami Jenis Kunci

The Tipe Tunggu kolom di panel Proses menunjukkan jenis kunci yang menunggu sesi terblokir:

• LCK_M_X: Penantian kunci eksklusif, biasanya disebabkan oleh operasi UPDATE, DELETE, atau INSERT.
• LCK_M_S: Penantian kunci bersama, biasanya pernyataan SELECT menunggu kunci eksklusif dilepaskan.
• LCK_M_U: Pembaruan kunci tunggu, jenis kunci perantara yang digunakan selama pembaruan.
• LCK_M_IX: Maksud menunggu kunci eksklusif, yang menunjukkan pertentangan kunci tingkat halaman atau baris.

The Tunggu Sumber Daya Kolom menunjukkan objek basis data mana yang dikunci, membantu Anda memahami tabel atau indeks mana yang terlibat dalam pertikaian.

4.2.3 Menyelesaikan Masalah Pemblokiran

Setelah Anda mengidentifikasi sesi pemblokiran dan apa yang dilakukannya, Anda memiliki beberapa pilihan:

1. Tunggu Selesai: Jika pemblokir kepala menjalankan kueri sah yang akan segera selesai, mungkin yang terbaik adalah membiarkannya selesai secara alami.
2. Hentikan Sesi: Jika pemblokir kepala macet atau menjalankan kueri yang harus dibatalkan:
   • Klik kanan sesi di panel Proses.
   • Pilih Membunuh Proses.
   • Konfirmasikan tindakan di kotak dialog.
3. Optimalkan Kueri: Jika pemblokiran berulang dengan kueri yang sama, optimalkan kueri tersebut untuk mengurangi durasi pengunciannya.
4. Sesuaikan Tingkat Isolasi: Pertimbangkan untuk menggunakan READ COMMITTED SNAPSHOT ISOLATION untuk mengurangi pemblokiran pada beban kerja yang banyak membaca.
5. Penyetelan Indeks: Tambahkan indeks untuk mempercepat kueri, mengurangi lamanya waktu penahanan kunci.

4.3 Menganalisis Penggunaan CPU yang Tinggi

Saat panel Ikhtisar menunjukkan waktu prosesor secara konsisten pada atau mendekati 100%, Anda perlu mengidentifikasi kueri mana yang bertanggung jawab dan menentukan apakah kueri tersebut dapat dioptimalkan.

4.3.1 Mengidentifikasi Query yang Membutuhkan CPU Intensif

Untuk menemukan kueri yang menghabiskan CPU secara berlebihan:

1. Buka Pertanyaan Mahal Terbaru pane
2. Sortir dengan CPU (ms/detik) untuk menampilkan kueri yang menggunakan waktu CPU paling banyak.
3. Periksa pertanyaan teratas dalam daftar.
4. Klik kanan pada kueri CPU tinggi dan pilih Edit Teks Kueri untuk melihat pernyataan SQL.
5. Pilih Tampilkan Rencana Eksekusi untuk memahami bagaimana kueri dijalankan.

Perhatikan tidak hanya penggunaan CPU pada kueri individual tetapi juga Eksekusi/menit Kolom. Kueri yang menggunakan CPU sedang per eksekusi tetapi berjalan ribuan kali per menit dapat menjadi pemakan CPU terbesar Anda.

4.3.2 Teknik Optimasi Kueri

Pendekatan umum untuk mengurangi konsumsi CPU meliputi:

• Tambahkan Indeks yang Hilang: Pencarian indeks menggunakan CPU jauh lebih sedikit daripada pemindaian tabel. Cari rekomendasi indeks yang hilang dalam rencana eksekusi.
• Tulis Ulang Query yang Tidak Efisien: Ganti kursor dengan operasi berbasis set, hilangkan fungsi yang tidak diperlukan dalam klausa WHERE, dan hapus gabungan yang berlebihan.
• Perbarui Statistik: Statistik yang ketinggalan zaman menyebabkan SQL Server untuk memilih rencana eksekusi yang tidak efisien. Jalankan UPDATE STATISTICS pada tabel yang terdampak.
• Kurangi Volume Data: Tambahkan klausa WHERE untuk memfilter data lebih awal, gunakan TOP atau OFFSET/FETCH untuk pagination, dan hindari SELECT *.
• Memperbaiki Parameter Sniffing: Gunakan OPSI (REKOMPILASI), petunjuk kueri, atau panduan rencana saat penciuman parameter menimbulkan masalah.

4.4 Menyelidiki Masalah Memori

Tekanan memori dapat menyebabkan kueri tumpah ke disk, yang secara signifikan menurunkan kinerja. Monitor Aktivitas membantu Anda mengidentifikasi operasi yang membutuhkan banyak memori.

4.4.1 Memahami Metrik Memori

The Penggunaan Memori Kolom di panel Proses menunjukkan alokasi memori untuk setiap sesi dalam kilobyte. Penggunaan memori yang tinggi oleh satu sesi sering kali menunjukkan:

• Operasi sortir atau hash besar yang tidak dapat masuk ke dalam memori yang awalnya diberikan
• Kueri yang mengambil kumpulan hasil yang sangat besar
• Paralelisme yang berlebihan menciptakan banyak salinan operator rencana eksekusi
• Kebocoran memori dalam prosedur atau fungsi tersimpan CLR

Panel Penantian Sumber Daya dapat menampilkan Penantian Memori saat kueri tidak dapat memperoleh hibah memori yang cukup dan harus menunggu hingga memori tersedia.

4.4.2 Mengidentifikasi Query yang Membutuhkan Banyak Memori

Untuk menemukan pertanyaan yang menyebabkan tekanan memori:

1. Dalam majalah proses panel, urutkan berdasarkan Penggunaan Memori untuk melihat sesi yang paling banyak mengonsumsi memori.
2. Klik kanan sesi dengan penggunaan memori tinggi dan pilih Detail untuk melihat pertanyaan mereka.
3. Dalam majalah Pertanyaan Mahal Terbaru panel, cari kueri dengan tinggi Pembacaan Logika or Penulisan Logis, karena ini sering berkorelasi dengan penggunaan memori.
4. Periksa rencana eksekusi untuk operator Sort dan Hash Match, yang menggunakan hibah memori.

Kueri yang menampilkan peringatan “Memory Grant” dalam rencana eksekusi atau peringatan spill mengindikasikan masalah tekanan memori.

4.5 Mendeteksi Masalah Kinerja Aplikasi

Saat pengguna melaporkan waktu respons aplikasi yang lambat, Activity Monitor membantu Anda menentukan apakah basis data menjadi kendala.

4.5.1 Mengkorelasikan Monitor Aktivitas dengan Masalah Aplikasi

Untuk menyelidiki kelambatan aplikasi:

1. Catat waktu pasti pengguna melaporkan masalah dan aplikasi yang terpengaruh.
2. Buka Activity Monitor dan periksa Ringkasan panel untuk lonjakan sumber daya pada waktu itu.
3. Dalam majalah proses panel, filter berdasarkan Aplikasi untuk hanya menampilkan koneksi dari aplikasi yang terpengaruh.
4. Cari yang tinggi Waktu Tunggu nilai yang menunjukkan penundaan basis data.
5. Periksalah Pertanyaan Mahal Terbaru panel untuk kueri dari aplikasi yang menghabiskan sumber daya signifikan.

Jika basis data tidak menunjukkan aktivitas yang tidak biasa sementara pengguna mengalami kelambatan, masalahnya kemungkinan terletak pada kode aplikasi, latensi jaringan, atau kinerja sisi klien.

4.5.2 Mengidentifikasi Pola Aplikasi yang Tidak Efisien

Activity Monitor mengungkap beberapa anti-pola dalam desain aplikasi:

• Aplikasi Chatty: Banyak kueri kecil, alih-alih kueri yang lebih sedikit dan lebih efisien. Diidentifikasi oleh jumlah koneksi yang tinggi dan banyaknya kueri sederhana dalam Kueri Mahal Terbaru.
• N+1 Kueri: Satu kueri diikuti oleh N kueri tambahan untuk data terkait. Ditampilkan sebagai kueri sederhana dengan eksekusi per menit yang sangat tinggi.
• Set Hasil Besar: Aplikasi yang mengambil data jauh lebih banyak dari yang dibutuhkan. Carilah yang tinggi Pembacaan Logika dikombinasikan dengan kueri SELECT* sederhana.
• Waktu Habis yang Hilang: Aplikasi yang tidak mengatur batas waktu perintah dapat membiarkan koneksi terbuka tanpa batas waktu, terlihat sebagai sesi yang berjalan lama di panel Proses.

5. Metode Alternatif: Mendapatkan Data Monitor Aktivitas melalui T-SQL

Meskipun Activity Monitor menyediakan antarmuka grafis yang nyaman, terkadang Anda perlu mengambil informasi yang setara secara terprogram atau membuat solusi pemantauan khusus.

5.1 Menggunakan Tampilan Manajemen Dinamis (DMV)

SQL Server memaparkan informasi aktivitas melalui tampilan manajemen dinamis, yang ditanyakan oleh Activity Monitor di balik layar.

5.1.1 DMV Utama untuk Pemantauan Aktivitas

DMV terpenting untuk mereplikasi fungsionalitas Activity Monitor meliputi:

• sys.dm_exec_permintaan: Menampilkan permintaan yang sedang dieksekusi beserta informasi CPU, I/O, dan tunggu.
• sys.dm_exec_sessions: Berisi informasi tingkat sesi seperti nama login, nama host, dan nama program.
• sys.dm_os_wait_stats: Menyediakan statistik tunggu kumulatif untuk keseluruhan kejadian.
• sys.dm_exec_query_stats: Berisi statistik kinerja agregat untuk kueri yang di-cache.
• sys.dm_io_virtual_file_stats: Mengembalikan statistik I/O untuk data dan berkas log.
• sys.dm_exec_sql_teks: Mengambil teks SQL untuk sql_handle atau plan_handle yang diberikan.
• sys.dm_exec_query_plan: Mengembalikan rencana eksekusi untuk kueri yang di-cache.

5.1.2 Contoh Kueri untuk Informasi Proses

Untuk mereplikasi fungsi panel Proses, Anda dapat menanyakan:

SELECT 
    s.session_id AS [Session ID],
    CASE WHEN s.is_user_process = 1 THEN 'Yes' ELSE 'No' END AS [User Process],
    s.login_name AS [Login],
    ISNULL(CAST(r.blocking_session_id AS VARCHAR), '') AS [Blocked By],
    CASE 
        WHEN r2.session_id IS NOT NULL 
        AND (r.blocking_session_id = 0 OR r.session_id IS NULL) 
        THEN '1' 
        ELSE '' 
    END AS [Head Blocker],
    ISNULL(DB_NAME(r.database_id), '') AS [Database],
    ISNULL(t.task_state, '') AS [Task State],
    ISNULL(r.command, '') AS [Command],
    r.cpu_time AS [CPU Time],
    r.total_elapsed_time AS [Elapsed Time],
    r.wait_time AS [Wait Time],
    r.wait_type AS [Wait Type],
    s.memory_usage * 8 AS [Memory Use (KB)],
    s.host_name AS [Host Name],
    s.program_name AS [Application]
FROM sys.dm_exec_sessions s
LEFT JOIN sys.dm_exec_requests r ON s.session_id = r.session_id
LEFT JOIN sys.dm_exec_requests r2 ON r.session_id = r2.blocking_session_id
LEFT JOIN sys.dm_os_tasks t ON r.session_id = t.session_id
WHERE s.session_id != @@SPID
ORDER BY s.session_id;

5.1.3 Contoh Kueri untuk Statistik Tunggu

Untuk melihat statistik tunggu yang mirip dengan panel Tunggu Sumber Daya:

SELECT TOP 10
    wait_type AS [Wait Type],
    wait_time_ms / 1000.0 AS [Wait Time (sec)],
    waiting_tasks_count AS [Waiting Tasks],
    wait_time_ms / NULLIF(waiting_tasks_count, 0) AS [Avg Wait Time (ms)]
FROM sys.dm_os_wait_stats
WHERE wait_type NOT LIKE '%SLEEP%'
    AND wait_type NOT LIKE '%IDLE%'
    AND wait_type NOT LIKE '%QUEUE%'
ORDER BY wait_time_ms DESC;

5.2 Menggunakan sp_WhoIsActive

sp_WhoIsActive adalah prosedur tersimpan canggih yang dibuat komunitas yang menyediakan informasi lebih terperinci daripada Activity Monitor dalam satu set hasil.

5.2.1 Menginstal sp_WhoIsActive

Untuk menginstal sp_WhoIsActive:

1. Unduh versi terbaru dari http://whoisactive.com.
2. Unduhan tersebut berupa skrip SQL yang berisi definisi prosedur.
3. Buka skrip di SQL Server Studio Manajemen.
4. Sambungkan ke SQL Server contoh.
5. Jalankan skrip untuk membuat prosedur di basis data utama.
6. Berikan izin eksekusi kepada pengguna yang sesuai.

Karena sp_WhoIsActive diinstal di master, ia dapat diakses dari konteks basis data mana pun.

5.2.2 Contoh Penggunaan Dasar

Cara paling sederhana untuk menggunakan sp_WhoIsActive adalah:

EXEC sp_WhoIsActive;

Ini mengembalikan kumpulan hasil yang menunjukkan semua sesi aktif dengan kueri, jenis tunggu, informasi pemblokiran, dan penggunaan sumber daya.

Untuk contoh 10 detik yang menunjukkan aktivitas selama periode tersebut:

EXEC sp_WhoIsActive @delta_interval = 10;

Ini menghitung delta untuk metrik seperti CPU dan pembacaan, menunjukkan apa yang terjadi selama 10 detik tersebut.

5.2.3 Parameter Lanjutan

sp_WhoIsActive mendukung banyak parameter untuk penyesuaian:

• @menyaring: Filter hasil ke sesi, basis data, atau login tertentu.
• @jenis_filter: Tentukan filter yang diterapkan (sesi, basis data, login, dsb.).
• @get_plans: Sertakan rencana eksekusi dalam hasil (atur ke 1).
• @get_locks: Tampilkan informasi kunci terperinci (atur ke 1).
• @dapatkan_info_transaksi: Menampilkan rincian transaksi (diatur ke 1).
• @urutan_urutan: Mengurutkan hasil berdasarkan metrik yang berbeda (CPU, pembacaan, durasi, dll.).
• @tabel_tujuan: Masukkan hasil ke dalam tabel untuk pelacakan historis.

Contoh yang menunjukkan rencana yang diurutkan berdasarkan CPU:

EXEC sp_WhoIsActive 
    @get_plans = 1,
    @sort_order = '[CPU] DESC';

5.3 Menggunakan Prosedur Tersimpan Sistem

SQL Server mencakup prosedur tersimpan tradisional untuk memantau aktivitas, meskipun menyediakan lebih sedikit informasi daripada DMV atau Monitor Aktivitas.

5.3.1 sp_who dan sp_who2

Prosedur sp_who menampilkan informasi sesi dasar:

EXEC sp_who;

Prosedur sp_who2 memberikan sedikit lebih detail:

EXEC sp_who2;

Kedua prosedur tersebut menampilkan ID sesi, nama login, waktu CPU, dan informasi pemblokiran. Namun, keduanya kurang detail dibandingkan dengan DMV atau Activity Monitor. Keduanya paling berguna untuk pengecekan cepat ketika Anda hanya membutuhkan informasi minimal dengan cepat.

5.3.2 Prosedur Sistem Berguna Lainnya

Prosedur sistem tambahan untuk pemantauan meliputi:

• sp_kunci: Menampilkan informasi kunci (tidak berlaku lagi; gunakan sys.dm_tran_locks sebagai gantinya).
• sp_monitor: Menampilkan statistik tentang SQL Server aktivitas.
• sp_bantuan: Menampilkan definisi objek dan metadata.
• DBCC SQLPERF: Menampilkan penggunaan ruang log transaksi dan statistik tunggu.

5.4 Membuat Skrip Pemantauan Kustom

Untuk lingkungan yang memerlukan pemantauan khusus di luar apa yang disediakan Activity Monitor, Anda dapat membangun solusi khusus menggunakan DMV.

5.4.1 Skrip Setara Monitor Aktivitas Lengkap

Berikut adalah skrip komprehensif yang mereplikasi sebagian besar fungsi Activity Monitor:

-- Processes Information
SELECT 
    s.session_id AS [Session ID],
    CONVERT(CHAR(1), s.is_user_process) AS [User Process],
    s.login_name AS [Login],
    ISNULL(CONVERT(VARCHAR, w.blocking_session_id), '') AS [Blocked By],
    CASE 
        WHEN r2.session_id IS NOT NULL 
        AND (r.blocking_session_id = 0 OR r.session_id IS NULL) 
        THEN '1' 
        ELSE '' 
    END AS [Head Blocker],
    ISNULL(DB_NAME(r.database_id), N'') AS [Database],
    ISNULL(t.task_state, N'') AS [Task State],
    ISNULL(r.command, N'') AS [Command],
    SUBSTRING(st.text, (r.statement_start_offset/2) + 1,
        ((CASE r.statement_end_offset 
            WHEN -1 THEN DATALENGTH(st.text)
            ELSE r.statement_end_offset 
        END - r.statement_start_offset) / 2) + 1) AS [Statement],
    st.text AS [Command Text],
    r.cpu_time AS [CPU Time (ms)],
    r.total_elapsed_time / 1000 AS [Elapsed Time (sec)],
    r.wait_time AS [Wait Time (ms)],
    r.wait_type AS [Wait Type],
    r.wait_resource AS [Wait Resource],
    s.memory_usage * 8 AS [Memory Use (KB)],
    s.host_name AS [Host Name],
    c.client_net_address AS [Net Address],
    s.program_name AS [Application]
FROM sys.dm_exec_sessions s
LEFT JOIN sys.dm_exec_requests r ON s.session_id = r.session_id
LEFT JOIN sys.dm_exec_requests w ON r.session_id = w.blocking_session_id
LEFT JOIN sys.dm_exec_requests r2 ON r.session_id = r2.blocking_session_id
LEFT JOIN sys.dm_os_tasks t ON r.session_id = t.session_id 
    AND r.request_id = t.request_id
LEFT JOIN sys.dm_exec_connections c ON s.session_id = c.session_id
OUTER APPLY sys.dm_exec_sql_text(r.sql_handle) st
WHERE s.session_id != @@SPID
ORDER BY s.session_id;

-- Recent Expensive Queries
SELECT TOP 20
    qs.execution_count / 
        DATEDIFF(MINUTE, qs.creation_time, GETDATE()) AS [Executions/min],
    qs.total_worker_time / 1000 AS [CPU Time (ms)],
    qs.total_physical_reads AS [Physical Reads],
    qs.total_logical_writes AS [Logical Writes],
    qs.total_logical_reads AS [Logical Reads],
    qs.total_elapsed_time / qs.execution_count / 1000 AS [Avg Duration (ms)],
    SUBSTRING(st.text, (qs.statement_start_offset/2) + 1,
        ((CASE qs.statement_end_offset 
            WHEN -1 THEN DATALENGTH(st.text)
            ELSE qs.statement_end_offset 
        END - qs.statement_start_offset) / 2) + 1) AS [Query Text]
FROM sys.dm_exec_query_stats qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) st
WHERE qs.execution_count > 0
ORDER BY qs.total_worker_time DESC;

5.4.2 Mengotomatiskan Pemantauan dengan Pekerjaan Agen SQL

Anda dapat menjadwalkan skrip pemantauan khusus menggunakan SQL Server Agen:

1. Buat tabel untuk menyimpan hasil pemantauan.
2. Ubah skrip pemantauan Anda untuk memasukkan hasil ke dalam tabel ini.
3. In SQL Server Studio Manajemen, perluas SQL Server Agen di Object Explorer.
4. Klik kanan Jobs dan pilih Pekerjaan Baru.
5. Konfigurasikan pekerjaan untuk menjalankan skrip pemantauan Anda secara berkala.
6. Siapkan peringatan atau laporan berdasarkan data yang dikumpulkan.

Pendekatan ini memungkinkan pelacakan historis dan analisis tren yang tidak disediakan oleh Activity Monitor.

6. Batasan dan Pertimbangan Monitor Aktivitas

Meskipun Activity Monitor berharga, memahami keterbatasannya membantu Anda menggunakannya dengan tepat dan melengkapinya dengan alat lain bila diperlukan.

6.1 Memahami Overhead Monitor Aktivitas

Activity Monitor tidak gratis—ia menghabiskan sumber daya server untuk mengumpulkan dan menampilkan informasi. Memahami overhead ini membantu Anda menggunakannya secara bertanggung jawab.

6.1.1 Dampak pada Sumber Daya Server

Activity Monitor menjalankan kueri terhadap DMV sistem setiap kali di-refresh. Kueri ini mengonsumsi CPU, menghasilkan pembacaan logis, dan dapat menahan kunci sementara pada tabel sistem. Pada server yang sibuk, overhead ini dapat memengaruhi kinerja.

Panel Proses dan Kueri Mahal Terbaru sangat mahal, karena harus memindai DMV dan tabel cache yang berpotensi besar. Pada server dengan ribuan rencana kueri yang di-cache, penyegaran Kueri Mahal Terbaru dapat memakan waktu beberapa detik.

Dokumentasi Microsoft memperingatkan bahwa interval penyegaran di bawah 10 detik dapat secara nyata memengaruhi kinerja server, terutama pada sistem yang sudah dimuat.

6.1.2 Praktik Terbaik Interval Penyegaran

Pilih interval penyegaran yang sesuai dengan situasi Anda:

• 1-5 detik: Hanya untuk pemecahan masalah kritis secara langsung pada server dengan beban ringan. Jangan biarkan Monitor Aktivitas berjalan pada interval ini.
• 10 detik (default): Cukup memadai untuk sebagian besar skenario pemecahan masalah dan pemantauan umum.
• 30-60 detik: Pilihan yang lebih baik untuk server produksi dengan beban berat atau saat melakukan pemantauan dalam jangka waktu lama.
• Hanya penyegaran manual: Untuk situasi di mana Anda ingin memeriksa status terkini secara berkala tanpa pemungutan suara berkelanjutan.

Selalu tutup Activity Monitor setelah selesai menyelidiki. Jangan biarkan terus berjalan, terutama jika terdapat beberapa instance dari pengguna yang berbeda.

6.2 Masalah Pengelompokan Jenis Tunggu

Pendekatan Activity Monitor dalam mengkategorikan waktu tunggu, meskipun menyederhanakan tampilan, dapat mengaburkan informasi diagnostik penting.

6.2.1 Bagaimana Monitor Aktivitas Mengelompokkan Menunggu

SQL Server Melacak ratusan jenis tunggu yang berbeda, masing-masing menunjukkan sumber daya atau kondisi tertentu. Activity Monitor mengelompokkannya ke dalam kategori umum seperti "Buffer Latch", "Lock", dan "Memory".

Misalnya, kategori "Buffer Latch" mencakup PAGELATCH_SH, PAGELATCH_UP, PAGELATCH_EX, dan beberapa jenis tunggu spesifik lainnya. Meskipun semuanya terkait dengan akses halaman, masing-masing memiliki penyebab dan solusi yang berbeda.

Microsoft tidak mendokumentasikan secara pasti jenis tunggu mana yang dipetakan ke kategori mana, sehingga sulit memahami apa yang sebenarnya Anda lihat.

6.2.2 Jenis Tunggu yang Hilang

Activity Monitor tidak menampilkan semua jenis penantian. Terutama, seringkali Activity Monitor mengabaikan penantian CXPACKET, yang menunjukkan eksekusi kueri paralel. Penantian CXPACKET umum terjadi dan biasanya tidak menimbulkan masalah, tetapi mengetahui keberadaannya membantu Anda memahami karakteristik beban kerja.

Bila Activity Monitor menunjukkan “Buffer Latch” sebagai waktu tunggu teratas Anda, tetapi alat lain menunjukkan CXPACKET mendominasi, perbedaan tersebut berasal dari logika pemfilteran dan pengelompokan Activity Monitor.

6.2.3 Mengapa Jenis Tunggu Tertentu Penting

Mengetahui jenis tunggu yang spesifik penting untuk pemecahan masalah:

• PAGELATCH_EX: Sering menunjukkan pertentangan tempdb pada halaman alokasi. Solusinya adalah menambahkan lebih banyak berkas data tempdb.
• PAGELATCH_SH: Mungkin mengindikasikan halaman aktif di tabel pengguna. Solusinya melibatkan partisi atau reorganisasi indeks.
• PAGELATCH_UP: Umum terjadi selama pembaruan. Mungkin menunjukkan operasi normal, bukan masalah.

Activity Monitor mengelompokkan semua ini di bawah "Buffer Latch", sehingga menyulitkan diagnosis. Alat seperti sp_WhoIsActive dan kueri DMV menampilkan jenis tunggu tertentu.

6.3 Akurasi dan Ketepatan Waktu Data

Activity Monitor memberikan tampilan yang mendekati waktu nyata, tetapi "hampir" adalah kata kuncinya. Memahami metode pengumpulan datanya membantu Anda menginterpretasikan hasil dengan tepat.

6.3.1 Snapshot vs Pemantauan Berkelanjutan

Monitor Aktivitas menampilkan snapshot titik waktu yang diambil pada setiap interval penyegaran. Peristiwa yang terjadi di antara snapshot tidak direkam. Jika kueri berjalan selama 2 detik dan Anda menyegarkannya setiap 10 detik, Anda mungkin melihatnya sekali atau tidak sama sekali, tergantung waktunya.

Artinya Activity Monitor unggul dalam menemukan masalah yang terus-menerus (pemblokiran menit yang berlangsung lama, CPU yang tinggi secara konsisten) tetapi mungkin melewatkan masalah yang sementara (kebuntuan singkat, lonjakan kueri yang kadang-kadang).

6.3.2 Agregasi dan Pengambilan Sampel

Panel Kueri Mahal Terbaru menampilkan data yang dikumpulkan sejak paket kueri dimasukkan ke cache. Dua kueri identik dengan nilai parameter berbeda akan muncul sebagai satu baris jika keduanya berbagi paket. Agregasi ini dapat menutupi masalah dengan kombinasi parameter tertentu (masalah pengendus parameter).

Panel Resource Waits menghitung tingkat dengan membandingkan snapshot. Jika statistik tunggu direset antara snapshot (jarang terjadi tetapi mungkin), tingkat yang dihitung mungkin tidak akurat.

6.4 Kapan TIDAK Menggunakan Monitor Aktivitas

Activity Monitor tidak cocok untuk setiap skenario pemantauan. Kenali kapan alat alternatif merupakan pilihan yang lebih baik.

6.4.1 Persyaratan Analisis Historis

Activity Monitor hanya menampilkan aktivitas terkini. Activity Monitor tidak menyimpan data historis. Jika Anda perlu menganalisis tren selama beberapa hari atau minggu, membandingkan performa saat ini dengan baseline, atau membuat laporan tentang pola performa, Activity Monitor tidaklah memadai.

Untuk analisis historis, gunakan SQL ServerDashboard Kinerja bawaan, Extended Events dengan target file, atau solusi pemantauan pihak ketiga.

6.4.2 Statistik Tunggu Terperinci Kebutuhan

Saat Anda membutuhkan informasi jenis tunggu yang tepat untuk penyetelan lanjutan, pengelompokan dan pemfilteran Activity Monitor membuatnya tidak memadai. Gunakan kueri DMV secara langsung atau sp_WhoIsActive sebagai gantinya.

Untuk analisis statistik penantian yang komprehensif, tanyakan sys.dm_os_wait_stats secara langsung dan saring penantian yang tidak berbahaya secara manual.

6.4.3 Pertimbangan Server Produksi

Pada server produksi dengan beban berat, overhead Activity Monitor bisa menjadi masalah. Beberapa administrator basis data sebaiknya tidak menjalankan Activity Monitor secara bersamaan di server yang sama.

Untuk pemantauan produksi, pertimbangkan alternatif ringan seperti snapshot DMV terjadwal yang disimpan dalam basis data pemantauan, atau gunakan perutean Hanya-Baca untuk memantau replika sekunder dalam konfigurasi Selalu Aktif.

7. Praktik Terbaik untuk Menggunakan Monitor Aktivitas

Mengikuti praktik terbaik memastikan Anda memperoleh nilai maksimal dari Activity Monitor sambil meminimalkan dampak negatif pada server Anda.

7.1 Kapan Menggunakan Monitor Aktivitas

Activity Monitor sangat efektif dalam skenario tertentu. Gunakan ketika keunggulannya sesuai dengan kebutuhan Anda.

7.1.1 Masalah Kinerja Waktu Nyata

Monitor Aktivitas ideal ketika pengguna sedang mengalami masalah dan Anda perlu segera mendiagnosis masalahnya. Tampilan real-time membantu Anda melihat apa yang sedang terjadi.

Ketika Anda menerima pesan "aplikasi lambat", membuka Activity Monitor seharusnya menjadi salah satu langkah pertama Anda. Anda dapat dengan cepat menentukan apakah basis data sedang sibuk, terblokir, atau tidak aktif.

7.1.2 Investigasi Perlambatan Aplikasi

Ketika suatu aplikasi tertentu menjadi tidak responsif, Activity Monitor membantu Anda menentukan apakah masalah basis data merupakan penyebabnya. Filter panel Proses berdasarkan nama aplikasi untuk melihat aktivitas basis data aplikasi tersebut saja.

Jika aplikasi tidak menunjukkan aktivitas basis data saat pengguna melaporkan masalah, masalahnya ada di tempat lain dalam tumpukan. Jika Anda melihat pemblokiran yang ekstensif atau kueri yang mahal, Anda telah menemukan penyebabnya.

7.1.3 Pemeriksaan Kesehatan Cepat

Activity Monitor menyediakan dasbor yang sangat baik untuk pemeriksaan kesehatan cepat selama administrasi rutin. Buka, lihat grafik Ikhtisar, dan pastikan tidak ada yang tampak abnormal.

Pemeriksaan sepintas ini hanya membutuhkan beberapa detik dan dapat mengungkap masalah sebelum menjadi kritis. Jadikan ini bagian dari rutinitas harian Anda.

7.2 Pengaturan Konfigurasi Optimal

Mengonfigurasi Activity Monitor dengan tepat akan meningkatkan kegunaannya dan jejak sumber dayanya.

7.2.1 Interval Penyegaran yang Direkomendasikan

Sesuaikan interval penyegaran dengan tujuan Anda:

• Pemecahan masalah aktif: 10 detik memberikan respons yang baik dengan overhead yang wajar.
• Pemantauan yang diperluas: 30-60 detik mengurangi dampak server selama periode observasi yang lebih lama.
• Diagnosis masalah kritis: 5 detik memberikan ketelitian tinggi saat setiap detik berharga, tetapi gunakan secara singkat.
• Pemeriksaan kesehatan rutin: Penyegaran manual (interval 1 jam) saat Anda tidak sedang menonton secara aktif.

Jangan lupa menutup Activity Monitor setelah selesai. Mengaturnya ke interval yang panjang dan melupakannya akan membuang-buang sumber daya server.

7.2.2 Strategi Penyaringan

Gunakan filter untuk fokus pada informasi yang relevan dan mengurangi beban kognitif:

• Filter Proses berdasarkan Basis Data untuk melihat hanya aktivitas terhadap basis data tertentu.
• Saring berdasarkan Masuk untuk melacak aktivitas pengguna tertentu.
• Saring berdasarkan Status Tugas = BERJALAN untuk menyembunyikan sesi yang tidak aktif.
• Saring berdasarkan Aplikasi untuk mengisolasi lalu lintas dari program tertentu.
• Tampilkan hanya NonBlanks di Diblokir Oleh untuk melihat situasi pemblokiran saja.

7.2.3 Pemilihan dan Pengurutan Kolom

Kembangkan pendekatan sistematis untuk meninjau data Monitor Aktivitas:

1. Mulailah dengan Gambaran Umum: Periksa grafik untuk melihat lonjakan atau anomali yang nyata.
2. Periksa Proses untuk pemblokiran: Urutkan berdasarkan ID Sesi, lalu cari nilai Diblokir Oleh.
3. Tinjauan Sumber Daya Menunggu: Urutkan berdasarkan Waktu Tunggu Kumulatif untuk mengidentifikasi hambatan sumber daya.
4. Menganalisis Kueri yang Mahal: Urutkan berdasarkan metrik yang berbeda (CPU, eksekusi, pembacaan) untuk menemukan berbagai jenis masalah.
5. Verifikasi dengan Panel I/O: Konfirmasikan apakah kueri intensif I/O berkorelasi dengan aktivitas disk yang tinggi.

7.3 Integrasi dengan Alat Lain

Activity Monitor berfungsi paling baik sebagai bagian dari perangkat yang lebih luas daripada sebagai solusi mandiri.

7.3.1 Menggunakan dengan SQL Server Profil

Monitor Aktivitas dan SQL Server Profiler saling melengkapi dengan baik. Saat Anda mengidentifikasi sesi yang bermasalah di Activity Monitor, klik kanan dan pilih Jejak Proses di SQL Server Profil.

Ini akan meluncurkan Profiler dengan filter yang sudah dikonfigurasi untuk hanya merekam aktivitas sesi tersebut. Anda akan melihat rangkaian lengkap pernyataan yang dieksekusi, informasi waktu, dan pesan kesalahan—detail yang tidak disediakan oleh Activity Monitor.

Untuk mempelajari lebih lanjut tentang SQL Server Kemampuan profiler dan teknik penelusuran tingkat lanjut, lihat luas SQL Server Panduan profiler.

7.3.2 Melengkapi dengan Acara yang Diperpanjang

Extended Events menawarkan pemantauan detail dengan overhead rendah yang menangkap informasi yang terlewatkan oleh Activity Monitor. Buat sesi Extended Events untuk melacak peristiwa spesifik seperti deadlock, kueri yang berjalan lama, atau kompilasi ulang yang berlebihan.

Gunakan Activity Monitor untuk investigasi langsung dan Extended Events untuk pemantauan berkelanjutan dan analisis historis. Kedua alat ini memenuhi kebutuhan yang berbeda.

Untuk mempelajari lebih lanjut tentang SQL Server Kemampuan Acara yang Diperluas dan teknik pemantauan tingkat lanjut, lihat luas SQL Server Panduan Acara yang Diperpanjang.

7.3.3 Solusi Pemantauan Pihak Ketiga

Perangkat lunak komersial seperti SolarWinds Database Performance Analyzer, Redgate SQL Monitor, dan Quest Spotlight menyediakan fitur-fitur yang tidak dimiliki Activity Monitor: peringatan, tren historis, perencanaan kapasitas, dan diagnostik otomatis.

Alat-alat ini merupakan tambahan yang berharga bagi Activity Monitor, bukan pengganti. Activity Monitor tetap berguna untuk pemeriksaan dan investigasi cepat, bahkan ketika alat pemantauan canggih tersedia.

7.4 Kesalahan Umum yang Harus Dihindari

Memahami kesalahan umum pada Activity Monitor membantu Anda menggunakannya secara lebih efektif.

7.4.1 Membiarkan Monitor Aktivitas Berjalan Terus Menerus

Kesalahan yang paling umum adalah membuka Activity Monitor dan membiarkannya berjalan tanpa batas waktu. Hal ini membuang sumber daya server dan memberikan sedikit nilai karena Anda tidak secara aktif memantau aktivitasnya.

Tutup Activity Monitor saat tidak digunakan secara aktif. Jika Anda membutuhkan pemantauan berkelanjutan, terapkan solusi pemantauan yang tepat dengan pengumpulan data terjadwal.

7.4.2 Terlalu Bergantung pada Monitor Aktivitas Saja

Activity Monitor memberikan satu perspektif tentang kesehatan server. Jangan hanya mengandalkannya. Lengkapi dengan Windows Performance Monitor untuk metrik tingkat OS, Extended Events untuk pelacakan detail, dan analisis rencana eksekusi untuk penyetelan kueri.

Activity Monitor membantu Anda mengidentifikasi masalah, tetapi menyelesaikannya sering kali memerlukan alat tambahan dan analisis yang lebih mendalam.

Pelajari lebih lanjut tentang SQL Server monitor kinerja di kami panduan lengkap.

7.4.3 Mengabaikan Tren Historis

Monitor Aktivitas menunjukkan status terkini, tetapi masalah kinerja seringkali memiliki pola yang hanya terlihat seiring waktu. Terapkan pengumpulan data historis agar Anda dapat membandingkan metrik terkini dengan data dasar dan mengidentifikasi tren.

Tanpa konteks historis, Anda mungkin tidak menyadari bahwa penggunaan CPU "normal" saat ini 30% lebih tinggi daripada dasar bulan lalu, yang menunjukkan penurunan bertahap.

8. Pemecahan Masalah Monitor Aktivitas

Monitor Aktivitas sendiri terkadang mengalami masalah. Mengetahui cara mengatasi masalah ini akan mencegah frustrasi.

8.1 Monitor Aktivitas Tidak Terbuka atau Tidak Menampilkan Data

Bila Activity Monitor terbuka tetapi menampilkan panel kosong atau tidak terbuka sama sekali, mungkin ada beberapa faktor yang menjadi penyebabnya.

8.1.1 Masalah Izin

Penyebab paling umum dari masalah Activity Monitor adalah kurangnya izin. Untuk memverifikasi dan mengatasinya:

1. Periksa izin tingkat server Anda:

   SELECT * FROM fn_my_permissions(NULL, 'SERVER')
   WHERE permission_name = 'VIEW SERVER STATE';
   

2. Jika tidak ada baris yang dikembalikan, Anda tidak memiliki izin VIEW SERVER STATE.
3. Minta administrator server untuk memberikannya:

   USE master;
   GRANT VIEW SERVER STATE TO [YourLogin];
   

4. Tutup dan buka kembali Activity Monitor setelah izin diberikan.

Masalah Kompatibilitas Versi 8.1.2

Menggunakan versi lama SQL Server Studio Manajemen untuk terhubung ke yang lebih baru SQL Server Versi ini dapat menyebabkan kegagalan Monitor Aktivitas. Alat ini mungkin tidak memahami jenis tunggu baru atau kolom tampilan sistem.

Selalu gunakan versi SSMS yang cocok atau lebih baru dari versi Anda SQL Server versi. Microsoft menyediakan SSMS terbaru sebagai unduhan gratis terpisah dari SQL Server itu sendiri.

8.1.3 Masalah Firewall dan Jaringan

Monitor Aktivitas memerlukan konektivitas ke SQL Server Misalnya pada port standar (1433 secara default). Jika Anda dapat terhubung melalui Object Explorer tetapi Activity Monitor gagal, aturan firewall mungkin memblokir koneksi tertentu.

Verifikasi bahwa klien Anda dapat mencapai SQL Server mesin di semua port yang diperlukan. Periksa Windows Firewall dan firewall jaringan apa pun antara klien dan server Anda.

8.2 Monitor Aktivitas Dijeda Secara Permanen

Masalah yang umum, terutama di SQL Server 2019, Activity Monitor terbuka dalam keadaan terhenti sementara dan menolak untuk dilanjutkan.

8.2.1 Memahami Keadaan Terjeda

Saat Monitor Aktivitas dijeda, semua panel menampilkan status "Dijeda" dengan tombol lanjutkan yang mungkin tidak berfungsi. Ini mencegah Anda melihat aktivitas server apa pun.

Status jeda biasanya terjadi karena masalah izin, pembatasan koneksi jarak jauh, atau bug versi SSMS, bukan karena tindakan jeda yang disengaja.

8.2.2 Penyebab Umum

Monitor Aktivitas dapat memasuki status jeda permanen karena:

• Izin VIEW SERVER STATE yang hilang pada panel yang lebih baru ditambahkan baru-baru ini SQL Server Versi
• Koneksi jarak jauh dinonaktifkan pada SQL Server contoh
• Kegagalan autentikasi untuk kueri sistem tertentu
• Bug pada versi SSMS tertentu, khususnya 18.0 hingga 18.3
• Masalah konektivitas antara klien dan server

8.2.3 Langkah Resolusi

Untuk mengatasi masalah status jeda Monitor Aktivitas:

1. Perbarui SSMS: Unduh dan pasang yang terbaru SQL Server Versi Management Studio dari situs web Microsoft. Banyak bug status jeda telah diperbaiki di rilis selanjutnya.
2. Verifikasi izin: Pastikan Anda memiliki izin VIEW SERVER STATE dan VIEW ANY DEFINITION.
3. Periksa koneksi jarak jauh: Verifikasi bahwa SQL Server instance memperbolehkan koneksi jarak jauh:

   EXEC sp_configure 'remote access';
   

   Jika nilainya 0, mintalah administrator untuk mengaktifkannya.

4. Mulai ulang SSMS: Terkadang cukup dengan menutup semua jendela dan memulai ulang SQL Server Management Studio menyelesaikan masalah tersebut.
5. Hubungkan dengan Autentikasi Windows: Jika menggunakan autentikasi SQL, cobalah autentikasi Windows, karena terkadang autentikasi ini dapat melewati masalah jeda terkait autentikasi.

8.3 Masalah Performa Saat Menggunakan Activity Monitor

Jika Activity Monitor sendiri menjadi lambat atau menyebabkan penurunan kinerja server, penyesuaian diperlukan.

8.3.1 Mengurangi Overhead Pemantauan

Untuk meminimalkan dampak Activity Monitor:

1. Tingkatkan interval penyegaran menjadi 30 detik atau 1 menit.
2. Tutup panel yang tidak sedang Anda gunakan secara aktif dengan mengklik tombol ciutkan.
3. Saat panel diciutkan, Activity Monitor tidak meminta data untuk panel tersebut.
4. Hindari menjalankan beberapa instance Activity Monitor secara bersamaan.
5. Tutup Activity Monitor sepenuhnya saat tidak sedang aktif menyelidiki masalah.

8.3.2 Metode Pemantauan Ringan Alternatif

Jika Activity Monitor terlalu membutuhkan banyak sumber daya untuk lingkungan Anda, pertimbangkan alternatif berikut:

• Tanyakan langsung ke DMV: Tulis kueri T-SQL spesifik yang hanya mengambil informasi yang Anda perlukan.
• Gunakan sp_WhoIsActive: Prosedur tersimpan ini sangat optimal dan biasanya memiliki overhead yang lebih rendah daripada Activity Monitor.
• Terapkan pengambilan sampel: Jadwalkan pekerjaan Agen SQL yang menangkap cuplikan data DMV secara berkala, menyimpan hasil dalam tabel untuk analisis selanjutnya.
• Pantau replika sekunder: In Grup ketersediaan Selalu Aktif, jalankan Activity Monitor terhadap server sekunder yang dapat dibaca, bukan server utama.

8.4 Informasi yang Tidak Akurat atau Hilang

Terkadang Activity Monitor menampilkan informasi yang tampaknya salah atau tidak lengkap.

8.4.1 Verifikasi Data dengan DMV

Jika hasil Monitor Aktivitas tampak mencurigakan, verifikasi dengan menanyakan langsung ke DMV yang mendasarinya. Misalnya, jika panel Proses tidak menunjukkan pemblokiran tetapi pengguna melaporkannya, tanyakan:

SELECT 
    blocking_session_id,
    session_id,
    wait_type,
    wait_time,
    wait_resource
FROM sys.dm_exec_requests
WHERE blocking_session_id != 0;

Jika kueri ini menunjukkan pemblokiran yang terlewatkan oleh Activity Monitor, Anda telah mengonfirmasi adanya masalah tampilan.

8.4.2 Memahami Waktu Penyegaran Data

Ingat bahwa Activity Monitor menampilkan snapshot. Kueri yang dijalankan di antara interval penyegaran tidak akan muncul di Kueri Mahal Terbaru kecuali rencana eksekusinya tetap berada dalam cache.

Demikian pula, statistik tunggu di panel Tunggu Sumber Daya mencerminkan akumulasi sejak snapshot terakhir. Beban kerja yang berubah dengan cepat dapat menunjukkan pola yang berbeda setiap kali diperbarui.

9. Teknik Pemantau Aktivitas Lanjutan

Administrator basis data berpengalaman menggunakan Activity Monitor dengan cara yang canggih untuk mendapatkan nilai diagnostik maksimal.

9.1 Menggabungkan Beberapa Panel untuk Analisis Akar Penyebab

Kekuatan sesungguhnya dari Activity Monitor muncul saat Anda menghubungkan informasi di beberapa panel untuk memahami masalah kinerja yang kompleks.

9.1.1 Mengkorelasikan Penantian dengan Proses

Saat panel Waktu Tunggu Sumber Daya menunjukkan waktu tunggu yang tinggi dalam suatu kategori, gunakan panel Proses untuk mengidentifikasi sesi mana yang mengalami waktu tunggu tersebut:

1. Perhatikan kategori tunggu dengan waktu tunggu kumulatif yang tinggi (misalnya, “Kunci”).
2. Beralih ke panel Proses.
3. Sortir dengan Tipe Tunggu untuk mengelompokkan sesi berdasarkan waktu tunggu saat ini.
4. Cari sesi yang menunjukkan jenis menunggu dalam kategori bermasalah.
5. Untuk sesi tersebut, periksa Tunggu Sumber Daya kolom untuk melihat objek basis data mana yang terlibat.
6. Klik kanan dan pilih Detail untuk melihat teks kueri.

Korelasi ini membantu Anda berpindah dari "kami memiliki waktu tunggu kunci" ke "kueri spesifik ini sedang menunggu kunci pada tabel ini."

9.1.2 Menghubungkan Query Mahal dengan Masalah I/O

Ketika panel I/O File Data menunjukkan aktivitas disk yang tinggi pada database tertentu:

1. Perhatikan file basis data mana yang memiliki kecepatan baca atau tulis MB/detik yang tinggi.
2. Beralih ke Kueri Mahal Terkini.
3. Sortir dengan Pembacaan Fisik/detik untuk mengidentifikasi kueri yang membaca banyak data dari disk.
4. Filter atau identifikasi visual kueri yang berjalan pada basis data dengan I/O tinggi.
5. Periksa rencana eksekusi kueri tersebut untuk pemindaian tabel atau indeks yang hilang yang menyebabkan I/O berlebihan.

Analisis multi-panel ini menghubungkan gejala (I/O disk yang tinggi) dengan penyebab (kueri tidak efisien tertentu).

9.2 Menggunakan Monitor Aktivitas untuk Perencanaan Kapasitas

Meskipun Activity Monitor tidak menyimpan data historis, Anda dapat menggunakannya secara strategis untuk observasi perencanaan kapasitas.

9.2.1 Mengidentifikasi Pola Penggunaan Puncak

Pantau aktivitas server pada waktu yang berbeda dalam sehari untuk mengidentifikasi pola penggunaan:

1. Buka Monitor Aktivitas selama jam sibuk bisnis yang diketahui.
2. Perhatikan nilai puncak grafik % Waktu Prosesor.
3. Catat jumlah Tugas Menunggu maksimum.
4. Amati Permintaan Batch/detik pada waktu puncak.
5. Dokumentasikan basis data yang paling sibuk di panel Proses.
6. Ulangi pada jam-jam di luar jam sibuk untuk perbandingan.

Jika waktu prosesor pada jam sibuk secara konsisten melebihi 80%, Anda mendekati batas kapasitas CPU. Demikian pula, peningkatan jumlah tunggu menunjukkan meningkatnya perebutan sumber daya.

9.2.2 Analisis Tren Sumber Daya

Sementara Activity Monitor menunjukkan status terkini, Anda dapat menggunakannya untuk memeriksa tren secara acak dengan merekam metrik utama dari waktu ke waktu:

• Ambil tangkapan layar panel Ikhtisar pada waktu yang sama setiap hari
• Catat nilai puncak dari setiap grafik
• Bandingkan minggu ke minggu untuk mengidentifikasi tren pertumbuhan
• Perhatikan peningkatan bertahap dalam waktu prosesor rata-rata atau kecepatan I/O

Tren manual ini melengkapi solusi pemantauan yang lebih canggih dan membantu membenarkan perluasan kapasitas.

9.3 Mendokumentasikan Baseline Kinerja

Menetapkan metrik kinerja dasar membantu Anda mengenali saat kinerja menurun.

9.3.1 Menangkap Metrik Dasar

Selama periode kinerja yang diketahui baik, dokumentasikan metrik Monitor Aktivitas:

1. Buka Monitor Aktivitas selama operasi bisnis normal (bukan pada jam sibuk atau di luar jam sibuk).
2. Nilai panel Ikhtisar Rekaman:
   • Rentang Waktu Prosesor % Khas
   • Jumlah Tugas Menunggu Rata-rata
   • Kecepatan I/O Basis Data Normal
   • Permintaan Batch Umum/detik
3. Perhatikan kategori pada panel Waktu Tunggu Sumber Daya yang menunjukkan waktu tunggu terlama.
4. Dokumentasikan jumlah proses aktif biasanya di panel Proses.
5. Merekam metrik eksekusi kueri representatif dari Kueri Mahal Terkini.

Simpan dokumentasi dasar ini untuk referensi di masa mendatang saat menyelidiki masalah kinerja.

9.3.2 Membandingkan Kinerja Saat Ini vs. Kinerja Dasar

Jika masalah kinerja muncul, bandingkan pembacaan Activity Monitor saat ini dengan garis dasar yang terdokumentasi:

• Apakah waktu prosesor jauh lebih tinggi daripada waktu standar? Fokus pada kueri yang membutuhkan CPU intensif.
• Apakah tugas yang menunggu 2-3 kali lebih tinggi dari level dasar? Selidiki waktu tunggu sumber daya.
• Apakah I/O jauh lebih tinggi? Periksa panel I/O File Data dan kueri mahal.
• Apakah permintaan batch lebih rendah dari permintaan dasar selama jam sibuk? Cari masalah pemblokiran atau konektivitas.

Perbandingan ini membantu Anda mengidentifikasi apa yang berubah dan memfokuskan upaya pemecahan masalah dengan tepat.

9.4 Membuat Alur Kerja Pemantauan Kustom

Mengembangkan alur kerja sistematis untuk skenario investigasi umum guna memastikan analisis menyeluruh dan dapat diulang.

9.4.1 Proses Investigasi Langkah demi Langkah

Saat pengguna melaporkan masalah kinerja, ikuti alur kerja yang konsisten:

1. Pemeriksaan kesehatan cepat: Buka Monitor Aktivitas dan pindai grafik panel Ikhtisar untuk mencari anomali yang jelas.
2. Periksa pemblokiran: Perluas panel Proses, saring NonKosong di kolom Diblokir Oleh.
3. Identifikasi perebutan sumber daya: Panel Tinjauan Sumber Daya Tunggu diurutkan berdasarkan waktu tunggu.
4. Temukan kueri yang mahal: Periksa Query Mahal Terkini yang diurutkan berdasarkan CPU, lalu eksekusi, lalu pembacaan.
5. Korelasikan pola I/O: Referensi silang kueri mahal dengan aktivitas panel I/O Berkas Data.
6. Temuan dokumen: Ambil tangkapan layar dan rekam ID sesi yang relevan, jenis tunggu, dan detail pertanyaan.
7. Menyelam dalam: Gunakan jejak Profiler, analisis rencana eksekusi, dan kueri DMV untuk investigasi terperinci terhadap masalah yang teridentifikasi.

9.4.2 Kriteria Eskalasi

Tetapkan kriteria kapan harus meningkatkan masalah dibandingkan melanjutkan penyelidikan:

• Segera tingkatkan: Rantai pemblokiran berlangsung >5 menit, waktu prosesor pada 100% selama >2 menit, proses sistem kritis menunjukkan status DITANGGUHKAN.
• Meningkat dengan analisis: Kueri mahal yang berulang kali mengonsumsi >50% CPU, waktu respons I/O tinggi yang konsisten >50 ms, pemberian memori gagal berulang kali.
• Selidiki lebih lanjut: Penundaan sementara teratasi dalam hitungan menit, kueri dengan rencana yang kurang optimal tetapi kinerja yang dapat diterima, pemblokiran kecil dengan durasi <30 detik.

10. Monitor Aktivitas di Berbagai SQL Server versi

Activity Monitor telah berkembang di seluruh SQL Server versi, dengan tiap rilis membawa penyempurnaan dan terkadang masalah baru.

10.1 Monitor Aktivitas di SQL Server 2008 dan Selanjutnya

SQL Server Tahun 2008 memperkenalkan desain Monitor Aktivitas modern yang sebagian besar tidak berubah hingga saat ini.

10.1.1 Fitur Baru Diperkenalkan di SQL Server 2008

The SQL Server Desain ulang Activity Monitor 2008 membawa perbaikan signifikan:

• Dasbor grafis dengan grafik waktu nyata di panel Ikhtisar
• Antarmuka panel yang dapat diperluas/dilipat menggantikan tampilan kisi lama
• Panel Kueri Mahal Terbaru yang menampilkan data kinerja kueri agregat
• Panel I/O File Data untuk pemantauan aktivitas disk per file
• Panel Tunggu Sumber Daya yang Disempurnakan dengan kategorisasi tunggu
• Menu konteks klik kanan untuk tindakan proses seperti menghentikan sesi dan meluncurkan Profiler
• Interval penyegaran yang dapat dikonfigurasi dari 1 detik hingga 1 jam

Perubahan ini mengubah Activity Monitor dari daftar proses sederhana menjadi dasbor pemantauan yang komprehensif.

10.1.2 Perubahan dari SQL Server 2005

SQL Server Activity Monitor tahun 2005 jauh lebih terbatas:

• Diakses melalui folder Manajemen di Object Explorer daripada toolbar
• Kotak tunggal yang menunjukkan daftar proses dengan informasi dasar
• Tidak ada grafik grafis atau beberapa panel
• Tidak ada kueri mahal atau pemantauan I/O
• Informasi statistik tunggu terbatas

Desain ulang pada tahun 2008 merupakan pencitraan ulang yang lengkap dan bukan perbaikan bertahap.

10.2 Monitor Aktivitas di SQL Server 2014/2016

SQL Server Tahun 2014 dan 2016 membuat perbaikan bertahap pada pengumpulan data dasar Activity Monitor tetapi sedikit perubahan visual.

10.2.1 Perbaikan dan Peningkatan

Peningkatan utama dalam versi ini meliputi:

• Performa yang lebih baik saat memantau server dengan ribuan rencana yang di-cache
• Kemampuan penyaringan yang ditingkatkan di panel Proses
• Peningkatan akurasi agregasi statistik tunggu
• Penanganan penyortiran dan pemfilteran kolom yang lebih baik dengan set hasil yang besar
• Kueri DMV yang lebih efisien mengurangi beban pemantauan

Antarmuka inti tetap konsisten dengan SQL Server 2008, mempertahankan keakraban bagi administrator.

10.3 Monitor Aktivitas di SQL Server 2019/2022

Baru SQL Server Versi terbaru melanjutkan evolusi Activity Monitor dengan fokus pada kinerja dan stabilitas.

10.3.1 Fitur dan Kemampuan Terbaru

SQL Server Monitor Aktivitas 2019 dan 2022 meliputi:

• Dukungan untuk jenis tunggu baru yang diperkenalkan dalam versi ini
• Peningkatan kinerja rendering di SSMS menggunakan teknologi WPF
• Penanganan sejumlah besar sesi aktif dengan lebih baik
• Kompatibilitas yang ditingkatkan dengan platform SQL cloud
• Metrik CPU dan I/O yang lebih akurat

10.3.2 Masalah yang Diketahui dalam Versi Terbaru

SQL Server Tahun 2019 memperkenalkan beberapa bug Activity Monitor:

• Status Jeda Permanen: Monitor Aktivitas sering kali memasuki status jeda dan tidak dapat dilanjutkan, terutama di SSMS 18.0-18.3. Telah diperbaiki di versi SSMS selanjutnya.
• Kegagalan Koneksi Jarak Jauh: Beberapa konfigurasi mencegah Activity Monitor terbuka pada instans jarak jauh. Solusinya termasuk mengaktifkan tanda pelacakan tertentu atau menggunakan versi SSMS yang lebih baru.
• Masalah Izin: Tampilan sistem baru memerlukan izin tambahan yang tidak didokumentasikan dengan jelas, menyebabkan tampilan kosong bahkan dengan VIEW SERVER STATE.

Selalu gunakan versi SSMS terbaru saat bekerja dengan SQL Server 2019 dan 2022 untuk menghindari masalah ini.

11. Kasus Penggunaan Praktis dan Contoh

Contoh dunia nyata menunjukkan cara menerapkan Activity Monitor secara efektif dalam skenario pemecahan masalah umum.

11.1 Studi Kasus: Mendiagnosis Aplikasi Web yang Lambat

Sebuah tim pengembangan melaporkan bahwa aplikasi web mereka menjadi sangat lambat, dengan waktu pemuatan halaman 20-30 detik, bukan 2-3 detik seperti biasanya.

11.1.1 Investigasi Awal dengan Panel Ikhtisar

Buka Activity Monitor dan periksa panel Overview:

1. Grafik % Waktu Prosesor memperlihatkan penggunaan CPU sebesar 85-95%, jauh lebih tinggi dari dasar normal sebesar 30-40%.
2. Tugas Menunggu berfluktuasi antara 10-20 tugas, dibandingkan dengan garis dasar normal 0-3.
3. I/O basis data menunjukkan aktivitas sedang sekitar 50 MB/s.
4. Permintaan Batch/detik lebih rendah dari yang diharapkan yaitu 100/detik, dibandingkan dengan 300-400/detik pada jam kerja.

Pola ini menunjukkan adanya bottleneck CPU dengan perebutan sumber daya yang menyebabkan penurunan throughput. Server bekerja keras tetapi tidak memproses banyak permintaan.

11.1.2 Mengidentifikasi Pertanyaan yang Bermasalah

Perluas panel Kueri Mahal Terkini dan urutkan berdasarkan Eksekusi/menit:

1. Kueri teratas menunjukkan 15,000 eksekusi per menit.
2. Klik kanan dan pilih Edit Teks Kueri untuk memeriksa kueri.
3. Kueri tersebut merupakan pernyataan SELECT sederhana yang mengambil satu rekaman pengguna: SELECT * FROM Users WHERE UserId = @UserId.
4. Kueri ini tidak boleh dijalankan 15,000 kali per menit untuk penggunaan aplikasi normal.

Klik kanan kueri dan pilih Tampilkan Rencana EksekusiRencana tersebut menampilkan pemindaian tabel pada tabel Pengguna dengan peringatan tentang indeks yang hilang pada kolom ID Pengguna.

Filter panel Proses berdasarkan Aplikasi untuk hanya menampilkan koneksi aplikasi web. Beberapa sesi akan menampilkan kueri yang sama yang berjalan berulang kali.

11.1.3 Resolusi dan Verifikasi

Masalah ini bermula dari dua hal: eksekusi kueri yang berlebihan dan indeks yang hilang. Langkah-langkah penyelesaian:

1. Buat indeks yang hilang:

   CREATE NONCLUSTERED INDEX IX_Users_UserId 
   ON Users (UserId);
   

2. Hubungi tim pengembangan tentang eksekusi yang berlebihan. Investigasi mengungkap masalah kueri N+1 dalam kode aplikasi di mana sebuah loop mengambil detail pengguna untuk setiap item dalam daftar.
3. Ubah aplikasi untuk mengelompokkan pencarian pengguna menjadi satu kueri menggunakan klausa IN atau parameter bernilai tabel.
4. Verifikasi perbaikannya dengan memantau Activity Monitor setelah penerapan. Penggunaan CPU turun menjadi 35-40%, eksekusi per menit berkurang menjadi 200-300, dan waktu respons aplikasi kembali normal.

11.2 Studi Kasus: Menyelesaikan Masalah yang Menghambat

Pengguna melaporkan bahwa sistem entri pesanan membeku secara berkala selama 30-60 detik sebelum melanjutkan operasi normal.

11.2.1 Mendeteksi Rantai Pemblokiran

Buka Activity Monitor selama salah satu kejadian pembekuan ini dan perluas panel Proses:

1. Sortir dengan ID sesi untuk melihat semua sesi yang diselenggarakan.
2. Beberapa sesi menunjukkan nilai dalam Diblokir Oleh kolom, semuanya menunjuk ke ID Sesi 73.
3. Sesi 73 menunjukkan '1' di Pemblokir Kepala kolom, mengonfirmasi bahwa itu adalah akar permasalahannya.
4. The Tipe Tunggu untuk sesi yang diblokir menunjukkan LCK_M_X, yang menunjukkan mereka menunggu kunci eksklusif.
5. The Tunggu Sumber Daya Kolom tersebut menunjukkan pemblokiran ada pada tabel Pesanan.

11.2.2 Menganalisis Penyebabnya

Klik kanan Sesi 73 dan pilih Detail untuk melihat perintah:

UPDATE Orders 
SET Status = 'Processing', 
    LastModified = GETDATE()
WHERE OrderId IN (SELECT OrderId FROM #TempOrders);

Pembaruan ini merupakan bagian dari pekerjaan pemrosesan batch yang berjalan setiap jam. Memeriksa Masuk Kolom mengonfirmasi bahwa sesi tersebut milik akun layanan pemrosesan batch.

Kueri tersebut mengunci tabel Pesanan saat memproses ribuan pesanan. Waktu Tunggu untuk sesi yang terblokir meningkat secara stabil, mengonfirmasi bahwa operasi yang berjalan lama ini adalah masalahnya.

11.2.3 Menerapkan Perbaikan

Resolusi jangka pendek:

1. Dokumentasikan rincian Sesi 73 termasuk teks pertanyaan dan durasinya.
2. Biarkan pembaruan selesai secara alami karena ini adalah pemrosesan batch yang sah.
3. Setelah selesai, verifikasi bahwa sesi yang terblokir telah bersih dan operasi normal dilanjutkan.

Solusi jangka panjang yang diterapkan:

1. Jadwalkan ulang pekerjaan batch beroperasi di luar jam sibuk (pukul 2-4 pagi, bukan pada jam kerja).
2. Ubah pemrosesan batch untuk memperbarui pesanan dalam kelompok yang lebih kecil, sebanyak 100 rekaman dalam satu waktu, dan melepaskan kunci antar kelompok.
3. Tambahkan indeks pada kolom OrderId untuk mempercepat operasi pembaruan.
4. Pertimbangkan isolasi SNAPSHOT untuk operasi baca guna mengurangi dampak pemblokiran.

11.3 Studi Kasus: Mengidentifikasi Eksekusi Query yang Berlebihan

Pemantauan basis data menunjukkan penggunaan CPU telah meningkat secara bertahap selama sebulan terakhir, tetapi tidak ada perubahan nyata yang terjadi pada kode aplikasi.

11.3.1 Mendeteksi Jumlah Eksekusi yang Abnormal

Buka Activity Monitor dan periksa panel Recent Expensive Query:

1. Sortir dengan Eksekusi/menit untuk melihat kueri yang paling sering dieksekusi.
2. Kueri teratas menunjukkan 37,000 eksekusi per menit—jauh lebih tinggi daripada kueri lainnya.
3. Klik kanan dan pilih Edit Teks Kueri.
4. Kueri mengambil informasi kategori produk:

   SELECT CategoryId, CategoryName 
   FROM ProductCategories 
   WHERE CategoryId = @CategoryId;
   

5. Permintaan sederhana ini seharusnya cepat dan dapat disimpan dalam cache, namun dijalankan puluhan ribu kali per menit.

11.3.2 Penelusuran ke Kode Aplikasi

Di panel Proses, temukan sesi yang menjalankan kueri ini:

1. Perhatikan Aplikasi kolom menunjukkan “ProductCatalogService”.
2. Klik kanan salah satu sesi ini dan pilih Jejak Proses di SQL Server Profil.
3. SQL Profiler mengungkap kueri dijalankan berulang-ulang dengan cepat dengan nilai CategoryId yang berbeda.
4. Hubungi tim pengembangan yang mengelola ProductCatalogService untuk peninjauan kode.

Peninjauan kode mengungkap masalah: perubahan terbaru mengambil daftar produk dengan kategori. Untuk setiap produk dalam set hasil (seringkali lebih dari 1,000 produk), kode tersebut melakukan panggilan basis data terpisah untuk mengambil informasi kategori—masalah kueri N+1 klasik.

11.3.3 Mengoptimalkan Aplikasi

Terapkan perbaikan yang tepat:

1. Ubah kueri aplikasi untuk menggunakan JOIN untuk mengambil produk dan kategorinya dalam satu panggilan basis data:

   SELECT p.ProductId, p.ProductName, c.CategoryId, c.CategoryName
   FROM Products p
   INNER JOIN ProductCategories c ON p.CategoryId = c.CategoryId
   WHERE p.Active = 1;
   

2. Terapkan kode yang diperbarui dan monitor Aktivitas Monitor.
3. Verifikasi perbaikannya: Eksekusi per menit untuk kategori kueri turun dari 37,000 menjadi di bawah 100, dan penggunaan CPU secara keseluruhan berkurang hingga 40%.
4. Dokumentasikan pelajaran yang dipelajari dan berbagi dengan tim pengembangan untuk mencegah masalah serupa pada perubahan kode di masa mendatang.

12. Mendeteksi Potensi Korupsi Basis Data

Meskipun Activity Monitor tidak dirancang khusus untuk mendeteksi kerusakan basis data, pola tertentu dalam tampilannya mungkin menunjukkan adanya masalah kerusakan mendasar yang memerlukan penyelidikan lebih lanjut.

12.1 Gejala Potensi Korupsi Basis Data

Jika kerusakan basis data terjadi dan sedang diakses, Anda mungkin sesekali melihat:

1. Di Panel Proses:

• Sesi macet dalam status DITANGGUHKAN dengan jenis tunggu yang tidak biasa
• Proses yang menunjukkan status kesalahan
• Kueri gagal berulang kali

2. Di Panel Tunggu Sumber Daya:

• Jenis tunggu terkait I/O yang tidak biasa yang dapat mengindikasikan masalah disk (meskipun hal ini lebih mungkin mengindikasikan masalah perangkat keras daripada kerusakan logis)

3. Dalam Pertanyaan Mahal Terbaru:

• Kueri dengan pembacaan fisik yang sangat tinggi jika berulang kali mencoba membaca halaman yang rusak

12.2 Pemeriksaan Lebih Lanjut dengan DBCC CHECKDB

Ketika Activity Monitor menampilkan gejala yang menunjukkan potensi kerusakan, Anda harus segera menjalankan DBCC CHECKDB untuk memverifikasi integritas basis data. Perintah ini memindai semua halaman basis data, memvalidasi checksum, dan memeriksa kesalahan konsistensi logis.

Untuk mempelajari lebih lanjut tentang cara menggunakan DBCC CHECKDB untuk memeriksa dan memperbaiki kerusakan database, lihat panduan DBCC CHECKDB yang komprehensif.

12.3 Perbaikan dengan Alat Profesional

Jika DBCC CHECKDB mengonfirmasi kerusakan basis data, Anda memiliki beberapa opsi untuk memperbaikinya:

• Pendekatan yang disarankan adalah memulihkan dari cadangan yang diketahui masih berfungsi. Lihat panduan lengkap kami tentang cara mencadangkan dan memulihkan SQL Server database.
• Untuk kerusakan kecil, DBCC CHECKDB dengan REPAIR_REBUILD dapat menyelesaikan masalah.
• Untuk database penting tanpa cadangan terbaru, profesional Perangkat lunak pemulihan SQL dan layanan sering kali dapat memulihkan data yang tidak dapat dilakukan oleh opsi perbaikan bawaan.

13. Kesimpulan

SQL Server Activity Monitor merupakan alat yang sangat berharga bagi administrator basis data, memberikan wawasan langsung mengenai kinerja server dan membantu mendiagnosis masalah dengan cepat dan efektif.

13.1 Ringkasan Poin-Poin Utama

Sepanjang panduan ini, kami telah menjelajahi bagaimana Activity Monitor membantu Anda memahami dan memecahkan masalah SQL Server kinerja:

• Activity Monitor menyediakan visibilitas waktu nyata ke dalam proses, penantian, kueri, dan I/O melalui antarmuka grafis yang terorganisasi.
• Lima panel—Ringkasan, Proses, Penantian Sumber Daya, I/O Berkas Data, dan Kueri Mahal Terkini—masing-masing menawarkan perspektif unik mengenai aktivitas server.
• Skenario pemecahan masalah umum seperti eksekusi kueri yang berlebihan, rantai pemblokiran, dan penggunaan CPU yang tinggi menjadi dapat dikelola dengan investigasi Monitor Aktivitas yang sistematis.
• Meskipun ampuh, Activity Monitor memiliki keterbatasan termasuk kurangnya data historis, pengelompokan tipe tunggu, dan beban pemantauan yang memengaruhi penerapannya.
• Melengkapi Activity Monitor dengan kueri DMV, sp_WhoIsActive, Extended Events, dan kemungkinan alat pihak ketiga akan menciptakan strategi pemantauan yang komprehensif.
• Mengikuti praktik terbaik untuk interval penyegaran, menutup Monitor Aktivitas saat tidak digunakan, dan menggabungkan beberapa panel untuk korelasi memaksimalkan nilainya sekaligus meminimalkan dampak.

13.2 Monitor Aktivitas sebagai Bagian dari Perangkat Anda

Activity Monitor seharusnya berfungsi sebagai alat respons pertama Anda untuk investigasi kinerja, bukan satu-satunya alat. Keunggulannya terletak pada penyediaan visibilitas langsung selama pemecahan masalah aktif, membantu Anda dengan cepat menentukan apakah database merupakan hambatan dan mengidentifikasi aspek spesifik mana yang memerlukan investigasi lebih lanjut.

Bayangkan Activity Monitor seperti dasbor di mobil Anda—alat ini langsung memberi tahu Anda jika ada masalah dan membantu Anda mengidentifikasi area yang perlu diperhatikan secara umum. Sebagaimana dasbor mobil Anda tidak memberi tahu persis mengapa lampu indikator mesin menyala, Activity Monitor mengarahkan Anda ke masalah tanpa selalu mengungkapkan akar permasalahannya secara lengkap. Analisis yang lebih mendalam tersebut membutuhkan alat dan keahlian tambahan.

Integrasikan Activity Monitor ke dalam perangkat yang lebih luas yang mencakup analisis rencana eksekusi, pelacakan statistik tunggu, solusi pemantauan historis, dan praktik terbaik kinerja. Gunakan bersama strategi pengindeksan yang tepat, teknik optimasi kueri, dan perencanaan kapasitas.

13.3 Melanjutkan Perjalanan Pembelajaran Anda

Menguasai Activity Monitor hanyalah satu langkah untuk menjadi administrator basis data yang efektif. Terus asah keterampilan Anda dengan:

• Belajar menafsirkan rencana eksekusi dan mengidentifikasi operasi yang tidak efisien
• Memahami SQL Server statistik tunggu dan implikasinya
• Mempelajari desain indeks dan teknik optimasi
• Menjelajahi SQL ServerArsitektur dan cara memproses kueri
• Mempraktikkan metodologi pemecahan masalah yang sistematis
• Membangun pengalaman dengan Extended Events untuk penelusuran detail
• Memahami tingkat isolasi transaksi dan dampaknya terhadap kinerja

Setiap investigasi kinerja dengan Activity Monitor mengajarkan Anda sesuatu yang baru tentang bagaimana SQL Server Pelajari cara kerja aplikasi dan bagaimana aplikasi berinteraksi dengan basis data. Dokumentasikan temuan Anda, bagikan pengetahuan dengan kolega, dan bangun pustaka solusi untuk masalah umum.

13.4 Sumber Daya Tambahan

Perluas pengetahuan Anda dengan sumber daya berharga ini:

• Buka Monitor Aktivitas di SQL Server Studio Manajemen (SSMS) : Resmi SQL Server dokumentasi tentang cara membuka Activity Monitor di SQL Server Studio Manajemen (SSMS).
• Activity Monitor : Resmi SQL Server dokumen tentang cara menggunakan Activity Monitor.

14. Pertanyaan yang Sering Diajukan (FAQ)

T: Apa itu SQL Server Monitor Aktivitas?

A: SQL Server Activity Monitor adalah alat bawaan dalam SQL Server Studio Manajemen yang menampilkan informasi waktu nyata tentang proses yang berjalan di SQL Server Instance dan dampaknya terhadap sumber daya server. Ini menyediakan dasbor grafis dengan lima panel yang menampilkan berbagai aspek aktivitas server, termasuk penggunaan prosesor, tugas yang menunggu, kecepatan I/O, sesi aktif, dan kueri mahal.

T: Bagaimana cara membuka Activity Monitor di SSMS?

A: Anda dapat membuka Activity Monitor menggunakan empat metode: (1) Klik ikon Activity Monitor di toolbar SSMS, (2) Klik kanan pada Activity Monitor Anda, SQL Server nama instance di Object Explorer dan pilih Activity Monitor(3) Tekan Ctrl + lain + A, atau (4) Konfigurasikan SSMS untuk meluncurkannya secara otomatis melalui Tools -> Opsi -> Lingkungan Hidup -> startup.

T: Izin apa yang saya perlukan untuk menggunakan Activity Monitor?

A: Kamu membutuhkan LIHAT STATUS SERVER izin untuk melihat sebagian besar informasi Activity Monitor. Untuk panel Data File I/O, Anda juga memerlukan salah satu dari berikut ini. BUAT DATABASE, UBAH DATABASE APAPUN, atau LIHAT DEFINISI APAPUN Tanpa izin ini, Activity Monitor mungkin terbuka tetapi menampilkan panel kosong.

T: Mengapa Monitor Aktivitas saya terhenti atau tidak berfungsi?

A: Activity Monitor biasanya berhenti karena masalah izin, versi SSMS yang kedaluwarsa, atau koneksi jarak jauh yang dinonaktifkan. Untuk mengatasinya: (1) Perbarui ke versi SSMS terbaru, (2) Pastikan Anda memiliki izin VIEW SERVER STATE, (3) Pastikan koneksi jarak jauh diaktifkan di SQL Server misalnya, (4) Mulai ulang SSMS, dan (5) Coba sambungkan dengan otentikasi Windows alih-alih otentikasi SQL jika memungkinkan.

T: Apa perbedaan antara Activity Monitor dan sp_WhoIsActive?

A: Activity Monitor adalah alat grafis bawaan SSMS yang menyediakan panel terorganisir untuk berbagai aspek pemantauan. sp_WhoIsActive adalah prosedur tersimpan gratis yang dibuat oleh komunitas yang mengembalikan informasi sesi terperinci dalam satu set hasil dengan jenis tunggu, detail pemblokiran, dan opsi penyesuaian yang lebih spesifik daripada Activity Monitor. Activity Monitor lebih baik untuk eksplorasi visual, sementara sp_WhoIsActive unggul dalam pemantauan berbasis skrip dan menyediakan informasi yang lebih detail.

T: Apakah Activity Monitor memengaruhi kinerja server?

J: Ya, Activity Monitor memiliki overhead yang terukur karena ia memeriksa DMV sistem pada setiap interval penyegaran. Dampaknya meningkat seiring dengan kecepatan penyegaran yang lebih rendah—Microsoft memperingatkan bahwa interval di bawah 10 detik dapat memengaruhi kinerja server. Selalu tutup Activity Monitor saat tidak digunakan secara aktif, dan pertimbangkan interval penyegaran 30-60 detik pada server produksi dengan beban berat.

T: Dapatkah saya mendapatkan data Activity Monitor menggunakan T-SQL?

A: Ya, Activity Monitor mengkueri tampilan manajemen dinamis sistem seperti sys.dm_exec_requests, sys.dm_exec_sessions, sys.dm_os_wait_stats, dan sys.dm_exec_query_stats. Anda dapat mengkueri DMV ini secara langsung menggunakan T-SQL untuk mengambil informasi yang setara secara terprogram, yang memungkinkan skrip pemantauan khusus dan pengumpulan data otomatis.

T: Berapa interval penyegaran default?

A: Interval penyegaran default adalah 10 detik. Anda dapat mengubahnya dengan mengklik kanan di mana saja di panel Ikhtisar, lalu memilih Interval Penyegaran, dan memilih dari opsi yang telah ditentukan: 1 detik, 5 detik, 10 detik, 30 detik, 1 menit, atau 1 jam. Interval yang lebih rendah memberikan tampilan yang lebih real-time tetapi meningkatkan overhead pemantauan.

T: Bagaimana cara membuka Activity Monitor secara otomatis saat SSMS dimulai?

A: Konfigurasikan peluncuran otomatis melalui opsi SSMS: Navigasi ke Tools -> Opsi -> Lingkungan Hidup -> startup, Lalu pilih Buka Penjelajah Objek dan Monitor Aktivitas dari Saat startup Menu tarik-turun. Monitor Aktivitas akan terbuka otomatis setiap kali Anda terhubung ke server di SSMS.

T: Apa saja keterbatasan Activity Monitor?

A: Batasan utama meliputi: (1) Tidak ada penyimpanan data historis atau kemampuan tren, (2) Jenis tunggu dikelompokkan ke dalam kategori daripada ditampilkan secara spesifik, (3) Beberapa jenis tunggu seperti CXPACKET mungkin tidak muncul, (4) Snapshot titik waktu mungkin melewatkan masalah sementara, (5) Pemantauan overhead dapat memengaruhi server yang sibuk, (6) Tidak ada mekanisme peringatan untuk pemantauan proaktif, dan (7) Tidak dapat menggabungkan data di beberapa server. SQL Server Untuk kebutuhan ini, lengkapi Activity Monitor dengan Extended Events, set pengumpulan data, atau alat pemantauan pihak ketiga.

---

tentang Penulis

Yuan Sheng adalah administrator basis data senior (DBA) dengan lebih dari 10 tahun pengalaman di SQL Server lingkungan dan manajemen basis data perusahaan. Ia telah berhasil menyelesaikan ratusan skenario pemulihan basis data di berbagai organisasi jasa keuangan, layanan kesehatan, dan manufaktur.

Yuan mengkhususkan diri dalam SQL Server pemulihan basis data, solusi ketersediaan tinggidan optimasi kinerja. Pengalaman praktisnya yang luas mencakup pengelolaan basis data multi-terabyte, implementasi Always On Availability Groups, dan pengembangan strategi pencadangan dan pemulihan otomatis untuk sistem bisnis yang sangat penting.

Melalui keahlian teknis dan pendekatan praktisnya, Yuan berfokus pada pembuatan panduan komprehensif yang membantu administrator basis data dan profesional TI memecahkan masalah kompleks SQL Server tantangan secara efisien. Dia selalu mengikuti perkembangan terbaru SQL Server rilis dan teknologi basis data Microsoft yang terus berkembang, secara berkala menguji skenario pemulihan untuk memastikan rekomendasinya mencerminkan praktik terbaik di dunia nyata.

Memiliki pertanyaan tentang SQL Server pemulihan atau butuh panduan pemecahan masalah basis data tambahan? Yuan menyambut masukan dan saran untuk meningkatkan sumber daya teknis ini.