@wolkir

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

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

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

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

П.с. если не правильно говорю или рассуждаю пинайте объясняйте :)662a1aeba5a1e306821492.jpeg
  • Вопрос задан
  • 216 просмотров
Пригласить эксперта
Ответы на вопрос 2
@mvv-rus
Настоящий админ AD и ненастоящий программист
Простой рецепт для простых случаев (никакой репликации).
Сделать 2 раза с небольшим промежутком следующее:
- выполнить резервное копирование журнала;
- обрезать журнал с хвоста (truncate).
Если предполагается использовать журнал для восстановления (к текущему состоянию или к точке во времени) о сделанные резервные копии журнала надо сохранить.
Ответ написан
@denilenko
Журнал транзакций (файл 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 часа)
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы