После определенных манипуляций с базой возникают ситуации, когда размер ее файлов превышает разумные пределы (либо, как у меня, в два раза больше положенного 103 Гб вместо 65 Гб, и это только файл базы данных). Данная ситуация разрешается простым шринком.
Приведенные ниже варианты кода довольно просты:
- DBCC shrinkdatabase(N’имя_базы’, TRUNCATE_ONLY) ; — усечение всей базы
- use [имя_базы] DBCC SHRINKFILE (N’имя_базы_Data’, 101); — усечение только файла данных до размера 101 мб
- use [имя_базы] DBCC SHRINKFILE (N’имя_базы_Log’, 0); — усечение только файла транзакций до размера 0 мб
Но при выполнении этой операции могут возникнуть проблемы. Проявляются они в основном на тех базах данных, для которых установлена модель архивирования Full (для модели Simple проблем, как правило, не возникает, далее поясним почему). В сообщениях об ошибке говорится о том, что log-файл находится в использовании, поэтому операцию выполнить невозможно — это более чем удивительно, поскольку обычно процесс шринка производится при завершенной работе пользователей (никто не обращается к базе). Монитор соединений так же показывает отсутствие какой-либо активности.
Прежде, чем выполнять шринк базы необходимо выполнить архивацию, но не всей базы, а именно файла транзакций. Только после завершения этой процедуры можно смело выполнять команду shrink, и результат будет достигнут. Надо сказать, что процедура архивации нужна только, если для базы данных установлена модель архивирования Full. В модели Simple log-файл автоматически помечается, как свободный для использования и команда shrink работает без проблем, в модели Full файл становится свободным для использования только после backup-а соответствующего файла.
Итого, для усечения размера файлов базы SQL 2005 имеет следующий код:
Use ИмяБазы
BACKUP Log[ИмяБазы] WITH TRUNCATE_ONLY
DBCC SHRINKFILE ("ИмяФайлаЛогическое")
Та же операция для SQL 2008 будет выглядеть по другому. Так как нет такого ключа как TRUNCATE_ONLY для команды BACKUP, то можно использовать временный перевод базы режим бекапирования SIMPLE, выполнить усечение файла, и вернуть режим FULL. конечно если изначально такой и был:
USE ИмяБазы
ALTER DATABASE ИмяБазы SET RECOVERY SIMPLE
DBCC SHRINKFILE ("ИмяФайлаЛогическое", 10);
ALTER DATABASEИмяБазы SET RECOVERY FULL
Так же, после проведенных манипуляций никогда не помешает сделать проверку базы. Как обычно переводим базу в монопольный режим (Если необходимо использовать аргументы REPAIR, выполните инструкцию DBCC CHECKDB без параметра восстановления, чтобы узнать требуемый уровень восстановления, и только потом восстановления )
Когда при подключении к базе MS SQL появляются ошибки:
Ошибка СУБД:
Microsoft OLE DB Provider for SQL Server: Журнал транзакций для базы данных «ReportServer» заполнен. Чтобы обнаружить причину, по которой место в журнале не может быть повторно использовано, обратитесь к столбцу log_reuse_wait_desc таблицы
sys. databases HRESULT=80040E14, SQLStvr: Error state=2, Severity=11,native=9002, line=1
или
Ошибка СУБД:
Microsoft OLE Provider for SQL Server: The transaction log for database “ReportServer” is full. To find out why space in the log cannot be reused, see the log_reuse_wait_desc column is sys.database
HRESULT=80040E14, SQLSTATE=4 2000, native=9002
это значит, что на диске, где расположен лог транзакций закончилось место и теперь СУБД некуда записывать данные о новых транзакциях. Чаще всего такое происходит, когда не установлено никаких ограничений на размер лога и в MS SQL не создано соответствующих планов обслуживания.
В таком случае нужно уменьшить размер самого файла транзакций (*.ldf), другими словами сделать шринк (сжатие) лога. Для этого можно использовать как запрос, так и сжатие лога вручную.
Рассмотрим сжатие лога транзакций вручную:
Шаг 1. Установить модель восстановления Простая (Simple). Правой кнопкой на базе — Свойства(Properties)
Далее: Параметры(Options) — 4-й сверху пункт Модель восстановления(Recovery model) — Простая(Simple) — OK.
Выполнить сжатие (Shrink) лога транзакций. Правой кнопкой на базе — Задачи(Tasks) — Сжать(Shrink) — Файлы(Files)
Установить Тип файла(File type) — Журнал(Log) — в Операция сжатия(Shrink action) — выбрать Реорганизовать страницы, перед тем освоить неиспользуемое место(Reorganize pages before releseasing unused space) — Сжать файл (Shrink file to)
указать приемлемый размер лога.
Транзакционные логи в SQL Server 2012 с течением времени неизбежно растут, и в какой-то момент времени могут занять все доступное место на диске. Чтобы избежать такой ситуации, в SQL Server есть средства для урезания (Truncate) транзакционных логов, позволяющие высвободить место для повторного использования. Логи урезаются автоматически в зависимости от используемой модели восстановления:
- Simple (простая модель) — журналы урезаются после достижения контрольной точки
- Full (модель полного восстановления) – после выполнения резервной копии логов, если после последнего бэкапа было достигнута контрольная точка
Однако есть ситуации, когда автоматическое урезание логов не отрабатывает как надо, и файлы логов занимают все место на диске. Как правило, это происходит неожиданно, и администратору приходится срочно решать вопрос с освобождением места на диске.
В этом случае при подключении к БД MS SQL появляется такая ошибка:
Microsoft OLE Provider for SQL Server: The transaction log for database “DBName” is full. To find out why space in the log cannot be reused, see the log_reuse_wait_desc column is sys.database
HRESULT=80040E14, SQLSTATE=4 2000, native=9002
Это означает, что транзакционные логи заняли все свободное место и SQL более не может писать файлы журналов. В этой ситуации вы можете выполнить урезание логов транзакций вручную.
Как правило это ситуация может возникнуть при использовании полной модели восстановления (Full). В этой модели файлы журналов не усекаются, пока все транзакционные логи не попадут в бэкап. Это нужно для того, чтобы гарантировать непрерывную последовательность номеров записей (LSN) в журнале. Таким образом, чтобы журналы урезались, нужно выполнить полный бэкап БД, либо (быстрее), на время сменить модель восстановления на Simple.
Итак, чтобы урезать транзакционный лог, запустите консоль SQL Server Management Studio (SSMS), выберите нужную БД, и откройте ее свойства в контекстном меню. Затем перейдите на вкладку Options и измените модель восстановления БД (Recovery model) на Simple.
Затем в контекстном меню БД выберите Tasks -> Shrink -> File s. В поле 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
Совет . После урезанию транзакционных логов в SQL Server настоятельно рекомендуется создать полную резервную копию БД, т.к. в случае повреждения файлов журнала, вы не сможете восстановить базу с использованием файлов транзакций.
Когда при подключении к базе MS SQL появляются ошибки:
Ошибка СУБД:
Microsoft OLE DB Provider for SQL Server: Журнал транзакций для базы данных «ReportServer» заполнен. Чтобы обнаружить причину, по которой место в журнале не может быть повторно использовано, обратитесь к столбцу log_reuse_wait_desc таблицы
sys. databases HRESULT=80040E14, SQLStvr: Error state=2, Severity=11,native=9002, line=1
или
Ошибка СУБД:
Microsoft OLE Provider for SQL Server: The transaction log for database “ReportServer” is full. To find out why space in the log cannot be reused, see the log_reuse_wait_desc column is sys.database
HRESULT=80040E14, SQLSTATE=4 2000, native=9002
это значит, что на диске, где расположен лог транзакций закончилось место и теперь СУБД некуда записывать данные о новых транзакциях. Чаще всего такое происходит, когда не установлено никаких ограничений на размер лога и в MS SQL не создано соответствующих планов обслуживания.
В таком случае нужно уменьшить размер самого файла транзакций (*.ldf), другими словами сделать шринк (сжатие) лога. Для этого можно использовать как запрос, так и сжатие лога вручную.
Рассмотрим сжатие лога транзакций вручную:
Шаг 1. Установить модель восстановления Простая (Simple). Правой кнопкой на базе — Свойства(Properties)
Далее: Параметры(Options) — 4-й сверху пункт Модель восстановления(Recovery model) — Простая(Simple) — OK.
Выполнить сжатие (Shrink) лога транзакций. Правой кнопкой на базе — Задачи(Tasks) — Сжать(Shrink) — Файлы(Files)
Установить Тип файла(File type) — Журнал(Log) — в Операция сжатия(Shrink action) — выбрать Реорганизовать страницы, перед тем освоить неиспользуемое место(Reorganize pages before releseasing unused space) — Сжать файл (Shrink file to)
указать приемлемый размер лога.
Любое программное обеспечение выполняет определенные функции. Независимо от того, как она это делает по умолчанию в папке с утилитой создается log-файл. Данный файл является текстовым документом, в котором отображаются все действия программы.
Вам понадобится
- Программное обеспечение:
- - любой текстовый редактор;
- - архиватор 7Zip.
