Модель восстановления SQL Server 2008 / R2

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

Довольно часто и по определенным практическим причинам многие базы данных создаются с использованием SSMS. Однако могут быть допущены ошибки, и оператор может забыть указать модель простого восстановления. Это приводит к «сюрпризу» через несколько дней, когда коробка борется с дисковым пространством из-за трех или четырех файлов журнала размером 60 ГБ, которые никогда не усекались.

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

Я вижу один из трех вариантов здесь:

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

2) Вы можете установить modelпростую базу данных и не беспокоиться об этом.

3) можно надеяться, что все помнят, что похоже на то, что вы делаете. (не рекомендуется)

Я бы лично пошел с номером два. Для этого есть база данных моделей.

Добавление к @ Surfer513

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

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

Эта статья на MSSQLTip.com посвящена проверке на Full, но вы можете легко проверить свою на Simple. Вы также можете добавить проверку, чтобы увидеть, происходило ли когда-либо резервное копирование в базе данных.

Безопасной ставкой является перевод вашей БД в полный режим, но тогда у вас возникнет проблема с ростом журнала. Теперь есть несколько вариантов:

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

Будучи администратором базы данных, вы должны использовать все опции, которые помогают с восстановлением. Это также зависит от вашего SLA с бизнесом.

При всем этом, я управляю несколькими БД в простом режиме. Это из-за отказа от ответственности, изложенного в SLA. Бизнес решил не тратить на диски файлы журналов (вы можете взять лошадь на воду, но вы не можете заставить ее пить). Бизнес управляет резервным копированием, восстановлением и аварийным восстановлением. Был DR, и потерянные деньги были больше, чем это стоило бы в дополнительном дисковом пространстве.