Транзакционные логи в SQL Server 2012 с течением времени неизбежно растут, и в какой-то момент времени могут занять все доступное место на диске. Чтобы избежать такой ситуации, в SQL Server есть средства для урезания (Truncate) транзакционных логов, позволяющие высвободить место для повторного использования. Логи урезаются автоматически в зависимости от используемой модели восстановления:
- Simple (простая модель) — журналы урезаются после достижения контрольной точки
- Full (модель полного восстановления) – после выполнения резервной копии логов, если после последнего бэкапа было достигнута контрольная точка
Однако есть ситуации, когда автоматическое урезание логов не отрабатывает как надо, и файлы логов занимают все место на диске. Как правило, это происходит неожиданно, и администратору приходится срочно решать вопрос с освобождением места на диске.
В этом случае при подключении к БД MS SQL появляется такая ошибка:
HRESULT=80040E14, SQLSTATE=4 2000, native=9002
Это означает, что транзакционные логи заняли все свободное место и SQL более не может писать файлы журналов. В этой ситуации вы можете выполнить урезание логов транзакций вручную.
Как правило это ситуация может возникнуть при использовании полной модели восстановления (Full). В этой модели файлы журналов не усекаются, пока все транзакционные логи не попадут в бэкап. Это нужно для того, чтобы гарантировать непрерывную последовательность номеров записей (LSN) в журнале. Таким образом, чтобы журналы урезались, нужно выполнить полный бэкап БД, либо (быстрее), на время сменить модель восстановления на Simple.
Итак, чтобы урезать транзакционный лог, запустите консоль SQL Server Management Studio (SSMS), выберите нужную БД, и откройте ее свойства в контекстном меню. Затем перейдите на вкладку Options и измените модель восстановления БД (Recovery model) на Simple.
Затем в контекстном меню БД выберите Tasks -> Shrink -> Files. В поле File type выберите Log, а в поле File name – имя файла логов. В поле Shrink action нужно указать Reorganize pages before releasing unused space, и укажите до какого размера нужно ужать файл и нажмите OK.
После урезания лога, опять переключитесь на полную (Full)модель восстановления БД.
Все рассмотренные выше операции можно выполнить простым скриптом из Query Analizer (скрипт работает в SQL Server, начиная с 2008 версии).
USE ″DBName″
ALTER DATABASE ″DBName″ SET RECOVERY SIMPLE
DBCC SHRINKFILE (″DBName″, ″Размер до которого урезать лог″);
ALTER DATABASE ″DBName″ SET RECOVERY FULL
на 2019 не работает:
«Параметр 2 недопустим для данной инструкции DBCC»
Он с MSSQL 2008 не работает.
А как сделать если база в базы в Always on?
Нужно вывести временно базу из Always on, сделать шринк и потом опять добавить в Always on
вывести базу из группы, перевести в симпл, сделать шринк, перевести в фулл, сделать фуллбекап, удалить копии базы с вторичных реплик, ввести базу в группу
на картинке указано, что «Available free space» 296,35 Mb (0%).
Разве пройдет при этом shrink File? Разве для shrinka не должно быть наоборот, свободного места под 99%?
А какое преимущество выбирать в качестве Shrink action «Reorganize pages before releasing unused space», указывая при этом до какого размера сжимать лог… ведь после того как я удалил с Терабайт журнала транзакций, мне эти огрызочные 100 Мегабайт ничто не дадут в принципе).
Я верно понимаю, что выбирая «Release unused space», мы ничего не теряем, от слова совсем?
По сути, да можно.
В Simple модели восстановления данные хотя и пишутся в транзакционные журналы, но тут же удаляются автоматически.
Скрипт кому нужен :
USE [DBName];
GO
ALTER DATABASE [DBName] SET RECOVERY SIMPLE;
GO
— Узнайте имя файла журнала, если оно неизвестно
— EXEC sp_helpfile;
DBCC SHRINKFILE (N’DBName_log’, 10); — Укажите имя файла журнала и размер без кавычек
GO
ALTER DATABASE [DBName] SET RECOVERY FULL;
GO