Pemantauan Log Transaksi

Selama setahun terakhir saya telah membuat blog beberapa kali di SQLPerformance.com tentang masalah kinerja log transaksi (lihat di sini) dan saya berjanji untuk membahas pemantauan log transaksi, yang akan saya lakukan di posting ini. Saya akan menyajikan beberapa metrik yang dapat Anda lacak, mengapa Anda harus peduli, dan saran apa pun untuk menangani masalah yang ditunjukkan.

DMV

Cara termudah untuk memantau latensi I/O log transaksi adalah dengan menggunakan sys.dm_io_virtual_file_stats DMV. Anda harus melakukan beberapa matematika untuk mendapatkan hasil yang bermanfaat dan Anda bisa mendapatkan beberapa contoh kode di skrip VirtualFileStats.sql dalam file zip demo ini. Anda benar-benar ingin melihat latensi tulis kurang dari 5 md untuk log transaksi.

Sebelumnya pada bulan November saya membuat blog hasil survei yang menunjukkan log transaksi dan latensi file data tempdb untuk lebih dari 25.000 basis data di seluruh dunia (lihat di sini), dengan 80% basis data mencapai tanda 5 md atau kurang untuk latensi penulisan log transaksi.

Jika latensi tulis Anda lebih tinggi dari 5 md, Anda dapat:

• Bekerja untuk mengurangi jumlah log yang dihasilkan dan/atau jumlah log flush yang terjadi dari transaksi kecil, seperti yang saya jelaskan di posting sebelumnya.
• Ikuti beberapa langkah pemecahan masalah yang saya jelaskan dalam posting blog survei di atas.
• Pindah ke subsistem I/O yang lebih cepat, mengingat bahwa jika Anda memutuskan untuk menggunakan SSD, Anda perlu menggunakan dua dalam konfigurasi RAID-1.

Hal lain yang dapat Anda perhatikan adalah memastikan Anda tidak mencapai batas keras 32 I/O tulis yang luar biasa untuk setiap log transaksi basis data pada 2008 R2 dan sebelumnya (ditingkatkan ke 2012 dari SQL Server 2012 dan seterusnya). Anda dapat mencoba melakukan ini dengan melihat Disk Fisik/Rata-rata. Panjang Antrian Tulis Disk, tapi itu untuk seluruh volume, bukan per file jadi jika ada hal lain di volume selain dari file log yang Anda minati, itu tidak akan memberi Anda nomor yang valid. Cara yang lebih baik adalah dengan menggabungkan hasil sys.dm_io_pending_io_requests DMV, yang mencantumkan semua I/Os yang beredar. Berikut beberapa kode untuk melakukannya:

SELECT
	COUNT (*) AS [PendingIOs],
	DB_NAME ([vfs].[database_id]) AS [DBName],
	[mf].[name] AS [FileName],
	[mf].[type_desc] AS [FileType],
	SUM ([pior].[io_pending_ms_ticks]) AS [TotalStall]
FROM sys.dm_io_pending_io_requests AS [pior]
JOIN sys.dm_io_virtual_file_stats (NULL, NULL) AS [vfs]
	ON [vfs].[file_handle] = [pior].[io_handle]
JOIN sys.master_files AS [mf]
	ON [mf].[database_id] = [vfs].[database_id]
	AND [mf].[file_id] = [vfs].[file_id]
WHERE
   [pior].[io_pending] = 1
GROUP BY [vfs].[database_id], [mf].[name], [mf].[type_desc]
ORDER BY [vfs].[database_id], [mf].[name];

Anda dapat dengan mudah memodifikasi ini untuk hanya menampilkan hasil untuk file log (filter pada type_desc ='LOG' ) dan hanya untuk ID database yang Anda minati.

Jika Anda menemukan bahwa Anda mencapai batas 32 untuk database tertentu, Anda dapat:

• Kurangi jumlah log flush yang terjadi dengan mengurangi jumlah transaksi kecil dan perhatikan hal-hal seperti pemisahan halaman dan indeks yang tidak digunakan/duplikat yang diubah selama operasi modifikasi data. Anda dapat membaca lebih lanjut tentang mengoptimalkan log flushes di posting blog ini
• Coba gunakan subsistem I/O yang lebih cepat
• Tingkatkan ke SQL Server 2012 atau lebih tinggi, dengan batas 112
• Cobalah delayed durability feature DMV yang ditambahkan di SQL Server 2014
• Sebagai upaya terakhir, bagi beban kerja ke beberapa database atau server

Jika Anda tertarik untuk melihat berapa banyak log transaksi yang dihasilkan oleh transaksi Anda, Anda dapat menggunakan sys.dm_tran_database_transactions DMV, dengan kode seperti di bawah ini:

BEGIN TRAN;
GO
 
-- Do something you want to evaluate
GO 
 
SELECT [database_transaction_log_bytes_used]
FROM sys.dm_tran_database_transactions
WHERE [database_id] = DB_ID (N'YourTestDB');
GO

