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

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

1 голос
/ 09 декабря 2008

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)

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

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

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

2 голосов
/ 06 июля 2011

Недавно я решил похожую проблему и обнаружил, что в 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
2 голосов
/ 09 декабря 2008

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

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

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

0 голосов
/ 29 августа 2009

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

Проверить использование для активной транзакции В 2005 году ВЫБРАТЬ * FROM sys.dm_tran_session_transactions

2000 DBCC LOGINFO

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

...