Модель відновлення SQL Server 2008 / R2

Досить багато всіх наших баз даних на певних серверах не потребують моделі повного відновлення (ми не робимо резервного копіювання журналу транзакцій), а за замовчуванням завжди слід створювати бази даних та вказувати просту модель відновлення.

Досить часто і з певних практичних причин багато баз даних створюються за допомогою SSMS. Однак можуть бути допущені помилки, і оператор може забути вказати модель простого відновлення. Це призводить до "несподіванки" через кілька днів, коли вікно бореться з дисковим простором через три-чотири 60-log журнальних файлів, які ніколи не були усічені.

Я можу зробити модель простого відновлення за замовчуванням для нових баз даних, налаштувавши модель відновлення в modelбазі даних. Однак, чи рекомендується це, якщо я це зробити, чи могло б це повернутися і кусати мене в майбутньому?

Тут я бачу один із трьох варіантів:

1) у вас може бути шаблонний сценарій для створення баз даних, що явно включає модель відновлення.

2) ви можете встановити modelбазу даних просто, і не потрібно з цього приводу хвилюватися.

3) Ви можете сподіватися, що всі пам’ятають, що схоже на те, що ви робите. (не рекомендовано)

Я б особисто пішов з номером два. Саме для цього існує база даних моделей.

Додавання до @ Surfer513

4) Політика управління на основі політики або для застосування простої моделі відновлення, або, щонайбільше, повідомляє про те, коли БД немає

Хоча я віддаю перевагу, щоб модель налаштування була простою, це не заважає команді T-SQL використовувати та встановлювати її на щось інше. Ви можете використовувати політику, щоб оцінити, чи модель відновлення не є простою, і вирішити, щоб політика змінила її для вас.

Ця стаття MSSQLTip.com перевіряє на повне, але ви можете легко просто перевірити свій простий. Ви також можете запустити чек, щоб перевірити, чи не було раніше резервної копії в базі даних.

Безпечна ставка - це переведення вашої БД у повний режим, але тоді у вас виникне проблема зростання журналу. Зараз є кілька варіантів:

• Поставте обмеження на максимальний розмір вашого журналу. Це вплине на операції, коли ця межа буде досягнута. Перевага полягає в тому, що вона запобіжить сценарії, коли на диску не вистачить місця, і тоді у вас виникнуть більші проблеми.
• Створіть сповіщення, що з’являються, коли ваш файл журналу виросте над водяним знаком, а потім керуйте ним.
• Розклад робочих місць для скорочення журналу. Скорочення журналу шкодить продуктивності вашої БД. Я б не запропонував цього.

Будучи DBA, ви повинні використовувати всі варіанти, які допомагають відновити. Це також залежить від вашої угоди про угод з бізнесом.

Враховуючи це, я управляю кількома БД в простому режимі. Це відбувається через відмову від відповідальності, викладену у угоді про угода про угоду. Бізнес вирішив не витрачати на накопичувачі файли журналів (можна взяти коня до води, але ви не можете його пити). Бізнес керує резервним копією, відновленням та DR. З'явився ДР, а втрачені гроші були більшими, ніж коштувало б це додаткове місце на диску.