Cara terbaik untuk mempertahankan ukuran file log SQL


13

Saya agak DBA baru dan saya mengelola contoh SQL Server 2012 yang memiliki cukup banyak aktivitas. Saya menjalankan dalam mode Pemulihan Penuh karena kami membutuhkan pemulihan waktu.

Saat ini, saya mengambil cadangan penuh dari database dan log setiap hari jam 5 pagi. Beberapa file log telah menggelembung hingga 300 GB dan bahkan setelah mengambil cadangan, ukurannya tidak berkurang. Saya bisa membuat mereka mengurangi ukuran dengan menjalankan sesuatu yang mirip dengan:

BACKUP LOG db1 TO DISK = '\\server\share\db1_log1.trn';
DBCC ShrinkFile([db1_log], 0);

BACKUP LOG db1 TO DISK = '\\server\share\db1_log2.trn';
DBCC ShrinkFile([db1_log], 0);

BACKUP LOG db1 TO DISK = '\\server\share\db1_log3.trn';
DBCC ShrinkFile([db1_log], 0);

Ketika saya memeriksa LSN file cadangan saya melihat sesuatu seperti:

RESTORE headeronly FROM DISK = N'\\server\share\db1_log1.trn'
FirstLSN:  15781000014686200001
SecondLSN: 15802000000665000001

RESTORE headeronly FROM DISK = N'\\server\share\db1_log2.trn'
FirstLSN:  15802000000665000001
SecondLSN: 15805000000004100001

RESTORE headeronly FROM DISK = N'\\server\share\db1_log3.trn'
FirstLSN:  15805000000004100001
SecondLSN: 15808000000004200001

Saya tidak percaya saya memutus rantai log saya dengan menyusutkan file log. Membaca ini, saya yakin saya merusak kinerja saya karena file-file log menyusut harus tumbuh kembali sendiri.

Pertanyaan:

  1. Mengapa file log tidak menyusut setelah cadangan saya? Apakah karena ada transaksi yang tidak terikat?
  2. Pada awalnya saya berpikir saya harus mengecilkan file log setelah setiap cadangan 5:00 pagi. Setelah membaca tentang bagaimana itu buruk untuk kinerja saya sekarang percaya bahwa saya perlu mengambil cadangan log reguler setiap beberapa jam di siang hari. Apakah itu benar?
  3. Cadangan penuh normal saya untuk database / log terjadi setiap hari pada jam 5:00 pagi dan kadang-kadang memakan waktu 3 jam. Jika saya menjadwalkan pencadangan log terjadi setiap jam, apa yang akan terjadi ketika cadangan log bertabrakan dengan cadangan 5:00 AM?

Jawaban:


10
  1. Mengapa file log tidak menyusut setelah cadangan saya? Apakah karena ada transaksi yang tidak terikat?

File log NTFS yang sebenarnya tidak "menyusut" dari cadangan log transaksi, tetapi VLF (File Log Virtual) dalam log transaksi ditandai untuk digunakan kembali (karena mereka sekarang dicadangkan dan bertahan di media) memungkinkan pembungkus dari log transaksi digunakan untuk terjadi. Jika Anda tidak mencadangkan log transaksi, atau tidak cukup sering maka tidak akan tersedia VLF dan itu akan menyebabkan log transaksi tumbuh (asalkan autogrowth diatur) untuk mengakomodasi entri log transaksi tambahan.

2.Pada awalnya saya berpikir saya harus mengecilkan file log setelah setiap 5:00 pagi cadangan. Setelah membaca tentang bagaimana itu buruk untuk kinerja saya sekarang percaya bahwa saya perlu mengambil cadangan log reguler setiap beberapa jam di siang hari. Apakah itu benar?

