Сжатие файла журнала не уменьшает размер

У меня есть база данных, которая имеет файл данных 350 МБ (.mdf) и файл журнала 4,9 ГБ (.ldf). Модель восстановления установлена ​​на FULL.

Когда я пытаюсь сжать файл журнала, он не сжимается.

Я знаю, что сокращение базы данных не хорошо, и это не должно быть сделано. Но все же я пытаюсь сделать это для сокращения файла журнала.

Когда я побежал

DBCC SQLPerf(logspace) 

Я обнаружил, что размер журнала составляет 4932 МБ, а объем используемого журнала - 98,76% !

Тогда я попробовал эту команду

USE <databasename>;
DBCC loginfo;

Теперь почти все VLF имеют статус 2, что означает, что все используются.

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

Я изменил модель восстановления на SIMPLEи попытался снова сжаться, но это также не помогло.

Я проверил на открытые транзакции

DBCC opentran (database);

и обнаружил, что ни одна транзакция не открыта сейчас.

Что мешает мне сжать файл журнала? Как я могу решить это?

Вот ответ на мой собственный вопрос.

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

SELECT log_reuse_wait_desc
FROM sys.databases
WHERE name = 'DBName'

Я получил следующий вывод:

log_reuse_wait_desc
-------------------
REPLICATION 

В базе данных остались некоторые объекты, связанные с репликацией, даже после удаления репликации.

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

Решение состояло в том, чтобы импортировать содержимое базы данных в другую базу данных, используя параметр импорта SQL Server.

Шаги по сокращению журнала будут

Резервное копирование журнала транзакций через SSMS или T-SQL, а затем выполнить сжатие

Команды для SSMS находятся под задачами, если щелкнуть правой кнопкой мыши имя базы данных

BACKUP LOG <Databasename> TO DISK N'<path\database_log.ldf';
GO

DBCC SHRINKFILE (<FileName>, <TargetSize>) WITH NO_INFOMSGS

Возможно, вам придется сделать это несколько раз

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

источник: http://support.microsoft.com/kb/907511

Прочтите раздел Как сжать журнал SQL Server, чтобы узнать, как циклический характер журнала может предотвратить сжатие после усечения. Возможно, что вы зарегистрировали последнюю точку LSN в VLF, который находится в хвосте LDF. Счетчик интуитивно должен продвигать журнал, генерируя записи журнала, чтобы позволить ему сжаться.

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

Вы можете попробовать запустить это:

USE <databasename>
GO

BACKUP DATABASE <databasename> TO DISK '<absolute path goes here>\<databasename>.bak';
GO

Или вы можете сделать это из SSMS и использовать доступные графические инструменты (подробности см. Здесь: http://msdn.microsoft.com/en-us/library/ms187510.aspx ).

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

Надеюсь это поможет.

Я обнаружил, что мне нужно выполнить 2 или 3 резервного копирования базы данных и журнала транзакций, чтобы размер журнала транзакций действительно уменьшился. У меня есть база данных, которая была создана с моделью полного восстановления. Каждую ночь он выполняет резервное копирование базы данных и журнала транзакций, но неизбежно, что журнал транзакций постоянно увеличивается в течение 2-3 недель. Когда оставшееся дисковое пространство достигнет 1 ГБ, я увижу, что журнал транзакций составляет около 30 ГБ. Я выполнил шаги, рекомендованные Microsoft, и после 4-й и 5-й итерации резервного копирования базы данных и журнала транзакций журнал транзакций, наконец, освободит дополнительное пространство и уменьшится. Затем я возвращаюсь и удаляю несколько созданных мной резервных копий.

Моя работа для репликации, которая блокирует сжатие файла журнала:

1. Установить модель восстановления БД на Simple
2. Отключить БД
3. Создать резервную копию файла журнала (на всякий случай)
4. Удалить файл журнала
5. Вывести БД в онлайн

В моем случае это сработало. После переноса БД онлайн-журнал создавался автоматически и его размер составлял 512 КБ вместо 70 ГБ. Но это только обходной путь. Проблема с корнем не решена. В моем случае мы используем репликацию.