Почему DBCC SHRINKFILE работает непоследовательно в работе базы данных?

DBCC SHRINKFILE всегда работает, когда я запускаю его вручную в файле журнала, даже когда я получаю следующее сообщение:

'Cannot shrink log file 2 (Claim_Log) because all logical log files are in use.'

Однако, когда я запускаю его с работы, он сокращает журнал только примерно в трети времени. В остальное время он просто остается большим (около 150 Гб). Там никогда не бывает никаких ошибок, кроме перечисленных выше. Это утверждение, которое я использую:

DBCC SHRINKFILE (N'Claim_log' , 0, TRUNCATEONLY)

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

Изменить: Вот полное сообщение из журнала:

'Executed as user: *. Cannot shrink log file 2 (Claim_Log) because all logical
log files are in use. [SQLSTATE 01000] (Message 9008)  DBCC execution completed. 
If DBCC printed error messages, contact your system administrator. [SQLSTATE 01000]
(Message 2528).  The step succeeded.'

Я уже пытался выгнать пользователей из БД и перевести их в однопользовательский режим.

Источник

3 ответа

Решение

Недавно я решил похожую проблему и обнаружил, что в sys.databases log_reuse_wait_desc был равен "replication". Очевидно, это что-то означает, что SQL Server ожидает завершения задачи репликации, прежде чем он сможет повторно использовать пространство журнала.

Однако репликация никогда не использовалась ни на нашей БД, ни на нашем сервере. Вы должны иметь возможность очистить состояние, запустив sp_removedbreplication; однако для меня sp_removedbreplication не решил проблему. Вместо этого SQL просто вернулся, сказав, что база данных не была частью репликации...

Я нашел свой ответ здесь:

По сути, мне пришлось создать репликацию, сбросить все указатели репликации на ноль; затем удалите репликацию, которую я только что сделал. т.е.

Execute SP_ReplicationDbOption {DBName},Publish,true,1
GO
Execute sp_repldone @xactid = NULL, @xact_segno = NULL, @numtrans = 0, @time = 0, @reset = 1
GO
DBCC ShrinkFile({LogFileName},0)
GO
Execute SP_ReplicationDbOption {DBName},Publish,false,1
GO
Источник

Попробуйте сначала ввести команду CHECKPOINT, а затем сжать логи

взято из BOL ( http://msdn.microsoft.com/en-us/library/aa226036(SQL.80).aspx)

Принудительно записывает все грязные страницы для текущей базы данных на диск. Грязные страницы - это данные или страницы журнала, измененные после ввода в буферный кеш, но изменения еще не записаны на диск. Дополнительные сведения об усечении журнала см. В разделе "Усечение журнала транзакций".

Источник

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

Проверка использования для активной транзакции в 2005 году SELECT * FROM sys.dm_tran_session_transactions

2000 DBCC LOGINFO

создать хороший план =>1.Создать план обслуживания для резервного копирования журнала (выполненный план).

Источник
Другие вопросы по тегам