Penyusutan file rutin dan terjadwal bukanlah ide yang baik. Hanya ketika Anda perlu mendapatkan kembali ruang yang sangat dibutuhkan Anda dapat mempertimbangkan a DBCC SHINKFILE. Juga, ketika Anda terus mengembangkan log transaksi Anda, Anda bisa menghambat hal-hal lain seperti pemulihan database. Dengan terlalu banyak VLF dalam log transaksi (masalah umum ketika log transaksi hanya tumbuh dengan peningkatan penyimpanan kecil) jumlah waktu untuk memulihkan database bisa lebih lama dari yang diinginkan.

3. Pencadangan penuh normal dari database / log saya lakukan setiap hari pada jam 5:00 pagi dan kadang-kadang memakan waktu 3 jam. Jika saya menjadwalkan pencadangan log terjadi setiap jam, apa yang akan terjadi ketika cadangan log bertabrakan dengan cadangan 5:00 AM?

Tidak ada yang akan terjadi, itu adalah operasi yang sepenuhnya legal. Lihat grafik di bawah ini dari MSDN . Di mana ada titik hitam, kedua operasi itu tidak dapat terjadi pada saat yang sama. Seperti yang Anda lihat, cadangan basis data dan log transaksi diizinkan secara bersamaan.

masukkan deskripsi gambar di sini

Yang perlu diperhatikan di sini adalah Anda harus mencadangkan log transaksi Anda lebih sering. Pertumbuhan file NTFS bukan satu-satunya masalah yang bisa Anda hadapi dengan tidak mencadangkan log transaksi Anda lebih sering. Jika Anda mengalami kegagalan penyimpanan dan log transaksi Anda hilang, maka Anda hanya dapat mengembalikan ke titik waktu cadangan log transaksi terakhir Anda. Jika log transaksi hilang, Anda tidak akan dapat mencadangkan ekor log dan mengembalikannya ke titik kegagalan. Dalam kasus Anda, Anda berpotensi kehilangan data 24 jam. Tetapi jika Anda membuat cadangan log transaksi Anda setiap, katakanlah, 30 menit maka kehilangan data maksimum Anda adalah 30 menit. Dalam hal itu, jika log transaksi Anda hilang, dan Anda memiliki cadangan lengkap dan rantai log utuh Anda, Anda dapat memulihkan ke cadangan log terakhir itu.

Dokumentasi TechNet tentang Pemotongan Log Transaksi


5

Masalah utama yang Anda hadapi adalah Anda membuat cadangan log sekali sehari. Perilaku mesin adalah bahwa catatan log (ruang yang digunakan) dalam file log hanya akan dihapus setelah cadangan log berhasil. Ruang ini direklamasi ketika sebuah pos pemeriksaan terjadi, tetapi jika database Anda dalam pemulihan Log Penuh / Massal maka catatan log hanya akan dihapus jika mereka telah berhasil dicadangkan.

Cadangan log dimaksudkan untuk digunakan bersama dengan Cadangan penuh dan harus dijalankan secara berkala di antara Cadangan penuh. Interval ini dapat berupa periode apa pun, meskipun saya biasanya menjalankan pencadangan log setiap 15 menit. Interval Anda tergantung pada Recovery Point Objective (RPO) Anda dan berapa banyak data yang dapat Anda hilangkan jika terjadi pemulihan.

Jika Anda melakukan pencadangan log reguler, Anda tidak perlu melakukan penyusutan file biasa karena Anda akan mengelola ruang file log sebelum dipaksa untuk tumbuh.


-1

Saya punya masalah yang sama seperti Anda sebelumnya. File log saya selalu bertambah, alih-alih saya menggunakan cadangan Database lengkap setiap malam. Jadi, inilah solusi saya:

  1. buat cadangan file log Anda saat ini.

  2. Setel Database Anda ke Pemulihan Sederhana

    • Karena Pemulihan Penuh -> File log tidak menghapus transaksi yang dilakukan, itu hanya mengatur ulang data Anda -> File shink tidak terlalu berpengaruh -> dan sebaliknya untuk Pemulihan Sederhana.
  3. Shink file log Anda menjadi 1 MB atau kurang (terserah Anda)

  4. Kembalikan Database Anda ke Pemulihan Penuh.

Semoga ini bisa membantu

Phong Tran

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.