Dbcc shrinkfile не уменьшает файл
Я хотел сжать файл журнала как можно больше, и поэтому я начал свой поиск, чтобы выяснить, как это сделать. Предостережение: я не 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, чем кто-либо желает.
Аргументы
file_name
Логическое имя файла, предназначенного для сжатия.
file_id
Идентификационный номер (идентификатор) файла, предназначенного для сжатия. Чтобы получить идентификатор файла, используйте системную функцию FILE_IDEX или выполните запрос к представлению каталога sys.database_files в текущей базе данных.
target_size
Целое число, которое обозначает новый размер файла в мегабайтах. Если значение не указано или указан 0, инструкция DBCC SHRINKFILE уменьшает файл до его размера при создании.
Размер пустого файла по умолчанию можно уменьшить с помощью инструкции DBCC SHRINKFILE target_size. Например, при создании файла с размером 5 МБ и последующем уменьшении размера до 3 МБ, в то время как файл остается пустым, размер файла по умолчанию задается равным 3 МБ. Это правило применимо только к пустым файлам, в которых никогда не содержались данные.
Контейнеры файловых групп FILESTREAM не поддерживают этот параметр.
Если он указан, то инструкция DBCC SHRINKFILE пытается сжать файл до размера target_size. Используемые страницы в освобождаемой области файла перемещаются в свободное пространство в сохраняемых областях файла. Например, для файла данных размером 10 МБ при операции DBCC SHRINKFILE с target_size 8 все используемые страницы будут перемещены из последних 2 МБ файла на произвольные нераспределенные страницы в первых 8 МБ этого же файла. DBCC SHRINKFILE не сжимает файл не более, чем это нужно для хранимых данных. Например, если в файле данных, размер которого составляет 10 МБ, используется 7 МБ, инструкция DBCC SHRINKFILE со значением аргумента target_size, равным 6, сжимает файл только до 7 МБ, а не до 6 МБ.
EMPTYFILE
Переносит все данные из указанного файла в другие файлы в той же файловой группе. Другими словами, EMPTYFILE переносит данные из указанного файла в другие файлы в той же файловой группе. EMPTYFILE гарантирует, что новые данные не будут добавлены в файл, даже если в него разрешена запись. Для удаления файла можно использовать инструкцию ALTER DATABASE. Если с помощью инструкции ALTER DATABASE изменяется размер файла, флаг "только для чтения" сбрасывается, позволяя добавлять данные.
В контейнерах файловых групп FILESTREAM нельзя удалить файл с помощью ALTER DATABASE до тех пор, пока не будет выполнен сборщик мусора FILESTREAM, который удалит все ненужные файлы в контейнере файловых групп, скопированные в другой контейнер с помощью EMPTYFILE. Дополнительные сведения см. в статье sp_filestream_force_garbage_collection (Transact-SQL)
Сведения об удалении контейнера FILESTREAM см. в соответствующем разделе в статье Параметры инструкции ALTER DATABASE для файлов и файловых групп (Transact-SQL)
NOTRUNCATE
Позволяет переместить распределенные страницы из конца файла данных на нераспределенные страницы в начале файла с указанием или без указания target_percent. Свободное место в конце файла не возвращается операционной системе, а физический размер файла не изменяется. Таким образом, если указан аргумент NOTRUNCATE, сжатие файла незаметно. Аргумент NOTRUNCATE применим только к файлам данных. На файлы журнала он не влияет. Контейнеры файловых групп FILESTREAM не поддерживают этот параметр.
TRUNCATEONLY
Возвращает операционной системе все свободное пространство в конце файла, но не перемещает страницы внутри файла. Файл данных сокращается только до последнего выделенного экстента. Аргумент target_size не учитывается, если указан аргумент TRUNCATEONLY.
Параметр TRUNCATEONLY не переносит сведения в журнале, но удаляет неактивные VLF в конце файла журнала. Контейнеры файловых групп FILESTREAM не поддерживают этот параметр.
общим шаблоном для сжимать файл журнала будет контрольная точка, подпорка, SHRINKFILE, контрольная точка, Резервное копирование, SHRINKFILE и т. д., Пока вы не получите результаты. Существует много причин, по которым журнал не может быть сжимаемым, включая очень большой откат.
переключение с простого на полный имеет проблему:
здесь есть правила и исключения. Ниже мы поговорим о длительных транзакциях.
но одно предостережение, чтобы иметь в виду для полного режима восстановления: Если вы просто переключитесь в режим полного восстановления, но никогда не принимаете начальную полную резервную копию, SQL Сервер не будет выполнять ваш запрос, чтобы быть в полной модели восстановления. Ваш журнал транзакций будет продолжать работать так же, как и в Simpleuntil вы переключитесь на полную модель восстановления и сделать первую полную резервную копию.
модель полного восстановления без резервных копий журналов-это плохо:
Итак, это самая распространенная причина неконтролируемого роста журнала? Ответ: находясь в режиме полного восстановления без каких-либо резервных копий журнала.
это происходит все время люди.
почему это такая распространенная ошибка?
почему это происходит все время? Поскольку каждая новая база данных получает начальный параметр модели восстановления, просматривая базу данных модели.
начальная настройка модели восстановления модели всегда является полной моделью восстановления-до тех пор, пока кто-то не изменит это. Таким образом, Вы можете сказать, что "модель восстановления по умолчанию" заполнена. Многие люди не знают об этом и имеют свои базы данных работает в полной модели восстановления без резервных копий журнала и, следовательно, файл журнала транзакций намного больше, чем необходимо. Вот почему важно изменить значения по умолчанию, когда они не работают для вашей организации и ее потребностей)
Эта инструкция позволяет сжать указанный файл данных или журнала в текущей базе данных. С помощью инструкции можно переместить данные из одного файла в другие файлы в той же файловой группе, одновременно очищая файл и разрешая его удаление из базы данных. Вы можете сжать файл до меньшего размера, чем при создании, указав новое значение для минимального размера файла.
Сжатие файла журнала до указанного целевого размера
В следующем примере файл журнала в базе данных AdventureWorks сжимается до 1 МБ. Чтобы разрешить команде DBCC SHRINKFILE сжать файл, сначала необходимо усечь его, установив значение SIMPLE в модели восстановления базы данных.
Сжатие файла журнала
Так как файл журнала можно сжать только до границы виртуального файла журнала, сжать файл журнала до меньшего размера, чем у виртуального файла журнала, нельзя, даже если он не используется. Компонент Компонент Database Engine динамически выбирает размер виртуального файла журнала при его создании или расширении.
Комментарии
Инструкция DBCC SHRINKFILE применяется к файлам в текущей базе данных. Дополнительные сведения об изменении текущей базы данных см. в статье USE (Transact-SQL).
Вы можете в любой момент остановить операцию DBCC SHRINKFILE, и вся выполненная работа сохранится. Если вы отмените операцию, для которой указан параметр EMPTYFILE, маркировка файла, предотвращающая добавление новых данных, не устанавливается.
В случае сбоя операции DBCC SHRINKFILE возникает ошибка.
Во время сжатия файла в базе данных могут работать другие пользователи, то есть однопользовательский режим для базы данных не требуется. Для сжатия системных баз данных не обязательно запускать экземпляр SQL Server в однопользовательском режиме.
Файл не сжимается
Если размер файла не изменяется после сжатия, которое было выполнено без ошибок, проверьте, есть свободное место в файле, с помощью следующей команды:
- Выполните следующий запрос.
- Выполните команду DBCC SQLPERF, чтобы освободить пространство, используемое журналом транзакций.
Если свободного пространства недостаточно, сжатие не поможет уменьшить размер файла.
Чаще всего результаты сжатия незаметны для файлов журнала. Такая несжимаемость характерна для неусеченных файлов журнала. Чтобы усечь файл журнала, установите значение SIMPLE для модели восстановления базы данных или создайте резервную копию журнала и снова выполните операцию DBCC SHRINKFILE.
Обзор
В Microsoft SQL Server 2005 можно сжать файл журнала транзакций в базе данных для удаления неиспользуемых страниц. Компонент database engine эффективно использует пространство. Тем не менее когда неожиданно роста файла журнала транзакций, может потребоваться вручную сжать файл журнала транзакций.
В данной статье описывается, как с помощью инструкции DBCC SHRINKFILE сжать файл журнала транзакций вручную в полной модели восстановления базы данных SQL Server 2005. Метод, который можно использовать для уменьшения размера файла журнала транзакций в SQL Server 2005 может отличаться от метода, используемого для уменьшения размера файла журнала транзакций в SQL Server 2000. Дополнительные сведения о процедуре уменьшения файла журнала транзакций в SQL Server 2000 щелкните следующий номер статьи базы знаний Майкрософт:
Сжатие журнала транзакций в SQL Server 2000 с DBCC SHRINKFILE 272318
Сведения о накопительном пакете обновления
Накопительное обновление 2 для SQL Server 2012 с пакетом обновления 1 (SP1)
Исправление для этой проблемы впервые выпущено в накопительном обновлении 2. Для получения дополнительных сведений о том, как получить этот накопительный пакет обновления для SQL Server 2012 с пакетом обновления 1 (SP1), щелкните следующий номер статьи базы знаний Майкрософт:
2790947 Накопительный пакет обновления 2 для SQL Server 2012 с пакетом обновления 1 (SP1)Примечание. Поскольку сборки являются кумулятивными, каждый новый набор исправлений содержит все исправления и все исправления системы безопасности, которые были включены в предыдущий выпуск исправлений для SQL Server 2012 с пакетом обновления 1 (SP1). Рекомендуется установить последнюю версию исправления, которая включает это исправление. Дополнительные сведения см. в следующей статье базы знаний Майкрософт:
2772858 Сборки SQL Server 2012, выпущенные после выпуска пакета обновления 1 (SP1) для SQL Server 2012
Накопительное обновление 5 для SQL Server 2012
Исправление для этой проблемы впервые выпущено в накопительном обновлении 5. Для получения дополнительных сведений о том, как получить этот накопительный пакет обновления для SQL Server 2012, щелкните следующий номер статьи базы знаний Майкрософт:
2777772 Накопительный пакет обновления 5 для SQL Server 2012 Примечание. Так как сборки являются кумулятивными, каждый новый выпуск исправлений содержит все исправления и все исправления безопасности, которые были включены в предыдущий выпуск исправлений для SQL Server 2012. Рекомендуется установить последнюю версию исправления, которая включает это исправление. Дополнительные сведения см. в следующей статье базы знаний Майкрософт:
2692828 Сборки SQL Server 2012, выпущенные после выпуска SQL Server 2012
SQL Server 2008 R2 с пакетом обновления 2 (SP2)
Исправление для этой проблемы впервые выпущено в накопительном обновлении 1 для SQL Server 2008 R2 с пакетом обновления 2. Для получения дополнительных сведений о том, как получить этот накопительный пакет обновления, щелкните следующий номер статьи базы знаний Майкрософт:
2720425 Накопительный пакет обновления 1 для SQL Server 2008 R2 с пакетом обновления 2 (SP2)Примечание. Поскольку сборки являются кумулятивными, каждый новый выпуск исправлений содержит все исправления и все исправления безопасности, которые были включены в предыдущий выпуск исправлений для SQL Server 2008 R2. Рекомендуется установить последнюю версию исправления, которая включает это исправление. Дополнительные сведения см. в следующей статье базы знаний Майкрософт:
2730301 Сборки SQL Server 2008 R2, выпущенные после выпуска SQL Server 2008 R2 с пакетом обновления 2 (SP2)
SQL Server 2008 R2 с пакетом обновления 1 (SP1)
Исправление для этой проблемы впервые выпущено в накопительном обновлении 7 для SQL Server 2008 R2 с пакетом обновления 1 (SP1). Для получения дополнительных сведений о том, как получить этот накопительный пакет обновления, щелкните следующий номер статьи базы знаний Майкрософт:
2703282 Накопительный пакет обновления 7 для SQL Server 2008 R2 с пакетом обновления 1 (SP1)Примечание. Поскольку сборки являются кумулятивными, каждый новый выпуск исправлений содержит все исправления и все исправления безопасности, которые были включены в предыдущий выпуск исправлений для SQL Server 2008 R2. Рекомендуется установить последнюю версию исправления, которая включает это исправление. Дополнительные сведения см. в следующей статье базы знаний Майкрософт:
2567616 Сборки SQL Server 2008 R2, выпущенные после выпуска SQL Server 2008 R2 с пакетом обновления 1 (SP1)
SQL Server 2008 R2
Исправление для этой проблемы впервые выпущено в накопительном обновлении 13. Для получения дополнительных сведений о том, как получить этот накопительный пакет обновления для SQL Server 2008 R2, щелкните следующий номер статьи базы знаний Майкрософт:
2679366 Накопительный пакет обновления 13 для SQL Server 2008 R2Примечание. Поскольку сборки являются кумулятивными, каждый новый выпуск исправлений содержит все исправления и все исправления безопасности, которые были включены в предыдущий выпуск исправлений для SQL Server 2008 R2. Рекомендуется установить последнюю версию исправления, которая включает это исправление. Дополнительные сведения см. в следующей статье базы знаний Майкрософт:
981356 Сборки SQL Server 2008 R2, выпущенные после выпуска SQL Server 2008 R2
Синтаксис
Ссылки на описание синтаксиса Transact-SQL для SQL Server 2014 и более ранних версий, см. в статье Документация по предыдущим версиям.
Решение
Статус
Корпорация Майкрософт подтверждает наличие этой проблемы в своих продуктах, которые перечислены в разделе "Применяется к".
Microsoft SQL Server 2005 Standard Edition Microsoft SQL Server 2005 Express Edition Microsoft SQL Server 2005 Developer Edition Microsoft SQL Server 2005 Enterprise Edition Microsoft SQL Server 2005 Workgroup Edition Еще. Меньше
В. Усечение файла данных
В следующем примере усекается первичный файл данных в базе данных AdventureWorks . Выполняется запрос к представлению каталога sys.database_files для получения идентификатора файла данных file_id .
Наборы результатов
В приведенной ниже таблице описаны столбцы результирующего набора.
Рекомендации
Примите во внимание следующие сведения при планировании сжатия файла.
Максимальный эффект от сжатия достигается после операции, при которой создается много неиспользуемого пространства, например после усечения или удаления таблицы.
Большинству баз данных для выполнения обычных ежедневных операций требуется некоторый объем свободного места. Если вы регулярно сжимаете базу данных, но ее размер постоянно увеличивается, скорее всего, освобождаемое пространство необходимо для обычной работы базы данных. В таких случаях повторное сжатие базы данных бессмысленно.
Операция сжатия не исключает фрагментацию индексов в базе данных и даже, наоборот, приводит к усилению фрагментации. Фрагментация — это еще одна причина, по которой не стоит регулярно сжимать базу данных.
Сжимайте несколько файлов в одной базе данных последовательно, а не одновременно. Состязание в системных таблицах может привести к задержке из-за блокировки.
Сжатие файла данных до указанного целевого размера
В приведенном ниже примере файл данных с именем DataFile1 в пользовательской базе данных UserDB сжимается до 7 МБ.
Дополнительные сведения
В SQL Server 2005 операция сжатия (DBCC SHRINKFILE) пытается немедленно сжать указанного журнала транзакций до требуемого размера. Чтобы сжать файл журнала транзакций вручную при использовании модели полного восстановления, резервное копирование журнала транзакций. Затем используется инструкция DBCC SHRINKFILE сжать файл журнала транзакций.
Как правило при сжатии файла журнала транзакций в SQL Server 2005 работает быстрее, чем при сжатии файла журнала транзакций в SQL Server 2000. Причина в том что диспетчер журналов SQL Server 2005 создает или повторно использует неактивные виртуальные файлы журнала, следуя порядок хранения физического диска. Таким образом Неактивная часть журнала транзакций обычно находится в конце файла.
Например файл журнала транзакций может быть 100 виртуальных файлов журнала, и используются только 2 виртуальных файлов журнала. SQL Server 2000 может хранить первый используемый виртуальный файл журнала в начале файла журнала транзакций и второй используется виртуальный файл журнала в середине файла журнала транзакций. Чтобы сжать файл журнала транзакций до 2 только виртуальные файлы журнала, SQL Server заполняет остающейся части второй виртуальный файл журнала, используя фиктивные записи. Далее доступен виртуального файла журнала, указанный в параметре диспетчера журналов SQL Server перемещает начало логического журнала. Диспетчер журналов может создать виртуальный файл журнала в середине файла журнала транзакций непосредственно перед последним активный виртуальный файл журнала. В этом случае необходимо успешно сжать файл журнала транзакций до 2 виртуальных файлов журнала с помощью нескольких операций резервного копирования журнала и несколько операции сжатия. В худшем случае в этом примере может потребоваться использовать 50 журнала операций резервного копирования и 50 сжатие операций успешно сжать файл журнала транзакций до 2 виртуальных файлов журнала.
Однако в SQL Server 2005 можно выполнять одной инструкции DBCC SHRINKFILE сжать файл журнала транзакций непосредственно 2 виртуальные файлы журнала. Это можно сделать, так как диспетчер журналов SQL Server 2005 создает 2 виртуальных файлов журнала в порядке хранения физического диска. В начале файла журнала транзакций, оба виртуальных файлов журнала.
При попытке сжать файл журнала транзакций, в котором мало свободного места в SQL Server 2005, может потребоваться выполнить операцию резервного копирования дополнительный журнал. Операции резервного копирования журнала дополнительных усекает для меньшего размера файла журнала транзакций. Эта операция резервного копирования журнала — только три шага, которые выполняют для уменьшения размера файла журнала транзакций в SQL Server 2000. Для получения дополнительных сведений обратитесь к статье базы знаний Майкрософт, описанное в разделе «Аннотация». Чтобы сжать файл журнала транзакций, в котором мало свободного места в SQL Server 2005, выполните следующие действия.
Создайте резервную копию журнала транзакций, чтобы сделать неактивным большинство активных виртуальных файлов журнала. Таким образом в дальнейшем можно удалить неактивные виртуальные файлы журнала. Чтобы сделать это, запустите среду SQL Server Management Studio и запустите инструкцию Transact-SQL, которая напоминает следующую инструкцию Transact-SQL.
Примечание. В данном заявлении — это имя базы данных, резервного копирования и — это полный путь к файлу резервной копии.
Например выполните следующую инструкцию Transact-SQL.
Сжать файл журнала транзакций. Чтобы сделать это, выполните инструкцию Transact-SQL, которая напоминает следующую инструкцию Transact-SQL.
Примечание. В данном заявлении — это имя файла журнала транзакций, а — это размер целевого файла журнала транзакций для. Целевой размер должен быть разумным. Например размера, меньше, чем 2 виртуальных файлов журнала не удается сжать файл журнала транзакций.
Если инструкция DBCC SHRINKFILE не удалось сжать файл журнала транзакций для целевого размера, запустите инструкцию BACKUP LOG, указанное на шаге 1, чтобы сделать неактивным несколько виртуальных файлов журнала.
Выполнение инструкции DBCC SHRINKFILE описанное в шаге 2. После этой операции журнала транзакций должно быть близким к целевого размера.
В целом в SQL Server 2005 изменен алгоритм диспетчера журналов для получения следующего виртуального файла журнала. Таким образом при сжатии файла журнала транзакций в SQL Server 2005 может отличаться от при сжатии файла журнала транзакций в SQL Server 2000.
Если файл журнала имеет достаточное количество свободного места, при сжатии файла журнала транзакций в SQL Server 2005 работает быстрее, чем при сжатии файла журнала транзакций в SQL Server 2000.
Если файл журнала отсутствует свободное место, при сжатии файла журнала транзакций в SQL Server 2005 является таким же, как при сжатии файла журнала транзакций в SQL Server 2000.
Если файл журнала имеет мало свободного места, может потребоваться выполнить операцию дополнительный журнал резервного копирования в SQL Server 2005, меньше, чем для выполнения в SQL Server 2000.
Примеры
Разрешения
Необходимо быть членом предопределенной роли сервера sysadmin или предопределенной роли базы данных db_owner .
Причина
Когда на странице удаляется запись с переадресованной версией, тип записи на странице изменяется на GHOST_VERSION_RECORD. Тем не менее, на странице «свободное место на странице (PFS)» не указывается, что на странице содержится Фантом-запись. Это приведет к тому, что страница не будет уменьшаться на размер файла базы данных.
Проблемы
Рассмотрим следующий сценарий.
У вас есть база данных, в которой в Microsoft SQL Server 2012 или Microsoft SQL Server 2008 R2 используется один из указанных ниже элементов.
Параметр уровня изоляции SNAPSHOT
Изоляция моментальных снимков READ UNCOMMITTED (RCSI)
Вы удаляете одну или несколько переадресованных записей в таблице базы данных.
В таблице нет кластеризованного индекса.
Чтобы уменьшить размер файла базы данных, используйте команду DBCC SHRINKFILE.
В этом сценарии размер файла базы данных не уменьшается, хотя большая часть файла базы данных пуста.Примечание.Эта проблема обычно возникает при удалении переадресованной версии записи в куче.
Г. Очистка файла
Следующий пример демонстрирует процедуру очистки файла для его удаления из базы данных. Для этого примера сначала создается файл, содержащий данные.
SQL Server 2008 R2 Datacenter SQL Server 2008 R2 Developer SQL Server 2008 R2 Enterprise SQL Server 2008 R2 Standard SQL Server 2008 R2 Standard Edition for Small Business SQL Server 2008 R2 Web SQL Server 2008 R2 Workgroup SQL Server 2012 Developer SQL Server 2012 Enterprise SQL Server 2012 Express SQL Server 2012 Standard SQL Server 2012 Web SQL Server 2012 Enterprise Core Еще. Меньше
Корпорация Майкрософт распространяет исправления Microsoft SQL Server 2008 R2 или Microsoft SQL Server 2012 как один файл для загрузки. Поскольку исправления являются кумулятивными, каждый новый выпуск содержит все исправления и исправления для системы безопасности, которые были включены в пакет исправлений для Microsoft SQL Server 2008 R2 или SQL Server 2012.
Операция сжатия блокируется
Разрешить эту проблему можно одним из следующих способов.
- Прервите выполнение транзакции, которая блокирует операцию сжатия.
- Прервите операцию сжатия. При прерывании операции сжатия вся уже выполненная работа сохраняется.
- Пока операция сжатия ожидает завершения блокирующей транзакции, ничего делать не нужно.
Ссылки
Дополнительные сведения о том, как уменьшение размера журнала транзакций посетите веб-узел Microsoft Developer Network (MSDN) Сжатие журнала транзакций .
Дополнительные сведения об инструкции DBCC SHRINKFILE посетите веб-узел MSDN DBCC SHRINKFILE (Transact-SQL) .
Дополнительные сведения об усечении журналов транзакций посетите веб-узел MSDN Усечение журнала транзакций .
У меня есть база данных с файлом журнала транзакций 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 файл после
Устранение неполадок
Этот раздел описывает методы диагностики и устранения проблем, которые могут произойти при выполнении команды DBCC SHRINKFILE:
Читайте также: