Не удалось сжать файл журнала 2 из за необходимого минимального пространства для журналов
Я хотел сжать файл журнала как можно больше, и поэтому я начал свой поиск, чтобы выяснить, как это сделать. Предостережение: я не DBA (или даже приближаюсь к DBA) и продвигаюсь на ощупь через этот квест.
во-первых, я просто вошел в SSMS, свойства БД, файлы и отредактировал начальное значение размера (МБ) до 10. Что уменьшил файл журнала до 62 ГБ (не совсем 10 МБ, которые я ввел). Итак, я прикрепил SQL Profiler, увидел, что вызывается DBCC SHRINKFILE. Затем я ввел эту команду в Редактор запросов, и вот результаты.
затем я провел некоторое исследование и обнаружил следующее:
который говорит, что мне нужно сделать резервную копию файла журнала перед shrinkfile, чтобы файлы виртуального журнала были выпущены, и shrinkfile может выполнять свою работу - я не знаю, что это значит. Я просто перефразирую здесь:)
Итак, я решил, что попытаюсь создать резервную копию файла журнала, а затем сделать DBCC SHRINKFILE (и я изменил новый размер файла журнала на 12800, так как это был минимальный размер, указанный в выводе предыдущей команды DBCC SHRINKFILE)
результат был таким же, как и первый обход. Я могу получить только файл журнала до 62 ГБ.
Я не уверен, что я делаю неправильно и что я должен попробовать следующий.
в дополнение к шагам, которые вы уже предприняли, вам нужно будет установить режим восстановления на простой, прежде чем вы сможете сжать журнал.
ЭТО НЕ РЕКОМЕНДУЕМАЯ ПРАКТИКА для производственных систем. Вы потеряете возможность восстановления до определенного момента времени из предыдущих резервных копий / файлов журнала.
см. пример B на этом DBCC SHRINKFILE (Transact-SQL) страница MSDN для примера и объяснения.
хорошо, вот решение для уменьшения физического размера файла транзакции, но без изменение режима восстановления на простой.
в базе данных найдите file_id файла журнала, используя следующий запрос.
в моем случае файл журнала-file_id 2. Теперь мы хотим найти используемые виртуальные журналы и сделать это с помощью следующей команды.
здесь вы можете увидеть, используются ли какие-либо виртуальные журналы, увидев если состояние равно 2 (используется) или 0 (бесплатно). При сжатии файлов пустые виртуальные журналы физически удаляются, начиная с конца файла, пока он не достигнет первого используемого состояния. Вот почему сжатие файла журнала транзакций иногда сокращает его частично, но удаляет все бесплатные виртуальные журналы, которые вы можете ожидать.
Если вы заметили состояние 2, которые происходят после 0, это блокирует сокращение от полного сокращения файла. Чтобы обойти это, сделайте еще одну резервную копию журнала транзакций и немедленно запустите эти команды, предоставив file_id, найденный выше, и размер файла журнала, который вы хотели бы уменьшить.
инструкция DBCC shrinkfile команда (столбцом file_id, LogSize_MB)
это покажет распределение виртуального файла журнала, и, надеюсь, вы заметите, что он был несколько уменьшен. Поскольку виртуальные файлы журнала не всегда распределяются по порядку, вам может потребоваться создать резервную копию журнала транзакций пару раз и снова запустить этот последний запрос; но я обычно могу сожмите его в резервную копию или две.
Я использую этот скрипт на sql server 2008 R2.
сокращение файла журнала
для файлов журнала компонент Database Engine использует target_size для вычисления целевого размера для всего журнала; поэтому target_size - это объем свободного места в журнале после операции сжатия. Целевой размер для всего журнала затем преобразуется в целевой размер для каждого файла журнала. DBCC SHRINKFILE пытается немедленно сжать каждый физический файл журнала до целевого размера.
, потому что файл журнала можно сжать только до границы виртуального файла журнала, сжатие файла журнала до размера, меньшего размера виртуального файла журнала, возможно, невозможно, даже если он не используется. При создании или расширении файлов журнала компонент Database Engine динамически выбирает размер виртуального файла журнала.
Если операция сжатия выполняется без ошибок, но размер файла не изменился, убедитесь, что файл имеет достаточное свободное пространство для удаления, выполнив одну из следующих операций:
выполните следующий запрос.
выберите имя, размер / 128.0-CAST(FILEPROPERTY (name, 'SpaceUsed') как int) / 128.0 как AvailableSpaceInMB из sys.database_files;
запустить DBCC SQLPERF возвратить пространства в журнале транзакций.
Если свободного пространства недостаточно, термоусадочная операция не может уменьшить размер файла.
обычно это файл журнала, который не сжимается. Обычно это результат файла журнала, который не был усечен.
вы можете усечь журнал установка базы данных модель восстановления до простой или резервное копирование журнала и DBCC SHRINKFILE операции снова.
пример :
сокращение файла журнала до заданного целевого размера
в следующем примере файл журнала в базе данных AdventureWorks сжимается до 1 МБ. Чтобы команда DBCC SHRINKFILE могла сжать файл, сначала файл усекается, задав для модели восстановления базы данных значение SIMPLE.
использовать Данных adventureworks2012;
GO
-- Усечь журнал, изменив модель восстановления базы данных на простой.
ALTER DATABASE AdventureWorks2012
УСТАНОВИТЬ ВОССТАНОВЛЕНИЕ ПРОСТО;
GO
-- Сократите усеченный файл журнала до 1 МБ.
DBCC SHRINKFILE (AdventureWorks2012_Log, 1);
GO
-- Сброс модели восстановления базы данных.
ALTER DATABASE AdventureWorks2012
УСТАНОВИТЬ ПОЛНОЕ ВОССТАНОВЛЕНИЕ;
GO
при использовании DBCC SHRINKFILE (Logfile, size) он только усекает от конца файла журнала назад, насколько это возможно. Когда он достигает наивысшего виртуального журнала, который все еще используется, он не может сжиматься дальше. Это описано в электронной документации по SQL Server по адресу:
Итак, как только верхний конец журнала ясен, его можно уменьшить в размере. Опять же, это будет зависеть от того, сколько журнала все еще используется. Журнал может быть очищается резервными копиями, но резервные копии не очищают незавершенные транзакции, поэтому журнал может оставаться в высоком VLF даже после повторного резервного копирования.
что касается увеличения и уменьшения VLFs, насколько велик файл журнала, созданный изначально, и какова настройка для роста файла журнала? Если он вырастет только на небольшое количество, он создаст больше VLFs, чем кто-либо желает.
общим шаблоном для сжимать файл журнала будет контрольная точка, подпорка, SHRINKFILE, контрольная точка, Резервное копирование, SHRINKFILE и т. д., Пока вы не получите результаты. Существует много причин, по которым журнал не может быть сжимаемым, включая очень большой откат.
переключение с простого на полный имеет проблему:
здесь есть правила и исключения. Ниже мы поговорим о длительных транзакциях.
но одно предостережение, чтобы иметь в виду для полного режима восстановления: Если вы просто переключитесь в режим полного восстановления, но никогда не принимаете начальную полную резервную копию, SQL Сервер не будет выполнять ваш запрос, чтобы быть в полной модели восстановления. Ваш журнал транзакций будет продолжать работать так же, как и в Simpleuntil вы переключитесь на полную модель восстановления и сделать первую полную резервную копию.
модель полного восстановления без резервных копий журналов-это плохо:
Итак, это самая распространенная причина неконтролируемого роста журнала? Ответ: находясь в режиме полного восстановления без каких-либо резервных копий журнала.
это происходит все время люди.
почему это такая распространенная ошибка?
почему это происходит все время? Поскольку каждая новая база данных получает начальный параметр модели восстановления, просматривая базу данных модели.
начальная настройка модели восстановления модели всегда является полной моделью восстановления-до тех пор, пока кто-то не изменит это. Таким образом, Вы можете сказать, что "модель восстановления по умолчанию" заполнена. Многие люди не знают об этом и имеют свои базы данных работает в полной модели восстановления без резервных копий журнала и, следовательно, файл журнала транзакций намного больше, чем необходимо. Вот почему важно изменить значения по умолчанию, когда они не работают для вашей организации и ее потребностей)
Все верно! Так и делаю.
База в зеркале может из-за этого не работает шринк?!
Вы внимательно читали мой пост?
1. Разбираете зеркало
3. Делаете полную резервную копию базы (правильное решение), или переводите базу в Simple режим восстановления (не правильное).
4. Делаете Shrink файла журнала
Вы внимательно читали мой пост?
1. Разбираете зеркало
.
3. Делаете полную резервную копию базы (правильное решение), или переводите базу в Simple режим восстановления (не правильное).
4. Делаете Shrink файла журнала
Александр, я бы хотел уточнить. и дополнить вопрос.
> 1. Разбираете зеркало
Повлияет ли это на работу базы (клиенты во время разбития зеркала, и после разбития будут ли работать с этой базой)
> Делаете полную резервную копию базы (правильное решение), или переводите базу в Simple режим восстановления (не правильное).
Места нет . 0мб свободно на диске. Куда его делать в сеть сделать нельзя SQL не позволяется сохранять бекапы на сетевой ресурс. (как сделать бекап на сетевой диск)
1. Пользователи работают с активной копией базы, соответственно - нет, не повлияет.
2. или переводите базу в Simple режим восстановления (не правильное).
SQL 2008 r2
Сразу хочу сказать я профан в скриптах и вообще в SQL. Все что я умею, это разворачивать SQL настраивать базы, давать права на базы, делать бекап, настраивать репликацию, зеркало, восстанавливать базу.
Тут такая ситуация, лог базы за несколько дней вырос до максимального значения, заполнил весь диск. То есть на диске место в 0. Сама база вести около 2гб, а лог 100гб с лишнем . Мне бы как то ужать это лог.
Я понимаю что нужно сделать бекап базы, но диск заполнен. База критична к работе. ТО бишь выключать её крайне не желательно. Может поможете советом.
В том, что файл журнал занял весь диск - ничего катастрофичного нет. А вот то, что у вас при полной модели восстановления не выполняются резервные копии журнала транзакций - это плохо (это самая распространённая ошибка начинающих).
Настройте резервное копирование журнала!
Уменьшить размер журнала сможете потом, с оказией.
1. Пользователи работают с активной копией базы, соответственно - нет, не повлияет.
2. или переводите базу в Simple режим восстановления (не правильное).
SQL 2008 r2
Сразу хочу сказать я профан в скриптах и вообще в SQL. Все что я умею, это разворачивать SQL настраивать базы, давать права на базы, делать бекап, настраивать репликацию, зеркало, восстанавливать базу.
Тут такая ситуация, лог базы за несколько дней вырос до максимального значения, заполнил весь диск. То есть на диске место в 0. Сама база вести около 2гб, а лог 100гб с лишнем . Мне бы как то ужать это лог.
Я понимаю что нужно сделать бекап базы, но диск заполнен. База критична к работе. ТО бишь выключать её крайне не желательно. Может поможете советом.
В том, что файл журнал занял весь диск - ничего катастрофичного нет. А вот то, что у вас при полной модели восстановления не выполняются резервные копии журнала транзакций - это плохо (это самая распространённая ошибка начинающих).
Настройте резервное копирование журнала!
Уменьшить размер журнала сможете потом, с оказией.
Журнал бекапируется, были ошибки в работе программы и она послыла кучу запросов в SQL что привело за 2 дня к увеличению объема лога. (как я понял, но журнал я бекаплю)
Все верно! Так и делаю.
База в зеркале может из-за этого не работает шринк?!
Вы внимательно читали мой пост?
1. Разбираете зеркало
3. Делаете полную резервную копию базы (правильное решение), или переводите базу в Simple режим восстановления (не правильное).
4. Делаете Shrink файла журнала
Вы внимательно читали мой пост?
1. Разбираете зеркало
.
3. Делаете полную резервную копию базы (правильное решение), или переводите базу в Simple режим восстановления (не правильное).
4. Делаете Shrink файла журнала
Александр, я бы хотел уточнить. и дополнить вопрос.
> 1. Разбираете зеркало
Повлияет ли это на работу базы (клиенты во время разбития зеркала, и после разбития будут ли работать с этой базой)
> Делаете полную резервную копию базы (правильное решение), или переводите базу в Simple режим восстановления (не правильное).
Места нет . 0мб свободно на диске. Куда его делать в сеть сделать нельзя SQL не позволяется сохранять бекапы на сетевой ресурс. (как сделать бекап на сетевой диск)
1. Пользователи работают с активной копией базы, соответственно - нет, не повлияет.
2. или переводите базу в Simple режим восстановления (не правильное).
SQL 2008 r2
Сразу хочу сказать я профан в скриптах и вообще в SQL. Все что я умею, это разворачивать SQL настраивать базы, давать права на базы, делать бекап, настраивать репликацию, зеркало, восстанавливать базу.
Тут такая ситуация, лог базы за несколько дней вырос до максимального значения, заполнил весь диск. То есть на диске место в 0. Сама база вести около 2гб, а лог 100гб с лишнем . Мне бы как то ужать это лог.
Я понимаю что нужно сделать бекап базы, но диск заполнен. База критична к работе. ТО бишь выключать её крайне не желательно. Может поможете советом.
В том, что файл журнал занял весь диск - ничего катастрофичного нет. А вот то, что у вас при полной модели восстановления не выполняются резервные копии журнала транзакций - это плохо (это самая распространённая ошибка начинающих).
Настройте резервное копирование журнала!
Уменьшить размер журнала сможете потом, с оказией.
1. Пользователи работают с активной копией базы, соответственно - нет, не повлияет.
2. или переводите базу в Simple режим восстановления (не правильное).
SQL 2008 r2
Сразу хочу сказать я профан в скриптах и вообще в SQL. Все что я умею, это разворачивать SQL настраивать базы, давать права на базы, делать бекап, настраивать репликацию, зеркало, восстанавливать базу.
Тут такая ситуация, лог базы за несколько дней вырос до максимального значения, заполнил весь диск. То есть на диске место в 0. Сама база вести около 2гб, а лог 100гб с лишнем . Мне бы как то ужать это лог.
Я понимаю что нужно сделать бекап базы, но диск заполнен. База критична к работе. ТО бишь выключать её крайне не желательно. Может поможете советом.
В том, что файл журнал занял весь диск - ничего катастрофичного нет. А вот то, что у вас при полной модели восстановления не выполняются резервные копии журнала транзакций - это плохо (это самая распространённая ошибка начинающих).
Настройте резервное копирование журнала!
Уменьшить размер журнала сможете потом, с оказией.
Журнал бекапируется, были ошибки в работе программы и она послыла кучу запросов в SQL что привело за 2 дня к увеличению объема лога. (как я понял, но журнал я бекаплю)
У меня есть база данных с файлом журнала транзакций 28gig. Режим восстановления прост. Я просто взял полную резервную копию базы данных, а затем побежал так:
backup log dbmcms with truncate_only
DBCC SHRINKFILE ('Wxlog0', TRUNCATEONLY)
имя БД-db_mcms, а имя файла журнала транзакций-Wxlog0.
Не помогло. Я не знаю, что делать дальше.
спасибо всем за ответы.
мы, наконец, нашли проблему. В sys.databases, log_reuse_wait_desc был равен "репликации". По-видимому, это означает, что SQL Server ожидает завершения задачи репликации, прежде чем сможет повторно использовать пространство журнала.
репликация никогда не использовался на этом БД или сервер когда-то играл с этим db. Мы очистили неправильное состояние, запустив sp_removedbreplication. После того, как мы запустили это, backup log и dbcc shrinkfile работали нормально.
определенно один для мешка хитростей.
вы можете столкнуться с этой проблемой, если ваша база данных настроена на автозапуск журнала, и вы получите много виртуальных файлов журнала.
Запустить DBCC LOGINFO('databasename') & посмотрите на последнюю запись, если это 2, то ваш файл журнала не будет сжиматься. В отличие от файлов данных файлы виртуального журнала нельзя перемещать внутри файла журнала.
вам нужно будет запустить BACKUP LOG и DBCC SHRINKFILE несколько раз, чтобы получить файл журнала для сжатия.
для дополнительных бонусных очков запустите DBBC LOGINFO между журналом & увиливает от
'sp_removedbreplication' не решил проблему для меня, так как SQL только что вернулся, сказав, что база данных не была частью репликации.
Я нашел свой ответ здесь:
в основном мне пришлось создать репликацию, сбросить все указатели репликации на ноль; затем удалить репликацию, которую я только что сделанный. т. е.
вам это не нужно
просто убедитесь, что вы осознаете опасности: смотрите здесь:не обрезать файлы ldf!
этот ответ был снят с здесь и публикуется здесь, если другой поток удаляется:
проблема в том, что у вас есть не распределенный LSN в журнале. Я видел это однажды раньше, не уверен, почему мы не снимаем отметку транзакции реплицируются. Мы проведем внутреннее расследование. Вы можно выполнить следующую команду, чтобы отменить отметку транзакции как replicated
в этот момент Вы должна быть возможность обрезать журнал.
У меня была такая же проблема в прошлом. Обычно сжатие и резервное копирование trn должны происходить несколько раз. В крайних случаях я устанавливаю БД на "простое" восстановление, а затем запускаю операцию сжатия файла журнала. Это всегда срабатывает. Однако недавно у меня была ситуация, когда это не сработало бы. Проблема была вызвана длительным запросом, который не был завершен, поэтому любые попытки сокращения были бесполезны, пока я не смог убить этот процесс, а затем запустить мои операции сокращения. Мы говорим журнала файл, который вырос до 60 ГБ и теперь уменьшен до 500 МБ.
помните, как только вы измените с полного на простой режим восстановления и сделать сокращение, не забудьте установить его обратно в полный. Затем сразу после этого вы должны сделать полную резервную копию БД.
Если вы установите режим восстановления в базе данных в 2005 году (не знаю, до 2005 года), он отбросит файл журнала все вместе, а затем вы можете вернуть его в режим полного восстановления, чтобы перезапустить/воссоздать файл журнала. Мы столкнулись с этим с SQL 2005 express в том, что мы не могли приблизиться к пределу 4GB с данными, пока мы не изменили режим восстановления.
Я знаю, что это несколько лет, но хотел бы добавить некоторую информацию.
Я нашел в очень больших журналах, в частности, когда БД не была настроена на резервное копирование журналов транзакций (журналы были очень большими), первая резервная копия журналов не устанавливала log_reuse_wait_desc ни на что, но оставляла статус все еще резервного копирования. Это заблокирует мозгоправа. Запуск резервной копии во второй раз правильно сбросит log_reuse_wait_desc ни к чему, позволяя сжатию обрабатывать.
вы пробовали из среды SQL Server management studio с GUI. Щелкните правой кнопкой мыши по базе данных, задачам, сжатию, файлам. Выберите тип файла-журнал.
Я работал на себя неделю назад.
попробуйте создать другую полную резервную копию после резервного копирования журнала w / truncate_only (IIRC вы должны сделать это в любом случае, чтобы поддерживать цепочку журналов). В простом режиме восстановления ваш журнал не должен сильно расти, так как он эффективно усекается после каждой транзакции. Затем попробуйте указать размер файла журнала, например
опция TRUNCATEONLY не переставляет страницы внутри файла журнала, поэтому у вас может быть активная страница в "конце" вашего файла, которая может предотвратить его усыхание.
вы также можете использовать DBCC SQLPERF(LOGSPACE), чтобы убедиться, что в файле журнала действительно есть свободное место.
попробуйте использовать целевой размер, который вам нужен для усечения только в DBCC:
DBCC SHRINKFILE ('Wxlog0', 1)
и проверьте это на статьи:
вы можете попытаться переместить выделенные страницы в начало файла журнала сначала с помощью
DBCC SHRINKFILE ('Wxlog0', NOTRUNCATE)
DBCC SHRINKFILE ('Wxlog0', 1)
верните БД в полный режим, запустите резервную копию журнала транзакций (а не только полную резервную копию), а затем уменьшите.
после того, как он сжат, вы можете вернуть БД в простой режим, и его журнал txn останется того же размера.
вы не можете сжать журнал транзакций меньше, чем его первоначально созданный размер.
Я пробовал все перечисленные решения, и никто из них не работал. В итоге мне пришлось сделать sp_detach_db, затем удалить файл ldf и повторно подключить базу данных, заставив ее создать новый файл ldf. Это сработало.
У меня была та же проблема. Я запустил процесс дефрагментации индекса, но журнал транзакций стал полным, и процесс дефрагментации ошибся. Журнал транзакций оставался большим.
Я создал резервную копию журнала транзакций, а затем продолжил сжимать журнал транзакций .файл LDF. Однако журнал транзакций не уменьшился вообще.
затем я выдал "контрольную точку", а затем" DBCC DROPCLEANBUFFER " и смог сжать журнал транзакций .ldf файл после
Все верно! Так и делаю.
База в зеркале может из-за этого не работает шринк?!
Вы внимательно читали мой пост?
1. Разбираете зеркало
3. Делаете полную резервную копию базы (правильное решение), или переводите базу в Simple режим восстановления (не правильное).
4. Делаете Shrink файла журнала
Вы внимательно читали мой пост?
1. Разбираете зеркало
.
3. Делаете полную резервную копию базы (правильное решение), или переводите базу в Simple режим восстановления (не правильное).
4. Делаете Shrink файла журнала
Александр, я бы хотел уточнить. и дополнить вопрос.
> 1. Разбираете зеркало
Повлияет ли это на работу базы (клиенты во время разбития зеркала, и после разбития будут ли работать с этой базой)
> Делаете полную резервную копию базы (правильное решение), или переводите базу в Simple режим восстановления (не правильное).
Места нет . 0мб свободно на диске. Куда его делать в сеть сделать нельзя SQL не позволяется сохранять бекапы на сетевой ресурс. (как сделать бекап на сетевой диск)
1. Пользователи работают с активной копией базы, соответственно - нет, не повлияет.
2. или переводите базу в Simple режим восстановления (не правильное).
SQL 2008 r2
Сразу хочу сказать я профан в скриптах и вообще в SQL. Все что я умею, это разворачивать SQL настраивать базы, давать права на базы, делать бекап, настраивать репликацию, зеркало, восстанавливать базу.
Тут такая ситуация, лог базы за несколько дней вырос до максимального значения, заполнил весь диск. То есть на диске место в 0. Сама база вести около 2гб, а лог 100гб с лишнем . Мне бы как то ужать это лог.
Я понимаю что нужно сделать бекап базы, но диск заполнен. База критична к работе. ТО бишь выключать её крайне не желательно. Может поможете советом.
В том, что файл журнал занял весь диск - ничего катастрофичного нет. А вот то, что у вас при полной модели восстановления не выполняются резервные копии журнала транзакций - это плохо (это самая распространённая ошибка начинающих).
Настройте резервное копирование журнала!
Уменьшить размер журнала сможете потом, с оказией.
1. Пользователи работают с активной копией базы, соответственно - нет, не повлияет.
2. или переводите базу в Simple режим восстановления (не правильное).
SQL 2008 r2
Сразу хочу сказать я профан в скриптах и вообще в SQL. Все что я умею, это разворачивать SQL настраивать базы, давать права на базы, делать бекап, настраивать репликацию, зеркало, восстанавливать базу.
Тут такая ситуация, лог базы за несколько дней вырос до максимального значения, заполнил весь диск. То есть на диске место в 0. Сама база вести около 2гб, а лог 100гб с лишнем . Мне бы как то ужать это лог.
Я понимаю что нужно сделать бекап базы, но диск заполнен. База критична к работе. ТО бишь выключать её крайне не желательно. Может поможете советом.
В том, что файл журнал занял весь диск - ничего катастрофичного нет. А вот то, что у вас при полной модели восстановления не выполняются резервные копии журнала транзакций - это плохо (это самая распространённая ошибка начинающих).
Настройте резервное копирование журнала!
Уменьшить размер журнала сможете потом, с оказией.
Журнал бекапируется, были ошибки в работе программы и она послыла кучу запросов в SQL что привело за 2 дня к увеличению объема лога. (как я понял, но журнал я бекаплю)
Читайте также: