Журнал SQL Server 2008 не будет усекаться

Question

Я считаю себя очень опытным человеком SQL. Но я не могу сделать эти две вещи:

• Уменьшить размер выделенного журнала.

• Усечение журнала.

  DBCC sqlperf (пространство журнала)

возвращается:

Database Name   Log Size (MB)   Log Space Used (%)  Status
ByBox       1964.25     30.0657         0

Следующее не работает с SQL 2008

DUMP TRANSACTION ByBox WITH TRUNCATE_ONLY

Выполнение следующего ничего не делает

DBCC SHRINKFILE ('ByBox_1_Log' , 1)
DBCC shrinkdatabase(N'bybox')

Я пробовал резервные копии. Я также попытался установить для свойств базы данных - «Восстановить модель» значения «ПОЛНЫЙ» и «ПРОСТОЙ», а также комбинацию всего вышеперечисленного. Я также попытался установить совместимость с SQL Server 2005 (я использую этот параметр, так как я хочу соответствовать нашему производственному серверу) и SQL Server 2008.

Независимо от того, что я пытаюсь, журнал остается на 1964,25 МБ, используется 30%, и он продолжает расти.

Я бы хотел, чтобы журнал вернулся на 0% и уменьшил размер файла журнала, скажем, до 100 МБ, что вполне достаточно. Моя база данных должна ненавидеть меня; он просто игнорирует все, что я прошу сделать с журналом.

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

-- Clear out pending replication stuff
exec sp_removedbreplication
go
EXEC sp_repldone @xactid = NULL, @xact_segno = NULL,
     @numtrans = 0, @time = 0, @reset = 1
go

Попытка:

SELECT log_reuse_wait, log_reuse_wait_desc
FROM sys.databases
WHERE NAME='bybox'

Возвращает

log_reuse_wait  log_reuse_wait_desc
0   NOTHING

Как я могу исправить эту проблему?

---

Глядя на это и устанавливая модель восстановления в ПОЛНОЕ Я пробовал следующее:

USE master
GO

EXEC sp_addumpdevice 'disk', 'ByBoxData', N'C:\<path here>\bybox.bak'

-- Create a logical backup device, ByBoxLog.
EXEC sp_addumpdevice 'disk', 'ByBoxLog', N'C:\<path here>\bybox_log.bak'

-- Back up the full bybox database.
BACKUP DATABASE bybox TO ByBoxData

-- Back up the bybox log.
BACKUP LOG bybox TO ByBoxLog

которые вернули:

Processed 151800 pages for database 'bybox', file 'ByBox_Data' on file 3.
Processed 12256 pages for database 'bybox', file 'ByBox_Secondary' on file 3.
Processed 1 pages for database 'bybox', file 'ByBox_1_Log' on file 3.
BACKUP DATABASE successfully processed 164057 pages in 35.456 seconds (36.148 MB/sec).

Processed 2 pages for database 'bybox', file 'ByBox_1_Log' on file 4.
BACKUP LOG successfully processed 2 pages in 0.056 seconds (0.252 MB/sec).

Отлично! Но это не так.

И DBCC SHRINKFILE ('ByBox_1_Log', 1) теперь возвращается с

DbId    FileId  CurrentSize MinimumSize UsedPages   EstimatedPages
7   2   251425  251425  251424  251424

и DBCC SQLPERF (LOGSPACE) по-прежнему сообщает об использовании 30%.

Я думаю, что мне, возможно, придется смириться с тем фактом, что в SQL Server 2008 вполне может быть ошибка или что мой файл журнала каким-то образом поврежден. Тем не менее, моя база данных находится в хорошем рабочем состоянии, что заставляет меня думать, что есть ошибка (содрогается при мысли) .

Answer 1

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

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

Answer 2

Я знаю, что вы имеете в виду - 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

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

Answer 3

SQL Server 2012 : у меня возникла проблема, при которой ни один файл журнала (и все они уже находились в режиме ПРОСТОГО восстановления) не уменьшился

Это сработало для меня ... Я перезапустил экземпляр SQL Server (потому что мог), и каждый из этих плохих парней сжался.

Все, что удерживало его от сжатия, было освобождено при перезапуске. Это хорошо только для экстренных случаев (или когда это ваш сервер), а не для обычного долгосрочного решения.

Answer 4

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

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

Я тоже побежал:

DBCC CHECKDB
DBCC UPDATEUSAGE (bybox)

И все в порядке.

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

Answer 5

Пожалуйста, запустите:

SELECT name, log_reuse_wait, log_reuse_wait_desc FROM sys.databases

и посмотрите, что такое log_reuse_wait для вашей проблемы, дБ если это репликация, что это ошибка, вам нужно это значение 0, 2 или 4