Мне немного неловко признать, что такое поведение было вызвано хранимой процедурой, вызываемой как часть внутреннего приложения. Однако, даже исправив ошибку, я до сих пор не знаю, почему она была вызвана резервным копированием!
Это был оскорбительный фрагмент кода:
SELECT DISTINCT T.*, TL.RunDate
FROM TaskLog TL
INNER JOIN Task T ON TL.TaskID = T.ID
WHERE TL.RerunFlag = 1
UPDATE TaskLog SET RerunFlag = 0
Изменена последняя строка на:
UPDATE TaskLog SET RerunFlag = 0 WHERE RerunFlag = 1
Я сделал полную резервную копию базы данных, и это привело к тому, что файл журнала начал бесконтрольно расти. Таким образом, проблема связана не с процессом доставки журналов, а просто с первым шагом, а именно с резервным копированием базы данных. Я проверил количество VLF, и вчера оно было больше 400, в настоящее время почти 200, так что это определенно проблема.
Файл журнала базы данных обычно размером около 80 МБ постоянно расширяется до 10 гигабайт без каких-либо признаков остановки, если я пытаюсь инициировать доставку журнала в базе данных на SQL Server 2005. DBCC SHRINKFILE не действует.
Я успешно реализовал доставку журналов для нескольких баз данных, но у меня было странное поведение в одной конкретной базе данных на SQL Server 2005. Обычно эта база данных содержит около 80 МБ данных с 80 МБ файла журнала для общего размера около 160 МБ. Обычно он не сильно меняется в размере в течение дня. Проблемы начинаются, когда я пытаюсь инициировать доставку журналов в этой базе данных с помощью мастера доставки журналов.
Мастер переходит к первому шагу - резервному копированию базы данных и достигает 100% завершения. Затем он останавливается / приостанавливается и никогда не достигает следующего шага. Сообщение об ошибке не создается, и сама SSMS реагирует. Просто кажется, что волшебник уносит буквально навсегда. Я останавливаю и убиваю процесс, но ущерб уже начался. С этого момента и до момента создания резервной копии и сжатия файла журнала, файл журнала продолжает расширяться со скоростью около 100 МБ каждые 5 минут.
Похоже, что пользователи не пострадали (слава богу).
Есть идеи причин и решений?
Вы пытались сделать резервную копию исходной копии и восстановить ее на целевой сервер с помощью параметров NORECOVERY STANDBY, а затем выполнить установку с доставкой журналов? Я использовал это, чтобы обойти необходимость "мастера" делать полную резервную копию и восстанавливать ее на целевой сервер.
Вы регулярно делаете резервную копию файла журнала транзакций? (Вам следует)
Похоже, у вас есть фрагментация виртуального файла журнала (VLF). Предлагаю прочитать: 8 шагов к увеличению пропускной способности журнала транзакций
Это определенно звучит так, как будто что-то происходит с журналом транзакций.
Вы смотрели на Журнал Отчет о состоянии доставки? Это может дать вам представление о том, что происходит с этой базой данных, когда она вешает трубку. В частности, вы захотите выяснить, что происходит, когда он пытается скопировать журнал.
Учитывая ваши симптомы, я думаю, что рост файла журнала действительно правильный. База данных обычно простая модель восстановления? Запустите на короткое время профилировщик, чтобы восстановить эту базу данных, и вы, вероятно, обнаружите, что происходит множество обновлений (или удалений или вставок).
Я думаю так,
Обычно SQL-сервер повторно использует пространство журнала. После запуска процесса доставки журналов SQL-сервер больше не может освобождать журнал до тех пор, пока он не будет отправлен (или, по крайней мере, не будет зарезервирован для отправки). Процессы доставки журналов запускаются, как только вы создаете полную резервную копию для использования для инициализации партнерской базы данных, поэтому ваши симптомы проявляются сразу после создания резервной копии. Резервное копирование не вызывает проблемы, проблема заключается в том, какие обновления запускаются так часто.