Model pemulihan SEDERHANA atau LENGKAP untuk basis data?

Kapan saya harus menggunakan model pemulihan penuh dan kapan saya harus menggunakan model pemulihan sederhana untuk database?

Saya selalu menggunakan model pemulihan penuh karena ini adalah default, tetapi hari ini saya menemukan kesalahan ini:

Penyedia DB OLE Microsoft untuk SQL Server (0x80040E14) Log transaksi untuk database 'DATABASE NAME' sudah penuh. Untuk mengetahui mengapa ruang dalam log tidak dapat digunakan kembali, lihat kolom log_reuse_wait_desc di sys.databases

Database spesifik sebenarnya adalah salah satu database terkecil dan paling tidak aktif di server saya, jadi saya tidak tahu bagaimana log dapat penuh pada database ini, dan bukan yang lain.

Untuk mengecilkan log dan membuat basis data dapat diakses kembali, saya mengubah model pemulihan dari FULL ke SIMPLE dan menyusutkan log file logis, dengan perintah berikut

alter database myDbName SET recovery simple
go
dbcc shrinkfile('LOG FILE LOGICAL NAME', 100)
go

Itu membantu, tetapi sekarang saya harus mengerti MENGAPA itu membantu, BAGAIMANA situasi ini dimulai dan BAGAIMANA mencegahnya di masa depan?

EDIT:

Setiap malam pada jam 1, kami melakukan backup scripted dari setiap database di server. Ini sedang dilakukan oleh skrip 31 baris di mana bagian paling penting adalah

set @Filename = 'D:\backup\' + convert(varchar, getDate(), 112) + ' - ' + @DBName + '.bak'
set @Description = 'Full backup of database ' + @Filename
BACKUP DATABASE @DBName TO DISK = @Filename WITH INIT , NOUNLOAD , NAME = @Description, NOSKIP , STATS = 10, NOFORMAT

Apakah model pemulihan baru dan penyatuan data akan menjadi konflik dengan skrip ini?

Kami tidak melakukan backup jenis lain dari database, dan karenanya bukan log transaksi, bukan?

Kapan saya harus menggunakan model pemulihan penuh dan kapan saya harus menggunakan model pemulihan sederhana untuk database?

Anda harus menggunakan model pemulihan penuh ketika Anda membutuhkan pemulihan database Anda secara berkala. Anda harus menggunakan model pemulihan sederhana ketika Anda tidak memerlukan pemulihan database Anda secara point-in-time, dan ketika cadangan penuh atau diferensial terakhir cukup sebagai titik pemulihan. (Catatan: ada model pemulihan lain, log masuk massal. Untuk informasi lebih lanjut tentang model pemulihan log-massal lihat referensi ini )

Penyedia DB OLE Microsoft untuk SQL Server (0x80040E14) Log transaksi untuk database 'DATABASE NAME' sudah penuh. Untuk mengetahui mengapa ruang dalam log tidak dapat digunakan kembali, lihat kolom log_reuse_wait_desc di sys.databases

Alasan Anda mendapatkan kesalahan itu (kemungkinan besar) adalah karena Anda belum mencadangkan log transaksi Anda. Ketika tidak dicadangkan, maka akan terus tumbuh secara fisik file log transaksi (asalkan autogrowth diaktifkan dan maxsize memungkinkan) karena tidak dapat menggunakan kembali "bagian" dari log transaksi (file log virtual). Itu hanya dapat menandai VLF tersebut untuk digunakan kembali dan memungkinkan sifat "membungkus" dari log transaksi ketika Anda melakukan backup log transaksi (dan beberapa persyaratan lainnya, seperti tidak ada transaksi aktif, beberapa aspek replikasi, dll.).

Untuk mengecilkan log dan membuat basis data dapat diakses kembali, saya mengubah model pemulihan dari FULL ke SIMPLE dan menyusutkan log file logis, dengan perintah berikut

......

Itu membantu, tapi sekarang saya harus mengerti MENGAPA itu membantu, BAGAIMANA situasi ini dimulai dan BAGAIMANA mencegahnya di masa depan?

Ini membantu Anda karena dengan menetapkan basis data ke model pemulihan sederhana, Anda memberi tahu SQL Server bahwa Anda tidak lagi peduli dengan pemulihan titik-waktu, dan persyaratan untuk memastikan bahwa file log virtual tidak lagi perlu disimpan dan ditandai sebagai aktif, sekarang proses pos pemeriksaan menandai VLF ini sebagai tidak aktif.

Kutipan / kutipan yang diambil dari referensi MSDN ini :

Di bawah model pemulihan sederhana, kecuali beberapa faktor menunda pemotongan log, pos pemeriksaan otomatis memotong bagian yang tidak terpakai dari log transaksi. Sebaliknya, di bawah model pemulihan log penuh dan massal, setelah rantai cadangan log dibuat, pos pemeriksaan otomatis tidak menyebabkan pemotongan log.

Kemudian Anda melakukan penyusutan file basis data fisik dan karena ada ruang kosong di log transaksi Anda sekarang ia dapat menyusutkan secara fisik file NTFS.

Membaca layak menghabiskan beberapa waktu di:

1. Model Pemulihan
2. Mengelola Log Transaksi (Gail Shaw)
3. Faktor-Faktor Yang Dapat Menunda Pemotongan Log

Sunting setelah Edit Anda :

Apakah model pemulihan baru dan penyatuan data akan menjadi konflik dengan skrip ini?

Itu BACKUP DATABASEperintah akan bekerja dengan baik model pemulihan. Adapun menyusut database rutin ... JANGAN MELAKUKANNYA !!!! Serius, ukuran database Anda sesuai, dan jika Anda menggunakan model pemulihan penuh maka pastikan bahwa Anda melakukan file log transaksi rutin dan sering, tidak hanya untuk menjaga ukuran log transaksi tetapi juga untuk memenuhi objek titik pemulihan.

Kami tidak melakukan backup jenis lain dari database, dan karenanya bukan log transaksi, bukan?

Jika database Anda menggunakan model pemulihan penuh, maka ya Anda harus melakukan backup log transaksi. Jika database Anda dalam pemulihan sederhana, maka Anda secara fisik tidak dapat melakukan backup log transaksi.

Mengenai model pemulihan apa yang digunakan (sederhana vs penuh), kami tidak dapat membuat keputusan untuk Anda. Hanya Anda, tim bisnis Anda, dan SLA Anda yang bisa.