DBCC SHRINKFILE в файле журнала не уменьшает размер даже после резервного копирования журнала на диск

хорошо, вот решение для уменьшения физического размера файла транзакции, но без изменение режима восстановления на простой.

в базе данных найдите file_id файла журнала, используя следующий запрос.

SELECT * FROM sys.database_files;

в моем случае файл журнала-file_id 2. Теперь мы хотим найти используемые виртуальные журналы и сделать это с помощью следующей команды.

DBCC LOGINFO;

здесь вы можете увидеть, используются ли какие-либо виртуальные журналы, увидев если состояние равно 2 (используется) или 0 (бесплатно). При сжатии файлов пустые виртуальные журналы физически удаляются, начиная с конца файла, пока он не достигнет первого используемого состояния. Вот почему сжатие файла журнала транзакций иногда сокращает его частично, но удаляет все бесплатные виртуальные журналы, которые вы можете ожидать.

Если вы заметили состояние 2, которые происходят после 0, это блокирует сокращение от полного сокращения файла. Чтобы обойти это, сделайте еще одну резервную копию журнала транзакций и немедленно запустите эти команды, предоставив file_id, найденный выше, и размер файла журнала, который вы хотели бы уменьшить.

инструкция DBCC shrinkfile команда (столбцом file_id, LogSize_MB)

DBCC SHRINKFILE (2, 100);
DBCC LOGINFO;

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

Я использую этот скрипт на sql server 2008 R2.

USE [db_name]

ALTER DATABASE [db_name] SET RECOVERY SIMPLE WITH NO_WAIT

DBCC SHRINKFILE([log_file_name]/log_file_number, wanted_size)

ALTER DATABASE [db_name] SET RECOVERY FULL WITH NO_WAIT

попробуй такое

ALTER DATABASE XXXX  SET RECOVERY SIMPLE

use XXXX

declare @log_File_Name varchar(200) 

select @log_File_Name  = name from sysfiles where filename like '%LDF'

declare @i int = FILE_IDEX ( @log_File_Name)

dbcc shrinkfile ( @i , 50) 

пол Рэндал имеет превосходное обсуждение этой проблемы в своем блоге: http://www.sqlskills.com/blogs/paul/post/backup-log-with-no_log-use-abuse-and-undocumented-trace-flags-to-stop-it.aspx

сокращение файла журнала

для файлов журнала компонент Database Engine использует target_size для вычисления целевого размера для всего журнала; поэтому target_size - это объем свободного места в журнале после операции сжатия. Целевой размер для всего журнала затем преобразуется в целевой размер для каждого файла журнала. DBCC SHRINKFILE пытается немедленно сжать каждый физический файл журнала до целевого размера.

однако, если часть логический журнал находится в виртуальных журналах за пределами целевого размера, компонент Database Engine освобождает как можно больше места, а затем выдает информационное сообщение.

сообщение описывает действия, необходимые для перемещения логического журнала из виртуальных журналов в конце файла. После выполнения действий можно использовать 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.

Transact-SQL

использовать Данных adventureworks2012;
GO
-- Усечь журнал, изменив модель восстановления базы данных на простой.
ALTER DATABASE AdventureWorks2012
УСТАНОВИТЬ ВОССТАНОВЛЕНИЕ ПРОСТО;
GO
-- Сократите усеченный файл журнала до 1 МБ.
DBCC SHRINKFILE (AdventureWorks2012_Log, 1);
GO
-- Сброс модели восстановления базы данных.
ALTER DATABASE AdventureWorks2012
УСТАНОВИТЬ ПОЛНОЕ ВОССТАНОВЛЕНИЕ;
GO

при использовании DBCC SHRINKFILE (Logfile, size) он только усекает от конца файла журнала назад, насколько это возможно. Когда он достигает наивысшего виртуального журнала, который все еще используется, он не может сжиматься дальше. Это описано в электронной документации по SQL Server по адресу:

http://technet.microsoft.com/en-us/library/ms189493.aspx

Итак, как только верхний конец журнала ясен, его можно уменьшить в размере. Опять же, это будет зависеть от того, сколько журнала все еще используется. Журнал может быть очищается резервными копиями, но резервные копии не очищают незавершенные транзакции, поэтому журнал может оставаться в высоком VLF даже после повторного резервного копирования.

что касается увеличения и уменьшения VLFs, насколько велик файл журнала, созданный изначально, и какова настройка для роста файла журнала? Если он вырастет только на небольшое количество, он создаст больше VLFs, чем кто-либо желает.

общим шаблоном для сжимать файл журнала будет контрольная точка, подпорка, SHRINKFILE, контрольная точка, Резервное копирование, SHRINKFILE и т. д., Пока вы не получите результаты. Существует много причин, по которым журнал не может быть сжимаемым, включая очень большой откат.

переключение с простого на полный имеет проблему:

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

но одно предостережение, чтобы иметь в виду для полного режима восстановления: Если вы просто переключитесь в режим полного восстановления, но никогда не принимаете начальную полную резервную копию, SQL Сервер не будет выполнять ваш запрос, чтобы быть в полной модели восстановления. Ваш журнал транзакций будет продолжать работать так же, как и в Simpleuntil вы переключитесь на полную модель восстановления и сделать первую полную резервную копию.

модель полного восстановления без резервных копий журналов-это плохо:

Итак, это самая распространенная причина неконтролируемого роста журнала? Ответ: находясь в режиме полного восстановления без каких-либо резервных копий журнала.

это происходит все время люди.

почему это такая распространенная ошибка?

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

начальная настройка модели восстановления модели всегда является полной моделью восстановления-до тех пор, пока кто-то не изменит это. Таким образом, Вы можете сказать, что "модель восстановления по умолчанию" заполнена. Многие люди не знают об этом и имеют свои базы данных работает в полной модели восстановления без резервных копий журнала и, следовательно, файл журнала транзакций намного больше, чем необходимо. Вот почему важно изменить значения по умолчанию, когда они не работают для вашей организации и ее потребностей)

Я пробовал много способов, но это работает.

пример кода доступен в DBCC SHRINKFILE

USE DBName;  
GO  
-- Truncate the log by changing the database recovery model to SIMPLE.  
ALTER DATABASE DBName  
SET RECOVERY SIMPLE;  
GO  
-- Shrink the truncated log file to 1 MB.  
DBCC SHRINKFILE (DBName_log, 1);  --File name SELECT * FROM sys.database_files; query to get the file name
GO  
-- Reset the database recovery model.  
ALTER DATABASE DBName  
SET RECOVERY FULL;  
GO

благодаря @user2630576 и @Ed.С.

следующий сработала:

BACKUP LOG [database] TO DISK = 'D:\database.bak'
GO

ALTER DATABASE [database] SET RECOVERY SIMPLE

use [database]

declare @log_File_Name varchar(200)

select @log_File_Name = name from sysfiles where filename like '%LDF'

declare @i int = FILE_IDEX ( @log_File_Name)

dbcc shrinkfile ( @i , 50)

ALTER DATABASE [database] SET RECOVERY FULL