Prática recomendada para o arquivo de log tempdb

11

Eu li muitos blogs aqui e ali sobre como configurar arquivos de dados tempdb, mas não encontrei nenhuma informação sobre o arquivo de log tempdb .

Aqui está a estratégia que estou usando atualmente com meu tempdb:

  • Eu usei as recomendações de Paul Randal sobre como dividir meus arquivos de dados tempdb
  • Eu configurei o tamanho dos meus arquivos de dados tempdb para o crescimento automático máximo e desativado. Por exemplo, tenho 100 GB de espaço livre em disco e defino o tamanho dos meus arquivos de dados de 8 tempdb como 10 GB cada. Isso evita a fragmentação no disco, conforme recomendado por Brent Ozar, e também tenho 20 gb grátis para o meu arquivo de log.

Mas, como eu disse, ninguém está falando sobre o arquivo de log tempdb . O que eu deveria fazer com isso? Na minha instalação, esse arquivo está no mesmo local que os arquivos de dados tempdb. Qual é o tamanho e o valor de crescimento automático que devo usar com o arquivo de log tempdb?

sql-server sql-server-2012 tempdb Alexandre Jobin
fonte
4
Não há uma resposta mágica para isso, exceto que eu não desabilitaria o crescimento automático para dados ou registro de tempdb, a menos que você queira que o sistema pare estridente se o crescimento automático for necessário. Eu nunca desabilitaria o crescimento automático em nenhum arquivo, porque, por mais que você planeje, sempre há situações anormais.
Aaron Bertrand
2
@AaronBertrand: ativar o crescimento automático em um tempdb de tamanho completo não ajudará. Eles já estão no máximo e podem estar na unidade. Não há mais espaço em disco que eles possam usar de qualquer maneira. É por isso que desabilitei o crescimento automático.
Alexandre Jobin
2
Então não importa se está desabilitado ou não, não é? Se um crescimento automático for necessário, ele falhará de qualquer maneira. Se você deixá-lo ativado, isso é menos uma coisa que você deve mudar quando perceber que talvez precise movê-lo para uma unidade maior.
Aaron Bertrand
1
PS 8 x 20> 100
Aaron Bertrand
1
Dividir seus arquivos não é necessariamente "uma boa configuração". Depende da sua configuração de hardware; que você não forneceu.
Paul

Respostas:

5

Realmente depende da quantidade de dados que fluirá pelo log de transações. Veja como o log fica grande hoje. Você precisa configurar o log para ter pelo menos esse tamanho quando o SQL iniciar. Para a maioria dos meus clientes, eles terminam com um log de transações de 3-4 Gig para o tempdb, que contém apenas alguns VLFs e tudo funciona bem e sem problemas.

mrdenny
fonte
0

Sempre me disseram para armazenar arquivos de log em uma matriz física / disco separada se o seu hardware puder gravar simultaneamente nos dados e efetuar logon ao mesmo tempo para melhorar o desempenho. Eu acho que a limitação que gerou seu limite de 20G tempdb pode definir uma resposta para o tamanho. Para crescimento automático, isso pode depender das transações que você está executando, além de espaço livre disponível e outros recursos no disco. Normalmente escolho arbitrariamente 1/6 do tamanho inicial.

Robert Gannon
fonte
0

Aaron está certo, a configuração do TempDB depende de muitas variáveis, como você planeja ou não usar o isolamento de instantâneo, etc. Aqui está um white paper mais antigo do SQL 2005 da MS / TN que pode ajudá-lo, uma vez que boa parte ainda se aplica. Especificamente, consulte o "Espaço necessário para o log do tempdb" para que você possa ver que tipos de transações são registradas no log do tempdb para poder configurar as coisas adequadamente. Provavelmente será o tipo de coisa que você precisará monitorar e ajustar com o tempo.

No que diz respeito ao crescimento autônomo do tempdb, desativei-o com relutância em um servidor de relatórios no passado e o comportamento que experimentei foi o de causar a interrupção e a reversão da transação de longa execução, liberando instantaneamente o espaço de log, mas que pode depender do O tipo de transação que, no meu caso, é de tipos massivos e operações de junção (consultas de relatório mal escritas). Concordo com Aaron e recomendo evitar isso, se possível, especialmente em situações de alto volume de transações.

Miketk
fonte