У нас есть база данных на сервере SQL 2005, для которой установлен режим простой транзакции. Для журнала установлено значение 1 МБ, которое при необходимости может увеличиваться на 10%.
Мы продолжаем сталкиваться с проблемой, когда журнал транзакций заполняется, и нам нужно его уменьшить. Что могло вызвать переполнение журнала транзакций, если для него разрешен простой и неограниченный рост?
Есть несколько вещей, которые могут привести к увеличению журнала даже в модели восстановления ПРОСТОЙ:
Также была ошибка в SQL 2000 SP4, которая не позволяла контрольным точкам правильно очищать журнал - подробности см. В моем сообщении в блоге: Почему мой журнал не очищается в режиме ПРОСТОГО восстановления? Ошибка SQL 2000 или очень большие VLF.
Я предполагаю, что у вас долгая транзакция.
Вам не нужно постоянно сжимать журнал - постоянное сжатие и увеличение журнала приводит к так называемой фрагментации VLF, которая может повлиять на производительность. Кроме того, всякий раз, когда журнал растет, он должен быть инициализирован нулем, что заставляет все ждать, пока не произойдет инициализация. Подождите, пока бревно достигнет установившегося размера, и оставьте
Ознакомьтесь с длинной статьей, которую я написал для журнала TechNet Magazine о понимании журнала и его поведении в различных моделях восстановления: Понимание ведения журнала и восстановления в SQL Server.
Надеюсь это поможет!
Я понимаю, что это старый пост, но я только что нашел его, пытаясь узнать больше об этой же проблеме, и это все еще лучшее обсуждение в своем роде. Это мне очень помогло.
По словам Пола Рэндала, на самом деле файл журнала состоит из виртуальных файлов журнала размером 512 КБ каждый. Роберт, с другой стороны, сказал, что начальный размер журнала 5 МБ отлично работает с шагом 10%. Это заставило меня заняться простой математикой.
5 МБ = 5120 КБ. 10% рост с 5120 КБ - это ровно 512 КБ, или размер 1 VLF! Если размер файла журнала Уилла составляет всего 1 МБ (или 2 МБ в моем случае), 10% -ный рост приводит к попыткам увеличения на 102,4 КБ (или 204,8 КБ для меня), что меньше даже 1 виртуального файла журнала! Я считаю, что это причина того, что бревно не может расти! Решение Роберта по увеличению начального размера журнала помогло запустить приращения. Другое решение (не тестировалось, но я уверен, что оно сработает) было бы для Уилла увеличить приращения до 50% или для меня до 25%. Конечно, я бы не рекомендовал это, потому что даже если это означает рост всего на 512 КБ в первый раз, это может привести к огромному увеличению позже. Другой альтернативой является установка увеличения с шагом 1 МБ. Учитывая, что мы ожидаем небольших бревен с медленным ростом, это может быть хорошим решением. Естественно, если ожидаемый рост намного больше, такой небольшой рост будет означать, что файлы журнала нужно увеличивать слишком часто, что повлияет на производительность. В любом случае любое из этих решений должно хорошо работать, чтобы избежать ошибок 9001/9002 с неограниченным ростом на серверах, на которых достаточно свободного места на жестких дисках.
У меня такая же проблема в SQL 2005, файл журнала настроен на неограниченный рост, но он не растет, когда он заполняется, я получаю ошибку 9001. Решение для меня заключалось в том, чтобы установить начальный размер журнала на 5 МБ, похоже, проблема прояснилась.