Заметки о Windows и других программных продуктах Microsoft...

Урезание логов в SQL Server 2012

Урезание логов в SQL Server 2012

Логи транзакций в MS SQL имеют обыкновение разрастаться, что иногда может привести к окончанию места на диске. Чтобы этого не происходило, в SQL Server существует операция урезания логов (Truncate). Урезание логов производится автоматически, в зависимости от модели восстановления:

• В простой модели (Simple) — после достижения контрольной точки;
• В модели полного восстановления (Full) — после создания бэкапа логов, при условии что со времени предыдущего бэкапа была достигнута контрольная точка.

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

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

Для урезания лога открываем Management Studio, выбираем нужную базу, кликаем на ней правой клавишей мыши и в открывшемся контекстном меню выбираем пункт «Properties». Переходим на вкладку «Options» и изменяем модель восстановления базы (Recovery model) на Simple.

изменение модели восстановления базы данных

 

Затем в том же контекстном меню переходим в раздел Tasks -> Shrink -> Files. В поле File type выбираем Log, в поле File name указываем имя файла логов. В поле «Shrink action» выбираем «Reorganize pages before releasing unused space», задаем желаемый размер файла и жмем ОК.

урезание файла логов БД

 

После завершения операции возвращаем режим восстановления базы обратно в Full.

Тоже самое можно проделать из Query Analizer с помощью скрипта:

USE ″Имя базы″
ALTER DATABASE ″Имя базы″ SET RECOVERY SIMPLE
DBCC SHRINKFILE (″Имя файла лога″, ″Желаемый размер″);
ALTER DATABASE ″Имя базы″ SET RECOVERY FULL

Это всего лишь  один из способов быстрого уменьшения размера логов. Не самый красивый 🙂 но наиболее простой и эффективный.

 
 
Комментарии
acidborn60

Красивый способ — сделать бэкап лога и шринкануть. Правда и это не всегда помогает, особенно если в БД есть открытые долгоиграющие транзакции. Но метод, описанный в статье — это только на крайний случай.

Андрей

Приведенный скрипт отработал на ура. У меня лог был аж 250 гигов. Большое спасибо.

Владимир

Способ красивый, но… Все предыдущие бекапы сделанные в модели фулл нужно выбрасывать.
И, в статье совершенно не указано, что надо, после этой операции, сделать БЕКАП в модели фулл.
метод на самый простой случай.

почему — выбрасывать? Разве они не развернуться? ) Просто будут актуальны на момент создания этих бэкапов. или нет?

Равиль

тож не сталкивался с такой ситуацией и не сталкиваться, хотя бекапы Ж.Т тож делается, ж.т не бекапниться чтоль?

Если сжатие (шринк) лог-файла происходит после того, как база будет в простое, то бишь пользователей не будет в ней, то файл транзакции в дальнейшем не играет абсолютно никакую роль! Я так и делаю уже на протяжении 10 лет и, тьфу-тьфу, постоянно восстанавливается без проблем!

Leave a Reply to acidborn60