Резервное копирование журнала транзакции ms sql. Автоматически. Растет журнал транзакций. Сжатие это удаление?

Question

[wolkir]

Я совсем не БДшник. Просто поставили. БД бекапится от предыдущих. Но я так понимаю вся соль БД заключается в журналах(-е) транзакций. А его вроде не бэкапится. Ибо он растет. Как им управлять и шринк это же обрезание == удаление? а как не удалением.. Невозможно же каждый раз: (Перевести базу данных в режим восстановления – простая (simple).Выбрать файл логов журнала транзакций в списке, посмотреть, насколько уменьшится файл и нажать кнопку “ОК”.) Режимы БДшек у меня полная.

При этом когда сейчас сделал мануальный(ПКМ задачи создать резервную копию) резервная копия журнала без(доп параметра )сжатия его тож весила 25гб. С Параметром 10кб.

КАк правильно делать и ужимать, но не терять тех мифических возможностей восстановления к определенной точке.?

П.с. если не правильно говорю или рассуждаю пинайте объясняйте :)

Comments

[#]

а доки не пробовали читать?

Answer 1

[MVV]

Простой рецепт для простых случаев (никакой репликации).
Сделать 2 раза с небольшим промежутком следующее:
- выполнить резервное копирование журнала;
- обрезать журнал с хвоста (truncate).
Если предполагается использовать журнал для восстановления (к текущему состоянию или к точке во времени) о сделанные резервные копии журнала надо сохранить.

Comments

[wolkir]

не понял, резервное копирования журнала мы делаем в регулярном задании, а обрезаем мы ж должны знать конкретную таблицу в этом truncate , как это использовать?

[MVV]

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

Answer 2

[Денис]

Журнал транзакций (файл ldf) MS SQL может существенно вырасти при соблюдении следующих условий:
0. Установлена Полная модель восстановления.
1. За период времени между операциями BACKUP LOG было зафиксировано большое количество транзакций.
2. По каким-то причинам пункт №1 повторился несколько раз, т.е. транзакции в лог писались, но операция BACKUP LOG не выполнялась. В результате файл может вырасти до огромных размеров (пример из личного опыта: файл данных - 700 Гб, файл логов - 800 Гб).

Для решения проблемы с уже выросшим файлом логов:
1. Сделайте либо полный бэкап (BACKUP DATABASE), либо бэкап логов (BACKUP LOG).
2. Проверьте что файл логов пуст (размер у него останется тот же, но содержимое будет заполнено нулями). Наверняка есть варианты сделать это с помощью T-SQL, но можно через SSMS: ПКМ на имени базы -> Задачи -> Сжать -> Файлы, в появившемся окне в поле "Тип файла" выбираем "Журнал" и ниже сравниваем выделенное и доступное свободное место. Если делали полный бэкап, то выделенное будет существенно больше доступного. Если делали бэкап логов, то они будут практически равны.
3. В той же SSMS переводите базу на Простую модель восстановления и в окне из пункта 2 сжимаете журнал либо полностью, либо до определенного размера (я бы советовал до определенного). Опять же, вышеописанное точно можно сделать с помощью T-SQL.
4. Возвращаете Полную модель восстановления.
5. Для предотвращения подобных ситуаций в будущем, старайтесь настроить бэкап логов почаще (зависит от интенсивности работы с базой, от 15 минут до 1 часа)