DBCC SHRINKFILE у файлі журналу не зменшує розмір навіть після РЕЗЕРВНОГО ВХОДУ НА ДИСК

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

Я хотів максимально зменшити файл журналу, і тому я розпочав своє прагнення, щоб зрозуміти, як це зробити. Застереження: Я не DBA (і навіть не наближаюся до DBA), і прогресував, відчуваючи це завдання.

По-перше, я просто зайшов у 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

Це говорить про те, що мені потрібно зробити резервну копію файлу журналу до shrinkfile, щоб файли віртуального журналу були звільнені, і shrinkfile міг виконати свою роботу - я не знаю, що це означає ... Я просто перефразую тут :)

Отже, я вирішив спробувати зробити резервну копію файлу журналу, а потім зробити DBCC SHRINKFILE (і я змінив новий розмір файлу журналу на 12800, оскільки це був мінімальний розмір, визначений у результатах попередньої команди DBCC SHRINKFILE)

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

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

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

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

ЦЕ НЕ РЕКОМЕНДОВАНА ПРАКТИКА для виробничих систем ... Ви втратите здатність відновлюватись до певного часу з попередніх резервних копій / файлів журналів.

Див. Приклад B на цій сторінці msdn DBCC SHRINKFILE (Transact-SQL) для прикладу та пояснення.

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

Знайдіть у вашій базі даних ідентифікатор файлу журналу, використовуючи такий запит.

SELECT * FROM sys.database_files;

У моєму випадку файлом журналу є file_id 2. Тепер ми хочемо знайти віртуальні журнали, що використовуються, і зробимо це за допомогою наступної команди.

DBCC LOGINFO;

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

Якщо ви помітили статус 2, що трапляється після 0, це блокує термоусадочну систему, щоб вона повністю не зменшила файл. Щоб обійти це, зробіть ще одну резервну копію журналу транзакцій і негайно запустіть ці команди, надавши ідентифікатор файлу, знайдений вище, та розмір, до якого ви хотіли б зменшити свій файл журналу.

-- 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

Я пробував багато способів, але це працює.

Зразок коду доступний у 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

Я вирішив цю проблему, взявши повне резервне копіювання та транзакційне резервне копіювання. Іноді процес резервного копіювання не завершується, і це одна з причин, чому файл .ldf не стискається. Спробуйте це. У мене це спрацювало.

Завдяки @ 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