Dalam dua posting terakhir saya, saya membahas cara mengurangi jumlah log transaksi yang dihasilkan dan bagaimana memastikan log transaksi selalu dapat dihapus dengan benar. Dalam posting ini saya ingin melanjutkan dengan tema kinerja log transaksi dan membahas beberapa masalah konfigurasi log transaksi yang dapat menyebabkan masalah.
Terlalu Banyak VLF
Log transaksi dibagi menjadi beberapa bagian yang disebut file log virtual (VLFs) sehingga sistem manajemen log dapat dengan mudah melacak bagian mana dari log transaksi yang tersedia untuk digunakan kembali. Ada rumus untuk berapa banyak VLF yang Anda dapatkan saat Anda membuat log transaksi, menumbuhkannya secara manual, atau tumbuh secara otomatis:
| Hingga 1 MB | 2 VLF, masing-masing kira-kira 1/2 dari ukuran total |
|---|---|
| 1MB hingga 64MB | 4 VLF, masing-masing kira-kira 1/4 dari total ukuran |
| 64MB hingga 1GB | 8 VLF, masing-masing kira-kira 1/8 dari total ukuran |
| Lebih dari 1 GB | 16 VLF, masing-masing kira-kira 1/16 dari total ukuran |
Misalnya, jika Anda membuat log transaksi menjadi 8GB, Anda akan mendapatkan 16 VLF di mana masing-masing kira-kira 512MB. Jika kemudian Anda menambah log sebesar 4 GB lagi, Anda akan mendapatkan 16 VLF tambahan dengan masing-masing berukuran sekitar 256 MB, dengan total 32 VLF.
Catatan:algoritma ini sedikit berubah untuk SQL Server 2014 untuk meringankan masalah fragmentasi VLF – lihat posting blog ini untuk detailnya
Praktik terbaik umum adalah menyetel pertumbuhan otomatis log ke sesuatu selain 10% default, sehingga Anda dapat mengontrol jeda yang diperlukan saat menginisialisasi nol ruang log transaksi baru. Katakanlah Anda membuat log transaksi 256MB dan menyetel pertumbuhan otomatis ke 32MB, lalu log tersebut tumbuh ke ukuran kondisi-mapan 16GB. Dengan rumus di atas, ini akan mengakibatkan log transaksi Anda memiliki lebih dari 2.000 VLF.
Banyaknya VLF ini kemungkinan akan menghasilkan beberapa masalah kinerja untuk operasi yang memproses log transaksi (misalnya pemulihan kerusakan, pembersihan log, pencadangan log, replikasi transaksional, pemulihan basis data). Situasi ini disebut memiliki fragmentasi VLF. Umumnya jumlah VLF lebih dari seribu atau lebih akan menjadi masalah dan perlu ditangani (paling banyak yang pernah saya dengar adalah 1,54 juta VLF dalam log transaksi yang berukuran lebih dari 1 TB!).
Cara untuk mengetahui berapa banyak VLF yang Anda miliki adalah dengan menggunakan DBCC LOGINFO yang tidak berdokumen (dan sepenuhnya aman) memerintah. Jumlah baris output adalah jumlah VLF di log transaksi Anda. Jika menurut Anda jumlahnya terlalu banyak, cara untuk menguranginya adalah:
- Izinkan log untuk dihapus
- Mengecilkan log secara manual
- Ulangi langkah 1 dan 2 hingga log mencapai ukuran kecil (yang mungkin rumit pada sistem produksi yang sibuk)
- Tumbuhkan log secara manual ke ukuran yang seharusnya, dalam langkah hingga 8 GB sehingga setiap VLF tidak lebih besar dari sekitar 0,5 GB
Anda dapat membaca lebih lanjut tentang masalah fragmentasi VLF dan proses untuk memperbaikinya di:
- Artikel Microsoft KB yang menyarankan pengurangan nomor VLF
- Dapatkah pertumbuhan file log memengaruhi DML?
- 8 langkah untuk meningkatkan hasil log transaksi
Tempdb
Tempdb perlu memiliki log transaksi yang dikonfigurasi seperti database lainnya, dan mungkin tumbuh seperti database lainnya. Tetapi juga memiliki beberapa perilaku berbahaya yang dapat menyebabkan masalah bagi Anda.
Saat instance SQL Server dimulai ulang karena alasan apa pun, data tempdb dan file log akan kembali ke ukuran yang paling baru ditetapkan. Ini berbeda dari semua database lain, yang tetap pada ukurannya saat ini setelah instance dimulai ulang.
Perilaku ini berarti bahwa jika log transaksi tempdb telah berkembang untuk mengakomodasi beban kerja normal, Anda harus melakukan ALTER DATABASE untuk mengatur ukuran file log jika tidak, ukurannya akan turun setelah instance dimulai ulang dan harus bertambah lagi. Setiap kali file log tumbuh atau tumbuh otomatis, ruang baru harus diinisialisasi nol dan aktivitas logging dijeda saat selesai. Jadi, jika Anda tidak mengelola ukuran file log tempdb dengan benar, Anda akan membayar penalti kinerja seiring bertambahnya setiap instance dimulai ulang.
Penyusutan File Log Biasa
Cukup sering saya mendengar orang mengatakan bagaimana mereka biasanya mengecilkan log transaksi database setelah tumbuh dari operasi reguler (misalnya impor data mingguan). Ini bukan hal yang baik untuk dilakukan.
Seperti yang saya jelaskan di atas, setiap kali log transaksi tumbuh atau tumbuh otomatis, ada jeda sementara bagian baru dari file log diinisialisasi nol. Jika Anda secara teratur mengecilkan log transaksi karena bertambah ke ukuran X, itu berarti Anda sering mengalami masalah kinerja karena log transaksi otomatis tumbuh kembali ke ukuran X lagi.
Jika log transaksi Anda terus bertambah hingga ukuran X, biarkan saja! Atur secara proaktif ke ukuran X, kelola VLF Anda seperti yang saya jelaskan di atas, dan terima ukuran X sebagai ukuran yang diperlukan untuk beban kerja normal Anda. Log transaksi yang lebih besar tidak menjadi masalah.
Beberapa File Log
Tidak ada peningkatan kinerja dari membuat beberapa file log untuk database. Menambahkan file log kedua mungkin diperlukan, namun, jika file log yang ada kehabisan ruang dan Anda tidak ingin memaksa log transaksi untuk dihapus dengan beralih ke model pemulihan sederhana dan melakukan pemeriksaan (karena ini merusak pencadangan log rantai).
Saya sering ditanya apakah ada alasan mendesak untuk menghapus file log kedua atau apakah boleh membiarkannya di tempatnya. Jawabannya adalah Anda harus menghapusnya sesegera mungkin.
Meskipun file log kedua tidak menyebabkan masalah kinerja untuk beban kerja Anda, itu mempengaruhi pemulihan bencana. Jika database Anda rusak karena suatu alasan, Anda harus memulihkannya dari awal. Fase pertama dari setiap urutan pemulihan adalah membuat data dan file log jika tidak ada.
Anda dapat membuat pembuatan file data hampir seketika dengan mengaktifkan inisialisasi file instan yang melewatkan inisialisasi nol tetapi itu tidak berlaku untuk file log. Ini berarti bahwa pemulihan harus membuat semua file log yang ada saat cadangan lengkap diambil (atau dibuat selama periode waktu yang dicakup oleh cadangan log transaksi) dan menginisialisasi nol. Jika membuat file log kedua dan lupa menjatuhkannya lagi, menginisialisasi nol selama operasi pemulihan bencana akan menambah total waktu henti. Ini bukan masalah kinerja beban kerja, tetapi mempengaruhi ketersediaan server secara keseluruhan.
Mengembalikan dari Snapshot Database
Masalah terakhir dalam daftar saya sebenarnya adalah bug di SQL Server. Jika Anda menggunakan snapshot database sebagai cara untuk memulihkan kembali dengan cepat ke titik waktu yang diketahui tanpa harus memulihkan cadangan (dikenal sebagai reverting from snapshot) maka Anda dapat menghemat banyak waktu. Namun, ada kerugian besar.
Ketika database kembali dari snapshot database, log transaksi dibuat ulang dengan dua VLF 0,25 MB. Ini berarti Anda harus menumbuhkan log transaksi Anda kembali ke ukuran dan jumlah VLF yang optimal (atau akan tumbuh secara otomatis), dengan semua inisialisasi nol dan jeda beban kerja yang telah saya bahas sebelumnya. Jelas bukan perilaku yang diinginkan.
Ringkasan
Seperti yang dapat Anda lihat dari posting ini dan dua posting saya sebelumnya, ada banyak hal yang dapat menyebabkan kinerja log transaksi yang buruk, yang kemudian berdampak pada kinerja beban kerja Anda secara keseluruhan.
Jika Anda dapat menangani semua hal ini, Anda akan memiliki log transaksi yang sehat. Tapi itu tidak berakhir di sana karena Anda perlu memastikan Anda memantau log transaksi Anda sehingga Anda diperingatkan untuk hal-hal seperti pertumbuhan otomatis dan latensi membaca dan menulis I/O yang berlebihan. Saya akan membahas cara melakukannya di postingan mendatang.
