Как через SQL 2016 в планировщике сжать и почистить log.ldf (лог транзакций) файл от базы данных?

Question

[kipishio kipishio]

Всем привет.
Из за большого размера файла log.ldf, который стал примерно 150Gb и является историей транзакция базы данных SQL, возникла необходимость его уменьшить
Файл позволяет вернуться к любой точке времени и восстановить базу на указанное время.

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

Подскажите как через планировщик настроить сжатие и очистку этого файла после успешно сделанного бэкапа?

Answer 1

[Владимир Коротенко]

DBCC SHRINKDATABASE (AdventureWorks2012, TRUNCATEONLY);

https://docs.microsoft.com/ru-ru/sql/t-sql/databas...

Comments

[kipishio kipishio]

Спасибо. Уже смотрю мануал.

Answer 2

[unfilled]

Файл позволяет вернуться к любой точке времени и восстановить базу на указанное время.

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

Подскажите как через планировщик настроить сжатие и очистку этого файла после успешно сделанного бэкапа?

Полный бэкап не влияет усечение журнала транзакций. Если ваша база в полной модели восстановления (что, видимо, так), и вы делаете только полные резервные копии - ваш журнал транзакций будет только расти, сколько бы шринков (DBCC SHRINKDATABASE/SHRINKFILE) вы не делали.

Грамотный подход для того, чтобы не страдать от разрастания журнала транзакций: почитать про модели восстановления; виды резервных копий (включая резервные копии журнала транзакций); настроить резервное копирование журнала транзакций с такой частотой, которая обеспечит оптимальные для вас: размер файла журнала транзакций и объём допустимой потери данных; разово обрезать журнал транзакций с помощью DBCC SHRINKFILE.

Быстрый подход: перевести бд в простую модель восстановления (alter database set recovery simple), выполнить инструкцию из первого ответа и забыть про рост журнала транзакций и восстановление на момент времени.

Comments

[kipishio kipishio]

Понятно. Получается лучше не мучатся, а делать полный бэкап и из него восстанавливать и все.

Answer 3

[kipishio kipishio]

ваш журнал транзакций будет только расти, сколько бы шринков (DBCC SHRINKDATABASE/SHRINKFILE) вы не делали.

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

Comments

[unfilled]

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

[kipishio kipishio]

unfilled, Я делаю бэкапы журналов транзакций каждые 3 часа

[unfilled]

kipishio kipishio, Если вы делаете бэкап журнала транзакций каждые три часа и ваш журнал регулярно вырастает - у вас происходит большое количество изменений. Когда место в ЖТ заканчивается, он увеличивается в размере и всё новое выделенное ему место, он заполняет нулями. Пока SQL Server не закончит занулять место в выделенном куске, ваша база, фактически, находится в режиме Read-only.
Оно вам надо? Если при выбранной частоте бэкпов ЖТ его размер вам кажется слишком большим, делайте бэкапы ЖТ чаще. Это я к тому, что разово обрезать журнал транзакций после какой-то массовой модификации данных - это норм. Добавлять обрезку в планировщик - в 99% случаев не лучшая идея.