Divisão do TempDB em múltiplos arquivos iguais ao número de CPUs

O artigo Práticas recomendadas para aumentar o desempenho do tempdb do SQL Server sugere que eu devo dividir tempdbem um número de arquivos igual ao número de núcleos. Assim, para 4 núcleos, você obtém 4 arquivos.

Por ter o maior número de arquivos, você pode aumentar o número de operações de E / S físicas que o SQL Server pode enviar ao disco a qualquer momento. Quanto mais E / S que o SQL Server puder enviar para o nível do disco, mais rápido o banco de dados será executado. Com bancos de dados padrão, o SQL Server pode armazenar em cache uma grande quantidade de dados necessários na memória. Devido à natureza de alta gravação do tempdb, os dados precisam ser gravados no disco antes que possam ser armazenados em cache novamente na memória.

Embora pareça bom em teoria, é realmente tão bom como uma otimização geral? É algo que só pode ser aplicado a sistemas específicos em que o IO é muito alto?

Uma proporção de 1/4 a 1/2 vezes o número de arquivos de dados TempDB para núcleos de máquinas é uma recomendação há muito tempo ...

Mas agora há orientações ainda melhores. No PASS, em 2011, meu bom amigo Bob Ward, que é o principal funcionário do Suporte ao Produto SQL, adotou uma nova fórmula: se você tiver menos de 8 núcleos, use #files = #cores. Se você tiver mais de 8 núcleos, use 8 arquivos e, se estiver vendo uma contenção na memória, adicione mais 4 arquivos por vez. [ligação]

A última frase sempre foi relevante. Se você não vê uma disputa, por que adicionar arquivos adicionais? Por segurança, a maioria adicionará 2 a 4 arquivos como ponto de partida para a maioria das compilações, mas além disso, meça e reaja.

Como a maioria das diretrizes gerais , é uma simplificação excessiva sob sua luz mais positiva. Na melhor das hipóteses, é um bom ponto de partida (desde que você não mantenha a proporção 1: 1 do núcleo: arquivo de dados com uma grande quantidade de núcleos).

Não há substituto para o design adequado, o monitoramento e a linha de base adequados . O motivo por trás de vários arquivos de dados para o tempdb é reduzir e mitigar a contenção da página de alocação. Existem inúmeras postagens publicadas sobre como monitorar esta contenção e tomar medidas em conformidade. Abaixo estão alguns recursos:

Quebrando a contenção do TempDB (parte 1)
Quebrando a contenção do TempDB (parte 2)
Analisando a contenção do Tempdb
Otimizando a configuração do tempdb com eventos estendidos do SQL Server 2012

Mas, para responder à sua pergunta, não, isso não é uma parte difícil e rápida de configurar e esquecer do tempdb .