Di bagian kedua dari seri ini, saya menjelaskan hierarki struktural dari log transaksi. Karena posting ini terutama berkaitan dengan File Log Virtual (VLF) yang saya jelaskan, saya sarankan Anda membaca bagian kedua sebelum melanjutkan.
Ketika semuanya baik-baik saja, log transaksi akan berulang tanpa henti, menggunakan kembali VLF yang ada. Perilaku ini adalah apa yang saya sebut sifat melingkar dari log . Namun, kadang-kadang, sesuatu akan terjadi untuk mencegah hal ini, dan log transaksi bertambah dan bertambah, menambahkan lebih banyak dan lebih banyak VLF. Dalam postingan ini, saya akan menjelaskan bagaimana semua ini bekerja, atau terkadang tidak.
VLF dan Pemotongan Log
Semua VLF memiliki struktur header yang berisi metadata tentang VLF. Salah satu bidang terpenting dalam struktur adalah status VLF, dan nilai yang kami minati adalah nol, artinya VLF tidak aktif , dan dua, artinya VLF aktif . Ini penting karena VLF yang tidak aktif dapat digunakan kembali, tetapi yang aktif tidak bisa. Perhatikan bahwa VLF sepenuhnya aktif atau tidak aktif sepenuhnya.
VLF akan tetap aktif saat catatan log yang diperlukan ada di dalamnya, sehingga tidak dapat digunakan kembali dan ditimpa (saya akan membahas catatan log sendiri lain kali). Contoh alasan mengapa catatan log mungkin diperlukan meliputi:
- Ada transaksi jangka panjang yang menjadi bagian dari catatan log, sehingga tidak dapat dilepaskan hingga transaksi telah dilakukan atau telah selesai bergulir kembali
- Cadangan log belum mencadangkan catatan log tersebut
- Bagian log tersebut belum diproses oleh Agen Pembaca Log untuk replikasi transaksional atau Ubah Pengambilan Data
- Bagian log tersebut belum dikirim ke mirror database asinkron atau replika grup ketersediaan
Penting untuk dicatat bahwa jika tidak ada alasan untuk VLF tetap aktif, VLF tidak akan berubah menjadi tidak aktif lagi sampai proses yang disebut log truncation terjadi – selengkapnya di bawah ini.
Menggunakan log transaksi hipotetis sederhana dengan hanya lima VLF dan nomor urut VLF mulai dari 1 (ingat dari terakhir kali bahwa pada kenyataannya, mereka tidak pernah melakukannya), ketika log transaksi dibuat, VFL 1 segera ditandai sebagai aktif, seperti yang selalu ada menjadi setidaknya satu VLF aktif dalam log transaksi—VLF tempat blok log sedang ditulis. Contoh skenario kami ditunjukkan pada Gambar 1 di bawah ini.
Gambar 1:Hipotetis, log transaksi baru dengan 5 VLF, nomor urut 1 sampai 5.
Karena lebih banyak catatan log dibuat, dan lebih banyak blok log ditulis ke log transaksi, VLF 1 terisi, jadi VLF 2 harus aktif agar lebih banyak blok log yang akan ditulis, seperti yang ditunjukkan pada Gambar 2 di bawah.
Gambar 2:Aktivitas berpindah melalui log transaksi.
SQL Server melacak awal transaksi tidak terikat (aktif) tertua, dan LSN ini tetap ada di disk setiap kali terjadi operasi pos pemeriksaan. LSN dari catatan log terbaru yang ditulis ke log transaksi juga dilacak, tetapi hanya dilacak di memori karena tidak ada cara untuk mempertahankannya di disk tanpa mengalami berbagai kondisi balapan. Itu tidak masalah karena hanya digunakan selama pemulihan kerusakan, dan SQL Server dapat mengerjakan LSN dari "akhir" log transaksi selama pemulihan kerusakan. Pos pemeriksaan dan pemulihan kerusakan adalah topik untuk postingan berikutnya dalam seri ini.
Akhirnya, VLF 2 akan terisi, dan VLF 3 akan menjadi aktif, dan seterusnya. Inti dari sifat melingkar dari log transaksi adalah bahwa VLF sebelumnya dalam log transaksi menjadi tidak aktif sehingga dapat digunakan kembali. Ini dilakukan dengan proses yang disebut pemotongan log , yang juga biasa disebut pembersihan log . Sayangnya, kedua istilah ini adalah kesalahan penamaan yang mengerikan karena tidak ada yang benar-benar terpotong atau dihapus.
Pemotongan log hanyalah proses memeriksa semua VLF dalam log transaksi dan menentukan VLF aktif mana yang sekarang dapat ditandai sebagai tidak aktif lagi, karena tidak ada kontennya yang masih diperlukan oleh SQL Server. Saat pemotongan log dilakukan, tidak ada jaminan bahwa setiap VLF aktif dapat dibuat tidak aktif—itu sepenuhnya tergantung pada apa yang terjadi dengan database.
Ada dua kesalahpahaman umum tentang pemotongan log:
- Log transaksi semakin kecil (kesalahpahaman "pemotongan"). Tidak – tidak ada perubahan ukuran dari pemotongan log. Satu-satunya hal yang mampu membuat log transaksi lebih kecil adalah DBCC SHRINKFILE eksplisit.
- VLF yang tidak aktif dihilangkan dalam beberapa cara (kesalahpahaman "menghapus"). Tidak – tidak ada yang ditulis ke VLF saat dibuat tidak aktif kecuali beberapa bidang di header VLF.
Gambar 3 di bawah menunjukkan log transaksi kami di mana VLF 3 dan 4 aktif, dan pemotongan log dapat menandai VLF 1 dan 2 tidak aktif.
Gambar 3:Pemotongan log menandai VLF sebelumnya sebagai tidak aktif.
Kapan pemotongan log terjadi bergantung pada model pemulihan yang digunakan untuk database:
- Model sederhana:pemotongan log terjadi saat operasi pos pemeriksaan selesai
- Model lengkap atau model yang dicatat secara massal:pemotongan log terjadi saat pencadangan log selesai (selama tidak ada pencadangan penuh atau diferensial yang berjalan bersamaan, dalam hal ini pemotongan log ditangguhkan hingga pencadangan data selesai)
Tidak ada pengecualian untuk ini.
Sifat Lingkaran dari Log
Untuk menghindari log transaksi harus bertambah, pemotongan log harus dapat menandai VLF tidak aktif. VLF fisik pertama dalam log harus tidak aktif agar log transaksi memiliki sifat melingkar.
Perhatikan Gambar 4 di bawah ini, yang menunjukkan VLF 4 dan 5 sedang digunakan dan pemotongan log telah menandai VLF 1 hingga 3 sebagai tidak aktif. Lebih banyak catatan log dihasilkan, lebih banyak blok log ditulis ke dalam VLF 5, dan akhirnya terisi.
Gambar 4:Aktivitas mengisi VLF fisik tertinggi dalam log transaksi.
Pada titik ini, manajer log untuk database melihat status VLF fisik pertama dalam log transaksi, yang dalam contoh kita adalah VLF 1, dengan nomor urut 1. VLF 1 tidak aktif, sehingga log transaksi dapat membungkus dan mulai mengisi lagi dari awal. Manajer log mengubah VLF pertama menjadi aktif dan meningkatkan nomor urutnya menjadi satu lebih tinggi dari nomor urut VLF tertinggi saat ini. Jadi itu menjadi VLF 6, dan logging berlanjut dengan blok log yang ditulis ke dalam VLF itu. Ini adalah sifat melingkar dari log, seperti yang ditunjukkan di bawah ini pada Gambar 5.
Gambar 5:Sifat melingkar dari log transaksi dan penggunaan kembali VLF.
Saat Terjadi Kesalahan
Ketika VLF fisik pertama di log transaksi tidak aktif, log transaksi tidak dapat membungkus, sehingga akan tumbuh (asalkan dikonfigurasi untuk melakukannya dan ada ruang disk yang cukup). Ini sering terjadi karena ada sesuatu yang mencegah pemotongan log menonaktifkan VLF. Jika Anda menemukan log transaksi untuk database berkembang, Anda dapat meminta SQL Server untuk mengetahui apakah ada masalah pemotongan log menggunakan kode sederhana di bawah ini:
SELECT
[log_reuse_wait_desc]
FROM [master].[sys].[databases]
WHERE [name] = N'MyDatabase'; Jika pemotongan log dapat menonaktifkan satu atau lebih VLF, maka hasilnya akan menjadi NOTHING. Jika tidak , Anda akan diberikan alasan mengapa pemotongan log tidak dapat menonaktifkan VLF apa pun. Ada daftar panjang kemungkinan alasan yang dijelaskan di sini di bagian Faktor yang dapat menunda pemotongan log.
Penting untuk memahami semantik dari apa hasilnya:itulah alasan pemotongan log tidak dapat melakukan apa pun terakhir kali mencoba dijalankan . Misalnya, hasilnya mungkin ACTIVE_BACKUP_OR_RESTORE, tetapi Anda tahu bahwa pencadangan lengkap yang berjalan lama telah selesai. Ini hanya berarti bahwa terakhir kali pemotongan log dicoba, pencadangan masih berjalan.
Menurut pengalaman saya, alasan paling umum untuk mencegah pemotongan log adalah LOG_BACKUP; yaitu, lakukan pencadangan log! Tapi ada juga perilaku aneh yang menarik dengan LOG_BACKUP . Jika Anda terus-menerus melihat hasilnya LOG_BACKUP tetapi Anda tahu pencadangan log berhasil dilakukan, itu karena sangat sedikit aktivitas di database dan VLF saat ini sama dengan terakhir kali pencadangan log dilakukan. Jadi, LOG_BACKUP berarti "lakukan pencadangan log" atau "semua catatan log yang dicadangkan berasal dari VLF saat ini, sehingga tidak dapat dinonaktifkan." Ketika yang terakhir terjadi, itu bisa membingungkan.
Memutar Kembali…
Mempertahankan sifat melingkar dari log transaksi sangat penting untuk menghindari pertumbuhan log yang mahal dan kebutuhan untuk mengambil tindakan korektif. Biasanya, ini berarti memastikan pencadangan log terjadi secara teratur untuk memfasilitasi pemotongan log dan mengukur log transaksi agar dapat menampung operasi besar yang berjalan lama seperti pembangunan kembali indeks atau operasi ETL tanpa terjadi pertumbuhan log.
Di bagian selanjutnya dari seri ini, saya akan membahas catatan log, cara kerjanya, dan beberapa contoh menarik.
