Лучший способ для резервного копирования и усечения журналов транзакций по расписанию

Я не администратор баз данных, но, несмотря на то, что они есть, я должен надеть шляпу администратора баз данных и настроить планы обслуживания для своего экземпляра SQL Server.

Итак, какое-то время у меня был мой ночной процесс служб SSIS, запускающий задачу «Выполнение SQL» для выполнения резервного копирования - в основном выполняемый, master.dbo.xp_create_subdirчтобы убедиться, что целевые папки существуют, а затем BACKUP DATABASE [DbName] TO DISK = 'G:\Backups\DbName\DbName.bak' WITH INIT.

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

Сценарий «ручного усечения» выглядит следующим образом:

use Staging;
alter database Staging set recovery simple
alter database Staging set recovery full
dbcc shrinkfile ('Staging_log', 0, truncateonly);
go

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

Дело в том, что я никогда не делал этого раньше, поэтому у меня есть несколько вопросов:

• Будет ли резервное копирование журналов транзакций автоматически обрезать их, или мне нужно что-то еще сделать?
• Можно ли выполнять резервное копирование данных и журнала транзакций одновременно? Если нет, то как правильно это сделать?
• Файлы резервных копий в одночасье отбираются другим процессом, который захватывает все файлы на сервере и сохраняет их в другом месте. Было бы хорошей идеей истечь срок действия резервного набора через 2 дня? Нужно ли вообще их истекать?
• Задачи очистки соответственно удаляют «старые» файлы .bak и .trn в подпапках G:\Backups. Имеет ли это смысл?
• Было бы лучше сделать это в службах SSIS, чтобы я мог потерять свой ETL, если / когда произойдет сбой резервного копирования? Или мой процесс ETL должен заботиться?

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

Только за ночь SSIS делает записи, дневные - все чтения - мне нужно только ежедневное восстановление.

Вы должны выбрать модель восстановления исходя из потребностей своего бизнеса:

• Сколько данных бизнес может потерять и в то же время выжить?

Основываясь на ответе выше, вы должны тщательно выбрать модель восстановления базы данных .

Проще говоря (не обсуждая модель восстановления с массовой регистрацией) ,

• Модель полного восстановления позволяет создавать резервные копии журналов, что позволяет выполнять восстановление на определенный момент времени.
  • Усечение журнала может произойти, когда вы делаете резервные копии журнала транзакций, т.е. пространство файла журнала будет повторно использоваться после каждого резервного копирования журнала и не будет раздуваться!
• Простая модель восстановления позволяет только создавать ПОЛНЫЕ резервные копии. Восстановление на определенный момент времени невозможно.
  • Усечение журнала может происходить только при возникновении контрольной точки (вручную или автоматически), т. Е. Поскольку вы регулярно выполняете полное резервное копирование, вам не нужно беспокоиться о журнале транзакций, поскольку CHECKPOINT позаботится о повторном использовании неактивной части файла журнала.

Помните, что усечение журнала НЕ является физическим уменьшением размера файла журнала транзакций. Это означает, что неактивная часть файла журнала транзакций помечается как повторно используемая .

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

Я настоятельно рекомендую вам отказаться от планов технического обслуживания и внедрить [умное решение по техническому обслуживанию, которое легко, гибко и следует передовым методам] - 5 . - Решение для резервного копирования Ola (а также решение для обслуживания Index ).

давайте ответим на ваши вопросы:

Будет ли резервное копирование журналов транзакций автоматически обрезать их, или мне нужно что-то еще сделать?

Пожалуйста, не добавляйте резервные копии и не устанавливайте срок их действия. Они создают большой беспорядок. Используйте INITи делайте отдельные резервные копии журнала с отметкой даты и времени. Легко поддерживать. Используйте для этого решение для резервного копирования Ola. Решение является гибким для удаления старых резервных копий.

Можно ли выполнять резервное копирование данных и журнала транзакций одновременно? Если нет, то как правильно это сделать?

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

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

Файлы резервных копий в одночасье отбираются другим процессом, который захватывает все файлы на сервере и сохраняет их в другом месте. Было бы хорошей идеей истечь срок действия резервного набора через 2 дня? Нужно ли вообще их истекать?

Задачи очистки соответственно удаляют «старые» файлы .bak и .trn в подпапках G: \ Backups. Имеет ли это смысл? Было бы лучше сделать это в службах SSIS, чтобы я мог потерять свой ETL, если / когда произойдет сбой резервного копирования? Или мой процесс ETL должен заботиться?

Для обоих выше используйте решение для резервного копирования Ola. Он позаботится об удалении старых файлов.