Максимальный размер файла журнала транзакций SQL Server
У меня есть несколько баз данных, все в Simple режим восстановления. Ранее были проблемы с размерами файлов журнала, и я сократил их все с помощью Management Studio. Shrink задача. Я также установил параметр для автоматического роста логов, чтобы быть максимальным размером 1024 МБ. Я ожидаю, что файл журнала будет продолжать расти по мере необходимости, пока он не станет 1024 МБ. У меня есть два вопроса на данный момент:
- Что произойдет с файлом журнала после достижения этого предела?
- Есть ли какой-либо эффект от установки максимального ограничения (скажем, 100 МБ, а не 1024 МБ)?
Следует отметить, что существует также план обслуживания резервных копий, который должен выполняться 2 раза в день, и журналы должны автоматически обрезаться (в отличие от сокращения).
2 ответа
Если размер файла журнала во время транзакции достигает своего предела и не может автоматически расти, то транзакция не сможет быть зафиксирована, и вы увидите ошибки в SQL. Файл журнала должен иметь достаточный размер для обработки транзакций между CHECKPOINT операции. Установка нижнего предела увеличивает вероятность возникновения проблем из-за большой транзакции (зависит от рабочей нагрузки).
Ваш файл журнала будет естественным образом увеличиваться до требуемого размера, при условии, что установлены правильные параметры автоматического роста (обратите внимание, что, как предположил TomTom, лучше начать с разумного размера, чем ждать, пока автоматический рост приведет вас туда, что лишает вас производительности в тем временем). Как правило, единственный раз, когда вы должны сжимать файл журнала в простом режиме, это если вы недавно выполнили какую-то массовую транзакцию, из-за которой размер файла журнала увеличился до гораздо большего размера, чем обычно требуется, и вам нужно освободить это место для некоторого другого использовать.
Если вам часто приходится сокращать файлы журналов, вам нужно либо добавить больше места в систему, либо перенести другие службы, которым требуется это место, на другой сервер.
Что произойдет с файлом журнала после достижения этого предела?
У тебя проблемы. Транзакции завершаются неудачно. То есть откат в 1 ГБ, скорее всего, в системе, не подготовленной для обработки нагрузки, займет буквально целое время предполагаемого времени.
Есть ли какой-либо эффект от установки максимального ограничения (скажем, 100 МБ, а не 1024 МБ)?
Вам не хватает места раньше. Какие эманы определенные операции МОГУТ потерпеть неудачу.
Обратите внимание, насколько крошечные базы данных вы работаете, но я
- ВСЕГДА предварительно распределяйте их по максимальному размеру и
- Убедитесь, что у них есть передышка.
Здесь я не работаю с простыми, но у меня есть база данных, работающая на 500 МБ за 15-минутный интервал (мы поддерживаем это каждые 50 минут), и журнал tx составляет 400 ГБ для случайной работы ETL. Это стоило мне буквально центов по сравнению с проблемой и потерей производительности растущего файла (а также вызванной вами внутренней рагментацией). Autogrow подходит ТОЛЬКО для "небольших баз данных".
Следует отметить, что существует также план обслуживания резервных копий, который должен выполняться 2 раза в день, и журналы должны автоматически обрезаться (в отличие от сокращения).
В простом режиме восстановления они практически усекаются на каждой контрольной точке. Прочитайте, что вы настроили.