O artigo Melhores práticas de tempdb do SQL Server para aumentar o desempenho sugere que eu deveria dividir tempdb
em um número de arquivos igual ao número de núcleos. Portanto, para 4 núcleos, você obtém 4 arquivos.
Tendo o maior número de arquivos, você pode aumentar o número de operações físicas de E/S que o SQL Server pode enviar para o disco a qualquer momento. Quanto mais E/S 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 de que precisa 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 na memória.
Embora pareça bom em teoria, é realmente tão bom quanto uma otimização geral? É algo que pode ser aplicado apenas 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áquina tem sido a recomendação...
A última frase sempre foi relevante. Se você não está vendo contenção, por que adicionar arquivos adicionais? Para jogar pelo seguro, a maioria adicionará de 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 em sua luz mais positiva. Na melhor das hipóteses, é um bom ponto de partida (desde que você não esteja mantendo a proporção de 1:1 núcleo:arquivo de dados com uma grande quantidade de núcleos).
Não há substituto para o projeto adequado e monitoramento e linha de base apropriados . A razão por trás de ter vários arquivos de dados para tempdb é reduzir e mitigar a contenção da página de alocação. Existem inúmeras postagens publicadas sobre como monitorar essa contenção e agir de acordo. Abaixo estão alguns recursos:
Desmembrando a contenção do TempDB (parte 1)
Desmembrando a contenção do TempDB (parte 2)
Analisando a contenção
do TempDB Otimizando a configuração do tempdb com SQL Server 2012 Extended Events
Mas, para responder à sua pergunta, não, esta não é uma parte difícil e rápida de configurar e esquecer do tempdb .