Como o nome sugere, TempDB é um espaço de trabalho temporário exigido pelo SQL Server para criar e manter objetos intermediários e temporários.
O TempDB é uma engrenagem significativa no aparato geral do SQL Server e como um espaço de trabalho temporário – os dados que ele contém são de natureza transitória. Em outras palavras, sua instância do SQL Server recria o TempDB toda vez que é reiniciado – dando a si mesmo um bloco de rascunho limpo com o qual ele pode trabalhar.
- objetos temporários acionados por solicitações do usuário
- objetos exigidos pelos processos internos do sistema
- informações de versão de linha
Escusado será dizer que, se o TempDB não estiver configurado de forma ideal, pode levar a gargalos operacionais e uma degradação no desempenho. Isso pode deixar você se perguntando por que suas consultas com junções complexas e operações de classificação não estão produzindo resultados tão rápido quanto o esperado.
Não há uma maneira fácil de generalizar sobre as melhores práticas para otimizar o TempDB, os cenários são muito diversos e o que funciona em uma determinada situação pode não funcionar em outra. Mesmo que seu banco de dados tenha entrado em produção, é sempre uma boa ideia continuar revisando a configuração do TempDB para garantir que ele esteja configurado como deveria.
Um dos problemas mais sérios no desempenho do banco de dados é a contenção do TempDB. Isso acontece quando vários recursos exigem TempDB, mas há apenas um único arquivo de dados TempDB para acessar.
A contenção do TempDB pode causar sérios problemas de desempenho e muitas vezes é mal interpretada como um bloqueio normal devido a bloqueios de banco de dados. Muitas vezes, na verdade, é uma contenção travada nas páginas de alocação por processos simultâneos. Isso pode levar a gargalos, pois cada processo aguarda sua vez. Como a virada não chega rápido o suficiente, o tempo limite das conexões subjacentes e os processos precisam ser desalocados.
O que você ganha? Um engarrafamento virtual de processos bloqueados.
Como resolver a contenção do TempDB e otimizar o desempenho do SQL Server? Vamos dar uma olhada no básico e trabalhar nosso caminho a partir daí.
Número de arquivos de dados – Quantos devo ter?
Ao configurar o SQL Server e manter a configuração padrão, você terá apenas um único arquivo de dados para TempDB. Não se contente com esta configuração.
Uma das regras práticas frequentemente elogiadas é um único arquivo de dados por núcleo. Mas prossiga com cuidado neste caso, se o seu servidor tiver 12 núcleos, não use 12 arquivos de dados TempDB, a menos que seja justificado pelo aplicativo e pelos requisitos de carga.
A melhor opção, dadas as configurações de hardware atuais, é começar com 8 arquivos de dados primários de tamanho igual e ver se o problema de contenção foi resolvido. Trabalhe seu caminho para cima e adicione mais quatro arquivos, se necessário. O assistente de instalação e configuração do SQL Server 2016 possui um recurso interno que garante que você tenha um número suficiente de arquivos de dados TempDB detectando o número de núcleos de CPU e criando automaticamente o número apropriado de arquivos de dados TempDB.
O tamanho importa – Como os arquivos de dados devem ser configurados para o tamanho?
Agora que cobrimos o número de arquivos, vamos dar uma olhada no tamanho recomendado de cada arquivo. O tamanho padrão é 8 MB, o que fornece ao SQL Server um total de 64 MB de espaço TempDB, insuficiente para a maioria dos ambientes de produção. Manter o Autogrowth também é uma opção, mas o SQL Server terá que pausar e alocar mais espaço em disco para os arquivos TempDB quando necessário – adicionando uma sobrecarga significativa ao SQL Server durante uma execução de produção.
A prática recomendada é manter os arquivos e o espaço inicial necessário para cada arquivo em aproximadamente 80 a 90% do volume no qual o TempDB está armazenado. O espaço em disco de 10 a 20% é deixado para a memória virtual baseada em SO.
Em outras palavras, pré-dimensione os arquivos de dados durante a configuração ou altere o tamanho dos arquivos no ambiente de produção. Isso garantirá que espaço em disco suficiente seja alocado para TempDB. Manter a opção Autogrowth ativada é sempre recomendado neste momento, mas, idealmente, tente garantir que o SQL Server não precise alocar espaço em disco adicional com muita frequência.
Um fato interessante, antes do SQL Server 2017, não era possível alocar mais de 1 GB por arquivo de dados TempDB no momento da configuração. Com a versão mais recente, é possível alocar até 256 GB para um arquivo de dados TempDB durante a configuração.
O que nos leva à próxima pergunta:
Onde mantenho os arquivos de dados TempDB?
Antes do SQL Server 2012, no caso de um ambiente clusterizado, o TempDB precisava estar localizado em discos compartilhados entre o ambiente clusterizado, como uma rede de área de armazenamento (SAN). A partir do SQL Server 2012, é possível manter os arquivos de dados TempDB no armazenamento local baseado em SSD. Isso reduz o que teria sido muito tráfego entre a SAN compartilhada e a instância do SQL Server.
Na maioria dos casos, a melhor opção para a localização do TempDB é um SSD local dedicado. Se isso não for possível, mantê-lo em um volume dedicado próprio, com espaço em disco suficiente pré-alocado deve resolver prováveis problemas de desempenho. Certifique-se de monitorar constantemente a integridade do disco para que as leituras e gravações de disco sejam realizadas em um nível ideal.
Idealmente, a mídia deve ser a mais rápida possível, considerando a configuração do servidor, os requisitos do aplicativo e, por último, mas não menos importante, o orçamento alocado.
Agora que vimos o básico, vamos ver as adições relevantes e bem-vindas a várias adições do SQL Server após o SQL Server 2012.
O que mais é novo?
SQL Server 2016
Guia dedicada durante a configuração
- Com esta edição, o SQL Server tem uma guia dedicada para configuração do TempDB durante o fluxo de trabalho de configuração
- O assistente de instalação e configuração do SQL Server 2016 tem um recurso interno que garante que você tenha um número suficiente de arquivos de dados TempDB no momento da instalação do SQL Server. Ele detecta o número de núcleos de CPU e cria automaticamente arquivos de dados TempDB, sujeitos a um máximo de 8. Você pode aumentar esse número após configurar o SQL Server.
Inicialização instantânea do arquivo
- O SQL Server precisa alocar espaço em disco para TempDB durante a configuração inicial, bem como quando o tamanho do arquivo aumenta em uma execução de produção. Essa alocação pode ser possível de duas maneiras. A primeira maneira é inicializar o espaço em disco não utilizado escrevendo zeros antes de alocar o espaço. A segunda maneira é alocar instantaneamente espaço no arquivo para o crescimento do TempDB.
- No primeiro método, o SQL Server precisa realizar uma operação intensiva em disco inicializando cada cluster de disco lógico. Nesse método, os processos em execução no servidor que precisam do TempDB podem ter que esperar, criando um gargalo.
- Se você optar por alocar instantaneamente espaço no arquivo, o SQL Server alocará instantaneamente espaço para Autogrowth sem inicializar espaço em disco. Isso reduz a E/S de disco sempre que há um requisito de Autogrowth e garante melhor rendimento e desempenho. Embora tenha sido possível ativar o IFI em edições anteriores, foi um processo complicado. Nesta edição do SQL Server, é mais fácil configurar o IFI no momento da configuração do servidor.
- Os sinalizadores de rastreamento 1117 e 1118 são redundantes
SQL Server 2017
- Antes do SQL Server 2017, não era possível alocar mais de 1 GB por arquivo de dados TempDB no momento da instalação, o que significava que o tamanho do arquivo TempDB precisava ser aumentado após a conclusão da instalação. Com esta versão, é possível alocar até 256 GB para um arquivo de dados TempDB durante a instalação.
Monitorando TempDB
Manter o controle do TempDB pode ser difícil. Como você pode saber se está tendo contenção TempDB? O que está sendo alocado para objetos de usuário, armazenamento de versão ou objetos internos? Como estão essas tendências ao longo do tempo? Quais sessões estão consumindo o TempDB e em que grau? O Spotlight Cloud facilita a resposta a essas perguntas. Ele monitora todos os aspectos do desempenho do servidor SQL 24 horas por dia, 7 dias por semana e fornece fluxos de trabalho analíticos profundos para resolver qualquer problema de desempenho. Acompanhe seu TempDB ao longo do tempo e receba alertas automatizados de especialistas sobre configuração.
Como solução SaaS, o Spotlight Cloud é fácil de instalar e configurar. Ele retém dados de desempenho de até um ano, fornecendo insights de ajuste imbatíveis. Problemas de desempenho podem ser resolvidos em segundos com análise de causa raiz. Não perca mais tempo vasculhando scripts complexos - comece seu teste de 30 dias agora. O monitoramento de desempenho de alto nível do SQL Server começa agora.
