Журнал SQL Server 2008 года не усечет

Я наконец пришел к выводу, что существует ошибка в 2008 SQLServer.

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

я также работал:

DBCC CHECKDB
DBCC UPDATEUSAGE (bybox)

И все проверяет хорошо.

Список на следующем пакете обновления - все, что я могу сказать.

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

Use YourDatabase
GO

DBCC sqlperf(logspace)  -- Get a "before" snapshot
GO  

BACKUP LOG BSDIV12Update WITH TRUNCATE_ONLY;  -- Truncate the log file, don't keep a backup
GO

DBCC SHRINKFILE(YourDataBaseFileName_log, 2);  -- Now re-shrink (use the LOG file name as found in Properties / Files.  Note that I didn't quote mine).
GO

DBCC sqlperf(logspace)  -- Get an "after" snapshot
GO

Обновление: Simon отмечает, что получает ошибку на Команде резервного копирования. Я не понял, что "Truncate_only" был прекращен в SQL Server 2008, когда я ответил ранее. После небольшого количества исследования рекомендуемыми шагами для уменьшения файла журнала является к (a) Изменение, Модель Восстановления к Простому и затем (b) уменьшает файл с помощью DBCC ShrinkFile как выше. К сожалению, Вы упоминаете, что уже попытались установить модель восстановления на Простой, таким образом, я предполагаю, что Вы также выполнили DBCC Shrinkfile позже. Это корректно? Сообщите мне.

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

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

Попытайтесь работать

DBCC OPENTRAN

, чтобы проверить, существуют ли какие-либо открытые транзакции.

Я всегда ненавидел способ, которым SQL Server обрабатывает физическое уменьшение файлов журнала. Обратите внимание на то, что я всегда делал это через Руководителя предприятия / Studio управления SQL SERVER, но кажется, что, когда Вы уменьшаете/усекаете файл журнала, физический размер файла журнала не уменьшит до окончания выполнения полного резервного копирования на файле данных базы данных и затем поддержки файл журнала снова. Я никогда не мог закреплять точный шаблон, но Вы могли попытаться видеть, какова точная последовательность. Однако это всегда включало выполнение полного резервного копирования файла данных.

Я нашел DBCC SHRINKFILE (Transact-SQL) (MSDN).

Следующий пример уменьшает файл журнала в базе данных AdventureWorks к 1 МБ. Позволить DBCC SHRINKFILE управляйте для уменьшения файла, файл является сначала усеченным путем установки модели восстановления базы данных на ПРОСТОЙ.

USE AdventureWorks;
GO
-- Truncate the log by changing the database recovery model to SIMPLE.
ALTER DATABASE AdventureWorks
SET RECOVERY SIMPLE;
GO
-- Shrink the truncated log file to 1 MB.
DBCC SHRINKFILE (AdventureWorks_Log, 1);
GO
-- Reset the database recovery model.
ALTER DATABASE AdventureWorks
SET RECOVERY FULL;
GO

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

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

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

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

Итак, попробуйте следующее.

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

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

3. Запустите инструмент сжатия для файла журнала и, если повезет, файл журнала должен уменьшиться в размере. В последний раз, когда я это делал, он уменьшился с 180 ГБ до 12 МБ, и инструмент сжатия утверждает, что в файле все еще остается 10 МБ свободного места.