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