Лучшая практика для файла журнала tempdb

11

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

Вот стратегия, которую я сейчас использую с моим tempdb:

  • Я использовал рекомендации Пола Рэндала о том, как разделить мои файлы данных tempdb
  • Я установил максимальный размер моих файлов с данными tempdb и отключил автоматический рост. Например, у меня есть 100 ГБ свободного дискового пространства и я установил размер моих 8 файлов данных tempdb на 10 ГБ каждый. Это предотвращает фрагментацию на диске, как рекомендовано Брентом Озаром, а также у меня есть 20 ГБ свободного места для моего файла журнала.

Но, как я уже сказал, никто не говорит о файле журнала tempdb . Что мне с этим делать? На моей установке этот файл находится в том же месте, что и файлы данных tempdb. Каков размер и значение автоматического роста, которые я должен использовать с файлом журнала tempdb?

sql-server sql-server-2012 tempdb Александр джобин
источник
4
На это нет никакого волшебного ответа, за исключением того, что я не отключил бы авторастение для данных или журнала tempdb, если вы абсолютно не хотите, чтобы система остановилась, если понадобится автоматическое наращивание. Я бы никогда не отключил автогроу для любого файла, потому что независимо от того, насколько хорошо вы планируете, всегда есть ненормальные ситуации.
Аарон Бертран
2
@AaronBertrand: включение автоматического роста на полноразмерной базе данных tempdb не поможет. Они уже по максимуму могут быть на драйве. Там нет больше места на диске, что они могут использовать в любом случае. Вот почему я отключил автостров.
Александр Жобин
2
Тогда не имеет значения, если он отключен или нет, не так ли? Если требуется автогроу, он потерпит неудачу в любом случае. Если вы оставите его включенным, это будет меньше, чем вам нужно изменить, когда вы поймете, что, возможно, вам нужно переместить его на больший диск.
Аарон Бертран
1
PS 8 x 20> 100
Аарон Бертран
1
Разделение ваших файлов не обязательно "хорошая установка". Это зависит от конфигурации вашего оборудования; который вы не предоставили.
Пол

Ответы:

5

Это действительно зависит от того, сколько данных будет проходить через журнал транзакций. Посмотрите, насколько большим становится журнал сегодня. При запуске SQL необходимо настроить журнал как минимум на тот же размер. Для большинства моих клиентов они получают журнал транзакций 3-4 Gig для базы данных tempdb, который содержит всего несколько VLF, и все работает хорошо и гладко.

mrdenny
источник
0

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

Роберт Гэннон
источник
0

Аарон прав, настраивая TempDB, зависит от множества переменных, таких как, планируете ли вы использовать изоляцию моментальных снимков и т. Д. Вот более старая техническая документация по SQL 2005 от MS / TN, которая может вам помочь, поскольку значительная ее часть все еще применима. В частности, обратите внимание на «Пространство, необходимое для ведения журнала tempdb», чтобы вы могли видеть, какие виды транзакций регистрируются в журнале tempdb, чтобы вы могли настроить их соответствующим образом. Скорее всего, это будет то, что вам придется отслеживать и настраивать с течением времени.

Что касается authogrowth для базы данных tempdb, я неохотно отключал это на сервере отчетов в прошлом, и я столкнулся с тем, что это приводило к прерыванию и откату долго выполняющейся транзакции, что мгновенно высвобождает пространство журнала, но это может зависеть от тип транзакции, который в моем случае был массовыми сортировками и операциями соединения (плохо написанные запросы отчетов). Я согласен с Аароном и рекомендую избегать этого, если это возможно, особенно в ситуациях с большим объемом транзакций.

Miketk
источник