Model pemulihan SQL Server 2008 / R2

Hampir semua database kami di server tertentu tidak memerlukan model Pemulihan Lengkap (kami tidak melakukan backup log transaksi) dan defaultnya selalu untuk membuat database dan menentukan model Simple Recovery.

Cukup sering dan untuk alasan praktis tertentu banyak database dibuat menggunakan SSMS. Namun kesalahan dapat dibuat dan operator dapat lupa untuk menentukan model Pemulihan Sederhana. Ini mengarah ke "kejutan" beberapa hari kemudian ketika kotak berjuang dengan ruang disk karena tiga atau empat file log 60GB yang tidak pernah terpotong.

Saya dapat menjadikan model Simple Recovery sebagai pengaturan default untuk database baru dengan mengkonfigurasi model pemulihan pada modeldatabase. Namun, apakah ini direkomendasikan, jika saya melakukan ini, bisakah ia kembali dan menggigit saya dengan cara apa pun di masa depan?

Saya melihat satu dari tiga opsi di sini:

1) Anda dapat memiliki skrip templated untuk membuat basis data yang secara eksplisit menyertakan model pemulihan.

2) Anda dapat mengatur modeldatabase menjadi sederhana dan tidak perlu khawatir tentang ini.

3) Anda bisa berharap semua orang ingat, yang tampaknya seperti apa yang Anda lakukan. (tidak direkomendasikan)

Saya pribadi memilih nomor dua. Itulah tujuan dari model database.

Menambahkan ke @ Surfer513

4) Kebijakan Manajemen Berbasis Kebijakan baik untuk menegakkan model pemulihan sederhana, atau paling banyak memberi tahu Anda ketika DB tidak

Meskipun saya lebih suka pengaturan model ke sederhana ini tidak mencegah perintah T-SQL dari yang digunakan dan pengaturan itu untuk sesuatu yang lain. Anda dapat menggunakan kebijakan untuk mengevaluasi jika model pemulihan tidak Sederhana dan memilih untuk memiliki kebijakan mengubahnya untuk Anda.

Ini artikel MSSQLTip.com adalah pada memeriksa penuh, tetapi Anda dapat dengan mudah hanya Anda memeriksa Simple. Anda juga dapat memberikan cek untuk melihat apakah cadangan pernah terjadi pada basis data juga.

Taruhan aman adalah menempatkan DB Anda dalam mode penuh, tetapi kemudian Anda memiliki masalah pertumbuhan log. Sekarang ada beberapa opsi:

• Beri batasan pada ukuran maksimal file log Anda. Ini akan memengaruhi operasi setelah batas ini tercapai. Manfaatnya adalah itu akan mencegah skenario di mana disk kehabisan ruang dan kemudian Anda akan memiliki masalah yang lebih besar.
• Buat lansiran yang menyala setelah file log Anda tumbuh di atas tanda air dan kemudian kelola.
• Jadwalkan pekerjaan menyusut log. Log shriking merusak kinerja DB Anda. Saya tidak akan menyarankan itu.

Sebagai DBA, Anda harus menggunakan semua opsi yang membantu pemulihan. Ini juga tergantung pada SLA Anda dengan bisnis.

Semua yang dikatakan, saya mengelola beberapa DB dalam mode sederhana. Ini karena penafian yang diuraikan dalam SLA. Bisnis memutuskan untuk tidak menghabiskan drive untuk file log (Anda dapat mengambil kuda ke air, tetapi Anda tidak bisa membuatnya minum). Bisnis mengelola cadangan, pemulihan, dan DR. Ada DR, dan uang yang hilang lebih besar daripada biaya di ruang disk tambahan.