DBCC SHRINKFILE в файле журнала не уменьшает размер даже после BACKUP LOG TO DISK

Question

У меня есть база данных [Моя БД] со следующей информацией:
SQL Server 2008
Размер MDF: 30 ГБ
Размер LDF: 67 ГБ

IЯ хотел максимально сжать файл журнала, поэтому я начал поиски, чтобы выяснить, как это сделать.Предостережение: я не администратор баз данных (и даже не подхожу к администратору баз данных), и я чувствую прогресс в этом квесте.

Сначала я просто вошел в SSMS, свойства БД, файлы и отредактировал исходный размер (МБ).) значение до 10. Это уменьшило размер файла журнала до 62 ГБ (не совсем те 10 МБ, которые я ввел).Итак, я подключил SQL Profiler, увидел, что вызывается DBCC SHRINKFILE.Затем я ввел эту команду в редактор запросов, и вот результаты.

DBCC SHRINKFILE (N'My DB_Log' , 10)

И результат был:

Cannot shrink log file 2 (My DB_Log) because the logical log file located at the end of the file is in use.
DbId   FileId      CurrentSize MinimumSize UsedPages   EstimatedPages
------ ----------- ----------- ----------- ----------- --------------
8      2           8044104     12800       8044104     12800

(1 row(s) affected)

DBCC execution completed. If DBCC printed error messages, contact your system administrator.

Затем я провел некоторое исследование по этому вопросу и обнаружил следующее:

http://support.microsoft.com/kb/907511

Что говорит о том, что мне нужно сделать резервную копию файла журнала перед сжатым файлом, чтобы файлы виртуального журнала были выпущены, а файл сжатия мог выполнить свою работу - я не знаю, что этозначит ... я просто перефразирую здесь:)

Итак, я решил, что попробую сделать резервную копию файла журнала, а затем выполнить DBCC SHRINKFILE (и с тех пор я изменил размер нового файла журнала на 12800).был MinimumSize, определенный в выходных данных предыдущей команды DBCC SHRINKFILE)

BACKUP LOG [My DB] TO DISK = 'D:\SQLBackup\20110824-MyDB-Log.bak'
GO
DBCC SHRINKFILE (N'My DB_Log' , 12800)
GO

Результат был таким же, как при первом обходе.Я могу только уменьшить размер файла журнала до 62 ГБ.

Я не уверен, что я делаю неправильно и что мне следует попробовать дальше.

Answer 1

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

В вашей базе данных найдите 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;

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

Answer 2

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

ЭТО НЕ РЕКОМЕНДУЕМАЯ ПРАКТИКА для производственных систем ... Вы потеряете способность восстанавливаться на определенный момент времени из предыдущих резервных копий / файлов журналов.

См. Пример B на этой DBCC SHRINKFILE (Transact-SQL) msdn page для примера и пояснения.

Answer 3

Я использую этот скрипт на 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

Answer 4

Попробуйте это

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) 

Answer 5

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

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

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

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

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

• Устранение неполадок: файл не сжимается

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

Запустите следующий запрос.

ВЫБРАТЬ имя, размер / 128.0 - CAST (FILEPROPERTY (name, 'SpaceUsed') AS) int) /128.0 AS AvailableSpaceInMB FROM sys.database_files;

Запустите команду DBCC SQLPERF , чтобы вернуть пространство, используемое в журнале транзакций.

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

• Обычно это файл журнала, который не уменьшается. Обычно это результат файла журнала, который не был усечен.

• Вы можете обрезать журнал , установив для базы данных модель восстановления значение SIMPLE или , сделав резервную копию журнала и затем запустив DBCC SHRINKFILE операция снова.

Пример:

Сокращение файла журнала до указанного целевого размера

В следующем примере файл журнала в базе данных AdventureWorks сжимается до 1 МБ. Чтобы позволить команде DBCC SHRINKFILE сжать файл, файл сначала усекается путем установки модели восстановления базы данных на SIMPLE.

Transact-SQL

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

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

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

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

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

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

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

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

Но следует помнить одно предостережение о режиме полного восстановления: если вы просто переключаетесь в режим полного восстановления, но никогда не выполняете первоначальное полное резервное копирование, SQL Server не выполнит ваш запрос на использование модели полного восстановления. Журнал транзакций будет продолжать работать так же, как в Simpleun, пока вы не переключитесь на модель полного восстановления и не создадите первую полную резервную копию.

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

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

Это постоянно случается с людьми.

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

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

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

Answer 6

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

Answer 7

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

Пример кода доступен в 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

Answer 8

Спасибо @ user2630576 и @ Ed.S.

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

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