Из вашего комментария:
Размер файла журнала снова вырос до почти 200 ГБ
Я могу предположить, что ваша база данных не является подходящим кандидатом для autoshrink(и, исходя из моей практики, это редкий случай, когда autoshrink является хорошим решением для дБ).
Рекомендации
Создание начального размера файла (ов) журнала достаточно большой .Это процесс проб и ошибок, просто посмотрите, что свободное пространство существует и не слишком большоеНикогда не уменьшайте размер файлов журнала до нуля.
Делайте размер приращения журнала не на основе%, а на постоянный размер.По умолчанию SQLServer имеет приращение размера на основе%.Сделайте это приращение достаточно большим .Опять же, это процесс проб и ошибок.
Убедитесь, что в файловой системе (ах), в которой расположены файлы журналов, достаточно свободного места.Вам не нужны фрагментированные файлы журналов, и вы абсолютно не хотите, чтобы база данных отключалась при пиковых нагрузках.
Последнее, но не менее важное.Проверьте открытые транзакции, когда ваш файл журнала неожиданно большой.Я расширю эту тему ниже.
DBCC OPENTRAN
Если журнал большой и его нельзя сжать - это означает, что у вас много данных в открытых транзакциях.
Проверьте это с помощью DBCC OPENTRAN
Посмотрите внимательно.
Вы можете найти виновных - программы / клиенты, которые открывают транзакции, делают много изменений, а затем никогда не commit s / rollback s их.
Имейте в виду, что журналлинейный рост и одна «плохая» транзакция может предотвратить повторное использование пространства журнала (и сокращение тоже)
Найдите таких преступников, найдите программистов / пользователей, которые открывают такие транзакции, в качестве последней меры - kill их.
Уточнение:
Я имею в виду kill как в T-SQL kill
У меня есть сильное подозрение, чтозакрытые транзакции - ваше дело.
Сообщите о своем прогрессе.
Удачи!