Anda mungkin sangat terkejut melihat berapa banyak log yang dihasilkan, terutama di tempdb untuk kode yang menggunakan objek sementara. Dan tentu saja, log transaksi tempdb dapat menjadi penghambat seperti halnya database pengguna.

Penghitung Monitor Kinerja

Penghitung kinerja terkait log semuanya ada di objek kinerja Database. Berikut adalah beberapa yang utama untuk ditonton (baik dengan Performance Monitor itu sendiri, atau menggunakan peringatan SQL Agent, atau menggunakan sys.dm_os_performance_counters DMV, atau di alat pemantauan pihak ketiga favorit Anda):

Pertumbuhan Log

Anda tidak ingin melihat penghitung ini meningkat karena mengatakan ada sesuatu yang terjadi di database yang menyebabkan lebih banyak log transaksi dihasilkan daripada ruang saat ini. Ini menyiratkan bahwa log transaksi tidak dapat dihapus sehingga Anda harus menyelidiki penyebabnya dengan menanyakan bidang log_reuse_wait_desc dari sys.databases dan mengambil tindakan apa pun yang diperlukan (lihat faktor topik Buku Online yang Dapat Menunda Pemotongan Log untuk lebih jelasnya). Beberapa contoh kode adalah:

SELECT [log_reuse_wait_desc]
	FROM sys.databases
	WHERE [name] = N'YourDB';
GO

Setiap kali pertumbuhan log terjadi, bagian log transaksi yang baru dialokasikan harus dihilangkan, ditambah lebih banyak File Log Virtual ditambahkan – keduanya dapat menyebabkan masalah seperti yang saya tulis di blog sebelumnya.

Log Menyusut

Kecuali Anda adalah orang yang melakukan operasi penyusutan untuk mengembalikan log transaksi yang tidak terkendali, Anda tidak ingin melihat penghitung ini meningkat. Jika seseorang mengecilkan log transaksi tanpa alasan yang jelas, log transaksi tersebut kemungkinan akan bertambah lagi, menyebabkan masalah seperti yang saya tulis di blog sebelumnya.

Persen Log Digunakan

Anda harus memantau penghitung ini dan berhati-hati jika nilainya lebih dari 90%, karena hal itu menunjukkan bahwa pertumbuhan log mungkin akan segera terjadi dan log transaksi tidak dapat dihapus dengan benar, seperti yang saya bahas di atas.

Log Flush Tunggu/dtk

Anda ingin nilai ini tetap sama atau berkurang. Jika meningkat, itu berarti Anda memiliki hambatan subsistem I/O atau hambatan di dalam mekanisme log flush karena Anda mem-flush banyak bagian kecil log. Peningkatan di sini mungkin juga berkorelasi dengan mencapai 32 I/O yang luar biasa untuk log. Lihat pembahasan sys.dm_io_pending_io_requests di atas untuk lebih jelasnya.

Byte Log Flushed/dtk dan Log Flushes/dtk

Kedua penghitung ini memungkinkan Anda untuk mengetahui ukuran rata-rata log flush, dengan membagi penghitung pertama dengan yang kedua. Hasilnya akan menjadi nilai antara 512 dan 61440 (masing-masing ukuran minimum dan maksimum dari log flush). Nilai yang lebih rendah lebih mungkin berkorelasi dengan peningkatan Log Flush Waits/sec. Sekali lagi, lihat pembahasan sys.dm_io_pending_io_requests di atas untuk lebih jelasnya.

Acara Diperpanjang

Untuk yang lebih mahir di antara Anda, ada beberapa Acara yang Diperpanjang yang dapat Anda gunakan untuk melihat apa yang terjadi dengan log. Saya sarankan Anda mulai dengan menggunakan templat Pelacakan IO File Log Database di SQL Server 2012 SSMS. Anda dapat melakukannya dengan membuka Object Explorer dan kemudian instance Anda -> Manajemen -> Acara yang Diperpanjang dan mengklik kanan Sesi untuk memilih Wizard Sesi Baru. Di Jendela yang muncul, ketik nama sesi dan pilih template pelacakan dari tarik-turun. Kemudian tekan Ctrl+Shift+N dan sesi akan ditulis ke jendela kueri. Sayangnya, detail dari semua yang ada di sana berada di luar cakupan posting ini, tetapi deskripsi template cukup jelas:

Ada juga Extended Event baru di SQL Server 2012 yang disebut transaction_log yang dapat digunakan untuk melakukan segala macam analisis menarik tentang catatan log apa yang dihasilkan. Itu pasti topik yang akan saya bahas di posting mendatang.

Ringkasan

Dengan semua informasi di atas, Anda seharusnya dapat membuat sistem pemantauan log transaksi yang cukup bagus. Kesehatan log transaksi sangat penting untuk memastikan beban kerja Anda berjalan sebagaimana mestinya dan saya harap empat postingan dalam seri ini (ditambah semua tautan lainnya) telah membantu Anda meningkatkan kinerja keseluruhan lingkungan SQL Server Anda.