Bagaimana menyusutkan file log SQL Server mempengaruhi kinerja?

Saya memiliki database SQL Server 2008 yang memiliki file data berukuran 2GB, tetapi file log lebih dari 8GB. Dengan database pra-2008 saya bisa menggunakan 'Backup log' dan TRUNCATE_ONLYopsi tapi ini tidak lagi tersedia dengan database 2008 dan kemudian.

Saya memiliki skrip yang memotong file log:

USE [MyDatabase]
GO
ALTER DATABASE [MyDatabase] SET RECOVERY SIMPLE WITH NO_WAIT
DBCC shrinkfile('MyDatabase_log', 1)
ALTER DATABASE [MyDatabase] SET RECOVERY FULL WITH NO_WAIT
GO

Ini memotong file log sepenuhnya, tetapi pertanyaan saya adalah: Apakah ini mempengaruhi kinerja?

Saya melakukan dua backup penuh setiap hari sehingga log seharusnya tidak benar-benar diperlukan sejauh menyangkut data roll-forward.

Saya sangat merekomendasikan membaca Pentingnya manajemen ukuran log transaksi yang tepat oleh Paul S. Randal.

Intinya adalah bahwa hanya ada dua cara yang sangat baik untuk melakukan penanganan transaksi log :

1. Entah pergi dengan cadangan file LOG biasa dan file LOG akan menggunakan kembali ruang itu setelah setiap cadangan LOG dan tidak akan tumbuh tanpa batas waktu, atau

2. Gunakan model pemulihan SEDERHANA dan Anda tidak perlu peduli tentang ukuran file LOG Anda, karena Anda melakukan pencadangan penuh secara teratur.

Yang menjadi perhatian pemotongan dan kinerja file LOG adalah bahwa Anda akan selalu mendapatkan hit kinerja ketika file LOG akan ditingkatkan (kutipan dari posting blog yang terhubung di atas):

Jika Anda mengecilkan log, maka itu akan tumbuh lagi - mungkin menyebabkan fragmentasi VLF, dan pasti menyebabkan beban kerja Anda berhenti sementara log tumbuh, karena log tidak dapat menggunakan inisialisasi instan [...]

Pembaruan: Jangan salah pemotongan file LOG karena menyusutnya file DATA. Penyusutan file DATA benar-benar buruk. Lihat Mengapa Anda tidak harus mengecilkan file data Anda untuk detailnya.

OK dulu ya log itu diperlukan bahkan dengan backup harian penuh jika Anda ingin melakukan recover jika terjadi masalah. Kami membuat cadangan log transaksi kami setiap 15 menit. Masalahnya adalah Anda tidak mencadangkan log transaksi Anda dan itulah mengapa log tersebut tumbuh dengan sangat keterlaluan. Anda seharusnya hampir tidak perlu mengecilkan log transaksi jika Anda melakukan backup log transaksi yang benar.

Anda harus mencadangkan basis data sebelum memotong log. Saya sarankan melakukannya di luar jam sehingga tidak ada data baru yang dimasukkan antara cadangan dan pemotongan. Kemudian siapkan cadangan log transaksi yang tepat agar Anda tidak pernah mengalami masalah ini lagi.

Mengenai mempengaruhi kinerja, baik tanpa mengetahui detail perangkat keras dan penggunaan sistem Anda, itu akan sulit untuk dikatakan.

Seberapa cepat log transaksi tumbuh? Jika agak cepat, Anda akan memengaruhi kinerja dengan mengecilkannya hingga mendekati nol, karena harus menghabiskan waktu untuk menumbuhkannya kembali. Ini tidak berarti Anda tidak boleh menyusut dari waktu ke waktu, tetapi Anda harus memikirkan masalah ukuran alih-alih hanya menyusut menjadi minimum. Apakah perf hitnya besar? Mungkin tidak, tetapi itu tergantung pada beban di server (jumlah transaksi, dll).

Satu hal yang saya anggap bermasalah adalah "Saya melakukan 2 backup penuh setiap hari sehingga log tidak benar-benar diperlukan sejauh menyangkut roll-forward data." Log sangat penting untuk poin antara cadangan lengkap Anda. Bahkan dua kali sehari tidak menghilangkan kebutuhan untuk file log untuk pemulihan bencana, kecuali jika ini adalah database hanya baca (jika itu, Anda tidak akan melihat peningkatan besar dalam file log, namun).