Можно ли ограничить размер временного журнала в SQL Server 2005?
Я исследую проблему, из-за которой мой лог-файл tempdb растет пропорционально всему, что может показаться разумным. Этим утром размер файлов данных был более чем в 10 раз. Однако база данных продолжает нормально функционировать, и единственным ограничением размера временного журнала является размер диска, на котором он находится.
Тогда мой вопрос: было бы безопасно для меня ограничить размер временного журнала, я слышал, что вы не должны ограничивать размер tempdb, так как это критично для работы, которая должна выполняться на сервере sql. Но тот факт, что размер файла журнала увеличивается только до размера, допустимого диском, говорит о том, что я могу ограничить его, ничего не нарушая. Это тот случай? и если да, есть ли нижняя граница (т. е. объединенный размер файлов данных), я не должен ограничивать ее ниже?
Кстати, я понимаю, что это не решение проблемы выращивания бревен, которая находится в стадии изучения, но может быть не решена в ближайшее время.
Ура,
2 ответа
Все, что вы будете делать, ограничивая размер журнала, - это вызывать сбой, когда все, что увеличивается, журнал достигает предела. (Будет ошибка и, возможно, откат транзакции).
На самом деле, возможно, это полезный способ увидеть, что такое большой журнал!:) Хотя еще лучшим способом было бы использовать Perfmon для мониторинга счетчика SQL:Database:Log Used (kb), чтобы увидеть, когда он растет, и сопоставить его с другими действиями на сервере.
У нас была похожая проблема, после того, как мы подняли PSS call с Microsoft и тщательно изучили проблему, мы разделили следующую возможную причину и решение.
Причина:
Вероятная причина симптомов связана с дисками / лунками, на которых размещены пользовательские базы данных, с серьезными проблемами ответа ввода-вывода; это приводит к тому, что автоматическая проверка в пользовательских базах данных занимает очень много времени.
Теперь контрольная точка на базе данных tempdb возникает только тогда, когда журнал базы данных tempdb заполняется на 70%, а также имеет более низкий приоритет, чем контрольные точки базы данных пользователей. Таким образом, эффективно, когда автоматическая контрольная точка в пользовательской базе данных / данных выдается и пытается завершиться, из-за интенсивного использования tempdb файл журнала tempdb быстро заполняется; при использовании журнала 70% контрольная точка tempdb встречается, но ставится в очередь за контрольной точкой базы данных пользователей.
За время, необходимое для завершения контрольной точки пользовательской базы данных, файл журнала tempdb постоянно заполняется, и, если установлен автоматический рост, файл журнала увеличивается, когда ему требуется больше места. Это причина, почему файл журнала продолжает расти.
Таким образом, наиболее вероятная основная причина описываемых вами симптомов связана с плохой реакцией ввода-вывода с дисков / лун для ваших пользователей и / или файлов базы данных / журнала базы данных tempdb.
Решение:
Мы обошли эту проблему, разбираясь с подсистемой ввода-вывода, настроив предупреждение, которое сработало, когда файл журнала tempdb заполнился на 75%, и в ответ выполнило задание, которое принудительно вызвало команду "CHECKPOINT"(которая имеет приоритет над автоматической системой). контрольные точки), очищая журнал tempdb, предотвращая его бесконечный автоматический рост. Это все еще хорошая идея, чтобы оставить файл журнала на автоматическом увеличении для любой другой возможности.
Надеюсь это поможет.