Prática recomendada para o arquivo de log tempdb

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

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

@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

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

PS 8 x 20> 100

— Aaron Bertrand

Dividir seus arquivos não é necessariamente "uma boa configuração". Depende da sua configuração de hardware; que você não forneceu.

— Paul

Respostas:

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

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

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