Dalam posting saya sebelumnya tentang merampingkan operasi log transaksi, saya membahas dua penyebab paling umum dari catatan log tambahan yang dihasilkan:bobot mati dari indeks nonclustered yang tidak digunakan dan operasi pemisahan halaman (yang menyebabkan fragmentasi indeks). Dengan asumsi Anda telah membaca posting itu, saya menyebutkan bahwa ada masalah yang lebih halus yang dapat merusak kinerja log transaksi, dan saya akan membahasnya di sini.
Banyak, Banyak Transaksi Kecil
Seringkali SQL Server akan menyiram sebagian dari log transaksi ke disk. Pembilasan log terjadi setiap kali:
- Catatan log komit transaksi dibuat.
- Catatan log pembatalan transaksi dibuat di akhir transaksi yang dibatalkan.
- 60KB catatan log telah dibuat sejak log flush sebelumnya.
Log flush terkecil yang mungkin adalah blok log 512-byte tunggal. Jika semua transaksi dalam beban kerja sangat kecil (misalnya menyisipkan satu baris tabel kecil) maka akan ada banyak log flush berukuran minimal yang terjadi. Penghapusan log dilakukan secara asinkron, untuk memungkinkan throughput log transaksi yang layak, tetapi ada batas tetap 32 I/O log-flush bersamaan pada satu waktu (ditingkatkan menjadi 112 pada SQL Server 2012).
Ada dua kemungkinan efek yang mungkin terjadi:
- Pada subsistem I/O berperforma lambat, volume penulisan log transaksi yang kecil dapat membebani subsistem I/O yang menyebabkan penulisan latensi tinggi dan penurunan throughput log transaksi berikutnya. Situasi ini dapat diidentifikasi dengan latensi penulisan tinggi untuk file log transaksi di output sys.dm_io_virtual_file_stats (lihat tautan demo di bagian atas posting sebelumnya)
- Pada subsistem I/O berperforma tinggi, penulisan dapat diselesaikan dengan sangat cepat, tetapi batas 32 I/O log-flush bersamaan menciptakan hambatan saat mencoba membuat rekaman log tahan lama di disk. Situasi ini dapat diidentifikasi dengan latensi penulisan yang rendah dan jumlah penulisan log transaksi yang hampir konstan mendekati 32 dalam output agregat sys.dm_io_pending_io_requests (lihat tautan demo yang sama).
Dalam kedua kasus tersebut, membuat transaksi lebih lama (yang sangat kontra-intuitif!) dapat mengurangi frekuensi flush log transaksi dan meningkatkan kinerja. Selain itu, dalam kasus #1, pindah ke subsistem I/O berperforma lebih tinggi dapat membantu – tetapi dapat menyebabkan kasus #2. Dengan kasus #2, jika transaksi tidak dapat dilakukan lebih lama, satu-satunya alternatif adalah membagi beban kerja ke beberapa database untuk mengatasi batas tetap 32 I/O log-flush bersamaan atau meningkatkan ke SQL Server 2012 atau lebih tinggi.
Pertumbuhan Otomatis Log Transaksi
Setiap kali ruang baru ditambahkan ke log transaksi, itu harus diinisialisasi nol (menulis nol untuk menimpa penggunaan sebelumnya dari bagian disk), tidak peduli apakah fitur inisialisasi file instan diaktifkan atau tidak. Ini berlaku untuk pembuatan, pertumbuhan manual, dan pertumbuhan otomatis dari log transaksi. Saat inisialisasi nol sedang berlangsung, catatan log tidak dapat di-flush ke log, sehingga pertumbuhan otomatis selama beban kerja yang mengubah data dapat menyebabkan penurunan throughput yang nyata, terutama jika ukuran pertumbuhan otomatis diatur menjadi besar ( katakan gigabyte, atau biarkan default 10%).
Pertumbuhan otomatis harus dihindari, jika memungkinkan dengan membiarkan log transaksi dihapus sehingga selalu ada ruang kosong yang dapat digunakan kembali untuk catatan log baru. Kliring log transaksi (juga dikenal sebagai pemotongan log transaksi, jangan disamakan dengan penyusutan log transaksi) dilakukan dengan pencadangan log transaksi saat menggunakan mode pemulihan Penuh atau Dicatat Massal, dan oleh pos pemeriksaan saat menggunakan mode pemulihan Sederhana.
Penghapusan log hanya dapat terjadi jika tidak ada catatan log di bagian log transaksi yang dihapus. Satu masalah umum yang mencegah pembersihan log adalah memiliki transaksi yang berjalan lama. Sampai transaksi dilakukan atau dibatalkan, semua catatan log dari awal transaksi dan seterusnya diperlukan jika transaksi mundur – termasuk semua catatan log dari transaksi lain yang diselingi dengan catatan dari transaksi yang berjalan lama. Transaksi yang berjalan lama bisa jadi karena desain yang buruk, kode yang menunggu input manusia, atau penggunaan transaksi bersarang yang tidak tepat, misalnya. Semua ini dapat dihindari setelah diidentifikasi sebagai masalah.
Anda dapat membaca lebih lanjut tentang ini di sini dan di sini.
Fitur Ketersediaan Tinggi
Beberapa fitur ketersediaan tinggi juga dapat menunda pembersihan log transaksi:
- Pencerminan basis data dan grup ketersediaan saat dijalankan secara asinkron dapat membuat antrean catatan log yang belum dikirim ke salinan basis data yang berlebihan. Catatan log ini harus disimpan sampai dikirim, menunda pembersihan log transaksi.
- Replikasi transaksional (dan juga Ubah Pengambilan Data) bergantung pada pekerjaan Agen Pembaca Log untuk secara berkala memindai log transaksi untuk transaksi yang mengubah tabel yang terdapat dalam publikasi replikasi. Jika Agen Pembaca Log tertinggal karena alasan apa pun, atau sengaja dibuat untuk jarang dijalankan, semua catatan log yang belum dipindai oleh pekerjaan harus disimpan, menunda pembersihan log transaksi.
Saat berjalan dalam mode sinkron, pencerminan database dan grup ketersediaan dapat menyebabkan masalah lain dengan mekanisme logging. Menggunakan pencerminan database sinkron sebagai contoh, setiap transaksi yang dilakukan pada prinsipal tidak dapat benar-benar kembali ke pengguna atau aplikasi sampai semua catatan log yang dihasilkan telah berhasil dikirim ke server cermin, menambahkan penundaan komit pada prinsipal. Jika ukuran transaksi rata-rata panjang, dan penundaannya pendek, ini mungkin tidak terlihat, tetapi jika transaksi rata-rata sangat singkat, dan penundaannya cukup lama, ini dapat memiliki efek nyata pada throughput beban kerja. Dalam hal ini, tujuan kinerja beban kerja perlu diubah, teknologi ketersediaan tinggi diubah ke mode asinkron, atau bandwidth jaringan dan kecepatan antara basis data utama dan basis data yang berlebihan harus ditingkatkan.
Kebetulan, jenis masalah yang sama dapat terjadi jika subsistem I/O itu sendiri dicerminkan secara sinkron – dengan potensi penundaan untuk semua penulisan yang dilakukan SQL Server.
Ringkasan
Seperti yang Anda lihat, kinerja log transaksi bukan hanya tentang catatan log transaksi tambahan yang dihasilkan – ada banyak faktor lingkungan yang juga dapat berdampak besar.
Intinya adalah bahwa kesehatan dan kinerja log transaksi sangat penting untuk mempertahankan kinerja beban kerja secara keseluruhan. Dalam dua posting ini saya telah merinci penyebab utama masalah kinerja log transaksi, jadi semoga Anda dapat mengidentifikasi dan memulihkan semua yang Anda miliki.
Jika Anda ingin mempelajari lebih banyak tentang operasi log transaksi dan penyetelan kinerja, saya sarankan Anda memeriksa kursus pelatihan online 7,5 jam saya tentang logging, pemulihan, dan log transaksi, yang tersedia melalui Pluralsight.
