Contenções TempDB

Temos um banco de dados OLTP ativo de 40 GB no SQL Server 2014 SP1. As consultas são lentas com as esperas de IO_Completion, o comprimento da fila de disco subindo para 900 e o SQL Server para de responder. O que tentamos:

1. Reinicie a instância e, em um minuto, ela começará a se comportar da mesma maneira.

2. Após a segunda reinicialização, alteramos o tamanho inicial de cada arquivo de dados tempdb (existem 16 arquivos de dados criados) e ele começa a funcionar corretamente.

Nota: Estamos usando variáveis ​​de tabela para conjuntos de resultados intermediários. Esses conjuntos de resultados são muito pequenos.

Aconteceu duas vezes em um mês. Sempre que adiciono um pouco de espaço manualmente aos arquivos de dados, ele começa a funcionar normalmente. O mais interessante é que a mesma configuração (mesmo hardware, mesma configuração de pastas e arquivos, mesma carga de trabalho) que temos no SQL Server 2008 R2 e no SQL Server 2012 está funcionando bem.

Por favor, ajude-nos a encontrar uma solução permanente.

O tamanho inicial de todos os arquivos de dados é o mesmo 1000 MB, o atual é 1500 MB cada. Todos são idênticos. O crescimento automático é de 100 MB para cada um. Antes disso, estávamos enfrentando contenção de páginas PFS e GAM e aumentamos para 16 e o ​​problema foi resolvido. Ambos os sinalizadores de rastreamento 1117 e 1118 estão ativados. 24 núcleos em 2 nós NUMA. Todos os arquivos de dados estão no mesmo volume. Disco simples, sem SAN.

A instância está em uma máquina física. As consultas com variáveis ​​de tabela e as consultas com junções de hash geralmente geram esperas de IO_Completion.

A resposta detalhada do wBob nos levou a pesquisar mais detalhadamente. Como nós perdemos isso antes:

O crescimento automático do arquivo 'templog' no banco de dados 'tempdb' foi cancelado pelo usuário ou atingiu o tempo limite após 7704 milissegundos. Use ALTER DATABASE para definir um valor menor de FILEGROWTH para este arquivo ou para definir explicitamente um novo tamanho de arquivo.

Encontramos isso no log sempre que esse tipo de problema está ocorrendo. Estamos movendo o TempDB para separar o drive rápido.

Acho que você superfragmentou o tempdb e há uma incompatibilidade entre a CPU do servidor e a configuração do disco, mas vamos coletar mais algumas informações:

Perguntas / Mais informações necessárias

• Por favor, confirme o nome e o tipo do processador (basicamente estou tentando estabelecer se é 2 x hex-core com HT). Use as informações do sistema (por exemplo, Painel de controle> Sistema e segurança> Sistema no Windows Server 2012 R2) e / ou a ferramenta sysinternals CoreInfo para confirmar.
• Por favor, confirme o servidor maxdop (por exemplo, EXEC sp_configure 'max degree of parallelism' ). Se as CPUs forem de núcleo hexadecimal, o servidor maxdop deverá ter no máximo 6 (conforme aqui ), ou talvez um valor mais baixo em um sistema OLTP. Normalmente, mantenho meus arquivos tempdb alinhados com o DOP do servidor até um máximo de 8, mas entraremos nisso.
• Confirme a memória total do servidor na caixa e o limite de memória do SQL Server (por exemplo EXEC sp_configure 'max server memory (MB)').
• Confirme se há outros serviços em execução na caixa (por exemplo, SSIS, SSAS, SSRS, o aplicativo, iTunes etc.)
• Confirme se a inicialização instantânea de arquivos está ativada para a conta de serviço do SQL Server. (Maneiras de testá-lo aqui ).
• Por que existe uma discrepância tão grande entre a CPU (configuração NUMA robusta de 2 nós) e o disco único (PC doméstico)? Considere adicionar discos, distribuição e SSD para tempdb (embora evite reagir em excesso) .
• Adicione um plano de execução real para uma das consultas com problemas. Anonimize com o SQL Sentry Plan Explorer, se desejar.

• Hash se junta a variáveis ​​de tabela em um sistema OLTP? Isso sugere uma falta de indexação na variável da tabela, na tabela principal ou em ambas. Você está declarando suas variáveis ​​de tabela como esta (sem índices)?

  DECLARE @t TABLE ( x INT )

• Não economize na definição de variável da tabela, mesmo que ela esteja mantendo pequenos conjuntos de resultados. É sempre melhor fornecer ao otimizador o máximo de informações possível, para que seja explícito com exclusividade, exclusividade, independentemente de o índice estar ou não em cluster / não em cluster, por exemplo,

  DECLARE @t TABLE ( x INT PRIMARY KEY )
  DECLARE @u TABLE ( x INT PRIMARY KEY NONCLUSTERED, u INT NOT NULL UNIQUE CLUSTERED, z INT NOT NULL UNIQUE, a CHAR(1) NULL ) -- not sure why you would do this but you can
  DECLARE @v TABLE ( x INT NOT NULL, y INT NOT NULL, PRIMARY KEY ( x, y ) )   -- multi-column primary key

• A publicação do plano de execução ajudará a diagnosticar isso.

• Verifique o código que impede o armazenamento em cache da variável de tabela, conforme aqui , aqui . Eu acho que SQL dinâmico e proc executados com RECOMPILE são os únicos que afetam as variáveis ​​da tabela.

  DECLARE @u TABLE ( x INT )
  
  INSERT @u
  EXEC('DECLARE @t TABLE ( x INT ); INSERT INTO @t VALUES ( 1 ); SELECT x FROM @t;' )
  
  SELECT *
  FROM @u

• Verifique o log do SQL Server (Pesquisador de objetos> Gerenciamento> Logs do SQL Server) para obter mensagens, por exemplo, avisos de E / S.

• Verifique o Visualizador de Eventos do Windows
• Houve várias compilações lançadas desde o SP1. Revise as correções de CU inseridas desde o SP1 . É possível que haja erros no SP1 corrigidos nas UCs ​​subsequentes, por exemplo, CORRECÇÃO: O operador de classificação se espalha para tempdb no SQL Server 2012 ou no SQL Server 2014 quando o número estimado de linhas e o tamanho da linha estão corretos https://support.microsoft.com/en- eua / kb / 3088480
• Estabeleça essa é sua causa antes de aplicar qualquer hotfix, embora seja mais importante manter-se atualizado com as CUs com o SQL Server 2014, devido ao número de novos recursos (OLTP na memória, columnstore armazenado em cluster).
• Finalmente, a necessidade de um arquivo tempdb por núcleo é um mito e, olhando para a configuração do disco, acho que o tempdb está excessivamente fragmentado. Sinto que você tem uma cabeça de disco, o tempdb tem um grupo de arquivos, muitos arquivos.

No entanto, esqueça o que pensamos que sabemos; crie uma plataforma de teste que reproduza seu problema e experimente reduzir o número de arquivos temporários ... comece em 1, 2, 4, 6 etc. colete as informações para tomar uma decisão baseada em evidências. Agora, essa é a parte mais difícil, pois seu problema parece intermitente e você pode não conseguir mexer na configuração do tempdb, mas é assim que eu abordaria isso.

Boa sorte. Deixe-nos saber como você se sai.