У меня установлен SQL 2005, и мой файл templog.ldf продолжает расти, занимая все свободное место на диске, на котором он находится. Иногда это останавливается с освобождением нескольких мегабайт, но иногда это идет дальше, это диск c, я думаю, это поведение может быть связано с некоторыми другими проблемами, которые я видел.
У меня вопрос: что мне делать? Я могу переместить журнал на другой диск, но у меня есть основания предполагать, что он не будет делать то же самое там. Я предполагаю, что такое поведение, вероятно, является результатом чего-то, что я могу изменить, и что 45 ГБ - это необычный размер для журнала tempdb. Мы действительно используем много временных таблиц и табличных функций в нашем коде, поэтому существует много возможностей для использования tempdb, я могу понять рост базы данных tempdb, но не понимаю причину роста templog.
До сих пор я запускал DBCC OPENTRAN ('tempdb'), чтобы проверить, нет ли каких-либо старых транзакций, а это не так. Я читал о том, как сжать tempdb, и делал это несколько раз, но мне действительно интересно, что, если что-нибудь, я могу сделать, чтобы это не происходило в первую очередь, или более подробно о том, почему он может так сильно расти в первое место.
== РЕДАКТИРОВАТЬ ==
1) База данных tempdb использует простую модель восстановления
2) Рост временного журнала происходит в течение пары часов утром, когда у нас выполняются некоторые запланированные запросы, в основном объем отчетов, которые заканчиваются в нерабочее время на следующий день. Размер файла за это время неуклонно растет. Мы контролируем, сколько одновременных отчетов выполняется одновременно, увеличение количества одновременных отчетов увеличивает скорость роста журнала.
У нас была аналогичная проблема, после того, как мы обратились в службу поддержки клиентов Microsoft и тщательно изучили проблему, мы рассмотрели следующие возможные причины и способы решения.
Причина:
Вероятная причина симптомов связана с тем, что на дисках / lun, на которых размещены пользовательские базы данных, возникают серьезные проблемы с ответами ввода-вывода; это приводит к тому, что автоматическая контрольная точка в пользовательских базах данных занимает очень много времени.
Теперь контрольная точка на базе данных tempdb возникает только тогда, когда журнал tempdb заполняется на 70%, а также имеет более низкий приоритет, чем контрольные точки базы данных пользователя. Таким образом, когда автоматическая контрольная точка в пользовательских базах данных выдается и пытается завершиться, из-за интенсивного использования tempdb файл журнала tempdb быстро заполняется; при 70% использовании журнала возникает контрольная точка tempdb, но она помещается в очередь после контрольной точки пользовательской базы данных.
По мере того, как контрольная точка пользовательской базы данных завершает работу, файл журнала tempdb продолжает заполняться, и если установлено автоматическое увеличение, файл журнала увеличивается, когда ему требуется больше места. Это причина того, что файл журнала продолжает расти.
Таким образом, наиболее вероятная основная причина описываемых вами симптомов связана с плохим ответом на ввод-вывод с дисков / lun для вашего пользователя и / или файлов базы данных / журнала tempdb.
Решение:
Мы работали над проблемой, пока разбирались с подсистемой ввода-вывода, настраивая предупреждение, которое запускалось, когда файл журнала tempdb становился заполненным на 75%, и в ответ выполняло задание, которое принудительно запускало «CHECKPOINT» вручную (которое имеет приоритет над автоматической системой контрольные точки), очищая журнал tempdb, предотвращая его неограниченный автоматический рост. По-прежнему рекомендуется оставить файл журнала на автоматическом увеличении на всякий случай. Кроме того, я настоятельно рекомендую вам подумать об уменьшении размера файла журнала tempdb до чего-то значимого для вашей среды после установки исправления.
Надеюсь это поможет.
Проверьте свои запросы отчетов. Есть ли у вас такие, в которых есть DISTINCT? Есть ли у кого-нибудь из них декартовы соединения?
Доступны ли какие-либо запросы отчетов к связанным серверам в качестве участников соединения? В таком случае это может вызвать рост журнала и базы данных tempdb.
Когда отчеты запускаются утром, у любого из них происходит сбой?
Какая модель восстановления установлена на временной базе данных? Если он не установлен на Simple, установите его на Simple. Это должно удерживать его от роста. Если для него уже установлено значение «Простой», я бы сказал, что существует основная проблема, которую необходимо решить, и любая попытка сжать файл просто устраняет симптомы проблемы, а не основную причину.
Последние несколько часов я читал и делал заметки по этому поводу
http://technet.microsoft.com/en-gb/library/cc966545.aspx
Там много деталей и предложений по устранению неполадок. Похоже, что если ваша tempdb не расширяется и никогда не перестает расти, она, вероятно, просто занимает необходимое пространство и изначально должна была быть настроена на этот размер. Есть раздел, посвященный оценке пространства, необходимого для вашей базы данных tempdb, а также отслеживанию того, что может занимать место в базе данных tempdb. В результате первое, что я собираюсь сделать, это переместить tempdb на диск большего размера и посмотреть, что оттуда произойдет.
Есть раздел под названием 'Пространство, необходимое для ведения журнала tempdb' который указывает, какие функции используют журнал, есть еще один более ранний раздел, в котором подробно описывается расширенный набор функций, использующих tempdb.
Раздел под названием 'Мониторинг ввода / вывода' есть несколько идей по счетчикам производительности, чтобы посмотреть, беглый взгляд на мой сервер поместил их на территорию, где у вас, вероятно, есть узкое место. Я буду следить за ними какое-то время и посмотрю, как все сложится. Файл журнала tempdb также фактически был загружен менее чем на 50%, что соответствует идее, что он расширялся под нагрузкой сегодня утром и с тех пор сохраняет это пространство.
Я иду дальше, исходя из того, что размер, до которого он вырос, - это тот размер, которым он должен быть, следить за этим размером в будущем и убедиться, что есть место для роста на любом диске, на котором он находится. Как предлагают некоторые здесь, я посмотрю, что выполняется при расширении временного журнала, и посмотрю, можно ли что-нибудь там настроить. Я также буду следить за этими счетчиками производительности io, чтобы увидеть, нужно ли с чем-то разобраться.
Был еще один интересный раздел под названием 'Обновление до SQL Server 2005' что указывает на то, что tempdb используется для большего количества вещей в 2005 году, чем в 2000 году (как новые функции, так и существующие функции, которые ранее не использовали tempdb). Я только недавно обновился до 2005 года, так что это может быть одной из причин, по которой это внезапно стало проблемой. Я не помню, чтобы где-нибудь такое было в связи с обновлением до 2005 года, что немного неудобно.
Скорее всего, это вызвано неконтролируемым запросом перекрестного соединения. Лучше всего использовать Profiler, чтобы найти его, а затем исправить.
Другой способ найти это - ограничить размер файла журнала TempDB, а затем подождать, чтобы увидеть, какой запрос завершится ошибкой. Однако я готов поспорить, что это уже терпит неудачу, и никто вам не говорит.
Если вы перезапустите механизм SQL, для файла будет установлен исходный размер. Вы должны установить максимальный размер для всех файлов автоматического увеличения.
Некоторые SQL-запросы или хранимые процессы делают плохие вещи - единственное, что вы можете сделать, это профилировать tempdb, чтобы перехватить событие «База данных: автоматический рост файла журнала», и когда это произойдет, используйте профилировщик и запросы к таким таблицам, как sysprocesses, чтобы найти понять, что это за плохой процесс.
К сожалению, проследить преступный процесс приходится лишь старомодным детективом.
Вы пытались изменить размер файлов журнала tempdb с помощью DBCC SHRINKFILE ()? Если да, то сколько времени нужно, чтобы с [очень маленькой стоимости] до 45 ГБ или более?