Мой файл templog.ldf огромен (45 ГБ). Что мне делать?

У меня установлена ​​SQL 2005, и мой файл templog.ldf продолжает расти, занимая все свободное место на диске, на котором он находится. Иногда он останавливается с несколькими свободными мегабайтами, но иногда он идет дальше, это диск c, я думаю, что это поведение может быть связано с некоторыми другими проблемами, которые я видел.

Мой вопрос: что мне делать, я могу перенести журнал на другой диск, но у меня есть основания полагать, что он не будет делать то же самое там. Я предполагаю, что такое поведение, вероятно, является результатом того, что я могу изменить, и что 45 ГБ - это необычный размер для журнала tempdb. Мы используем много временных таблиц и табличных функций в нашем коде, поэтому у нас есть много возможностей для использования базы данных tempdb, я могу понять, как растет база данных tempdb, но не понимаю причины роста журнала templog.

До сих пор я запускал DBCC OPENTRAN ('tempdb'), чтобы посмотреть, не торчат ли какие-нибудь старые транзакции, а нет. Я читал о том, как уменьшить базу данных tempdb, и делал это несколько раз, но мне действительно интересно, что если я смогу что-либо сделать, чтобы остановить это в первую очередь, или больше подробностей о том, почему он может так сильно расти в первое место.

== редактирует ==

1) Tempdb использует простую модель восстановления

2) Рост временных журналов происходит в течение пары часов утром, когда у нас выполняются некоторые запланированные запросы, в основном из-за загрузки отчетов, которые заканчиваются в нерабочее время на следующий день. Размер файла неуклонно растет за это время. Мы контролируем, сколько одновременных отчетов запускается одновременно, увеличение количества одновременных отчетов увеличивает скорость, с которой растет журнал.

Проверьте ваши запросы отчетности. Есть ли у вас что-нибудь с DISTINCT? У кого-нибудь из них есть декартовы объединения?

Имеют ли какие-либо из запросов отчетов доступ к связанным серверам в качестве членов объединения? Если это так, это может привести к росту журнала базы данных и базы данных.

Когда отчеты запускаются утром, происходит ли сбой любого из них?

У нас была похожая проблема, после того, как мы подняли PSS call с Microsoft и тщательно изучили проблему, мы разделили следующую возможную причину и решение.

Причина:

Вероятная причина симптомов связана с дисками / лунками, на которых размещены пользовательские базы данных, с серьезными проблемами ответа ввода-вывода; это приводит к тому, что автоматическая проверка в пользовательских базах данных занимает очень много времени.

Теперь контрольная точка на базе данных tempdb возникает только тогда, когда журнал базы данных tempdb заполняется на 70%, а также имеет более низкий приоритет, чем контрольные точки базы данных пользователей. Таким образом, эффективно, когда автоматическая контрольная точка в пользовательской базе данных / данных выдается и пытается завершиться, из-за интенсивного использования tempdb файл журнала tempdb быстро заполняется; при использовании журнала 70% контрольная точка tempdb возникает, но ставится в очередь за контрольной точкой базы данных пользователей.

За время, необходимое для завершения контрольной точки пользовательской базы данных, файл журнала tempdb постоянно заполняется, и, если установлен автоматический рост, файл журнала увеличивается, когда ему требуется больше места. По этой причине файл журнала продолжает расти.

Таким образом, наиболее вероятная основная причина описываемых вами симптомов связана с плохой реакцией ввода-вывода с дисков / лун для ваших пользователей и / или файлов базы данных / журнала базы данных tempdb.

Решение:

Мы обошли эту проблему, разбираясь с подсистемой ввода-вывода, настроив оповещение, которое сработало, когда файл журнала tempdb заполнился на 75%, и в ответ выполнило задание, которое принудительно вызвало команду «CHECKPOINT» (которая имеет приоритет над автоматической системой). контрольные точки), очищая журнал tempdb, предотвращая его бесконечный автоматический рост. Это все еще хорошая идея, чтобы оставить файл журнала на автоматическом увеличении для любой другой возможности. Кроме того, я настоятельно рекомендую вам рассмотреть возможность уменьшения размера файла журнала tempdb до чего-то значимого в соответствии с вашей средой после внесения исправления.

Надеюсь это поможет.

Для чего установлена ​​модель восстановления на временную базу данных? Если не установлено значение «Простой», установите значение «Простой». Это должно держать его от роста. Если он уже установлен в значение «Простой», я бы сказал, что есть основная проблема, которую необходимо решить, и любая попытка уменьшить файл - это просто лечение симптомов проблемы, а не ее основной причины.

Я провел последние несколько часов, читая и делая заметки на этом

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 ГБ или более?