У нас есть база данных в SQL Server 2008, для которой Recovery model установлен на Simple.
Периодически мы запускаем большое обновление для большой таблицы (15 миллионов строк для обновления). Для этого мы запускаем хранимую процедуру, выполнение которой занимает 2 часа +. Когда хранимая процедура завершает работу, размер файла журнала увеличивается до 37 ГБ, что довольно странно, поскольку модель восстановления проста и мы не даже явно начать транзакцию в хранимой процедуре (мы делаем полную резервную копию БД перед обновлением для безопасности)
Кроме того, когда мы сжимаем файл журнала, он возвращается к 1 МБ
Можно ли просто предотвратить рост файла журнала до 37 ГБ ?
Спасибо
У меня была похожая проблема. Мне нужно было удалить пару миллионов старых записей. Удаление не удалось примерно через 30 минут, потому что доступное пространство для файла журнала было слишком маленьким. Мы решили эту проблему, изменив оператор удаления, чтобы удалить только 500 000 записей за раз. Это решило проблему.
Чтобы применить эти знания в вашем случае. Можете ли вы запустить несколько небольших обновлений вместо одного большого? Это можно сделать, явно добавив операторы «начать транзакцию» и «зафиксировать» в вашу хранимую процедуру. Помимо операторов в начале и в конце хранимой процедуры, вы можете выполнить фиксацию после миллиона строк и начать новую транзакцию, чем. Я бы не стал делать коммит после каждого обновления, так как это сильно снизит производительность. Другой вариант - ограничить хранимую процедуру определенным количеством и вызвать ее несколько раз или создать аналогичные хранимые процедуры, которые работают с разными частями данных.
Поскольку вы не используете явно границы транзакции, вам может повезти, установив уровень изоляции транзакции на незафиксированные чтения. Видеть Вот. Я думаю, что это может ускорить обработку, но не думаю, что это сильно повлияет на журнал транзакций. Имейте в виду, что вы включаете грязные чтения, устанавливая уровень изоляции на незафиксированные чтения.
AFAIK, автоусадка запускается только каждые 30 минут. Через какое время после завершения хранимой процедуры вы просматриваете файл журнала? Кроме того, сколько баз данных находится на этом сервере? Автоматическое сжатие работает по циклическому алгоритму и может занять некоторое время, чтобы добраться до этой конкретной базы данных.
Я также предлагаю попытаться разбить операции, чтобы минимизировать рост журнала. SQL Server не будет автоматически сжимать журнал, если вы не включили auto_shrink, что может вызвать серьезные проблемы с производительностью.