Olá a todos,

O TempDB é o local onde o SQLServer faz diversas operações, armazenando temporariamente objetos como tabelas, cursores, ordenações, modificações nos índices, e muitos outros, sendo um recurso compartilhado entre todo o sistema e para todos os usuários.

Operações muito longas podem manter o TempDB ocupado por um tempo muito longo, causando lentidão para retorno de algumas operações. Por mais que tomemos cuidados para que estes comandos impactem o mínimo possível na operação do banco, devemos também estar atentos a pequenas questões de configuração do banco de dados.

Para entender um pouco sobre o porque o TempDB pode atrapalhar na performance, vamos entender um pouco o funcionamento da paginação do SQLServer.

Entendendo um pouco sobre páginas

O SQLServer organiza seus dados em páginas de 8KB, por padrão agrupadas de 8 em 8. Estes agrupamentos são chamados “Extensões” (seria a tradução de Extent). Estas Extensões são organizados em áreas chamadas GAM (Global Allocation Map) e SGAM (Shared Global Allocation Map), que armazenam dados de 64000 páginas (em torno de 4GB) cada.

Quando temos objetos muito pequenos, como variáveis, tabelas temporárias ou cursores, nós temos as “Extensões Mistas”, que são compostas por vários objetos distintos no mesmo grupo de páginas. Quando a Extensão possui apenas dados de um mesmo objeto, ela é uma “Extensão Uniforme”.

A GAM registra quais extensões de páginas estão alocadas, tendo um bit para cada Extensão, onde o 1 indica que a Extensão está livre e o 0 indica que está sendo usada.

A SGAM registra qual a página que possui a informação se a Extensões é Mista e se possui pelo menos uma página livre, indicado pelo bit 1. Caso a Extensão Mista não possua página livre, ou seja não seja mista, haverá o bit 0.

Paginas SQL

Problema de se ter muitas Extensões Mistas

Pra um mesmo SGAM, toda vez que apagamos, criamos ou recuperamos um objeto no TempDB, o SQLServer acessa o SGAM a procura dentre todos os 4GB, em qual das Extensões mistas tem espaço para melhor alocar o objeto. Após a alocação, o SQLServer atualiza a informação  de uso destas páginas.

Quando temos muitas Extensões Mistas alocadas, causamos muitos acessos no SGAM e o tornando indisponível por alguns instantes.

 

Porque ter mais de um TempDB

Este é o problema de se ter um único TempDB, enquanto um processo o usa, outro está aguardando pelos mesmos recursos. Se você tiver por exemplo 4 arquivos para TempDB, você terá 4 SGAMs independentes organizando o uso destes recursos, e com 4 arquivos de TempDB sendo usados, a chance de concorrência diminui e ganhamos desempenho.

Porém, um ponto de atenção é que ter vários TempDBs só funciona realmente quando todos os arquivos possuem o mesmo tamanho e o mesmo “auto-growth”. Caso contrário, o arquivo maior cairá sempre no mesmo caso de problema de se ter um único TempDB.

 

O problema de se ter muitos TempDB

É muito comum ver na internet várias pessoas indicando que você tenha um TempDB por core, porém devemos ter muito cuidado com isto, em um servidor com 40 cores por exemplo, o overhead de gerenciar tantos arquivos para alocação de objetos toma mais tempo do que ter menos arquivos, principalmente se os dados tiverem que ser distribuídos em mas de um TempDB, como no caso de fazer uma ordenação muito grande.

O ideal é começar com alguns poucos arquivos (4 por exemplo) e monitorar o acesso e uso do TempDB para decidir entre incluir ou não mais um arquivo.

 

Conclusão

Inicie com 4 arquivos de TempDB, com o mesmo tamanho e o mesmo “auto-growth incremente” para eles, e monitore continuamente seu sistema para decidir se e quando incluir um novo arquivo de TempDB.