Por que as consultas estão causando o derramamento em tempdb?

fundo

Estou migrando um banco de dados de 160 GB do MSSQL 2008 (padrão) em um servidor Win 2008 com 48 GB de RAM para um novo servidor executando o MSSQL 2012 (edição da web de 64 bits) no Windows 2012 com 64 GB de RAM. O servidor antigo está ativo e sob carga; o novo servidor não está em produção. O novo servidor possui 8 arquivos tempdb (4 GB cada).

Problema

Nos testes no novo servidor, estou vendo etapas em várias consultas que causam alertas mencionando "o operador usou o tempdb para espalhar dados durante a execução". Consegui evitar tipos reescrevendo algumas das consultas, mas isso realmente não está solucionando o problema. As mesmas consultas no servidor antigo não causam derramamentos. Eu li que derramamentos acontecem quando o MSSQL não pode concluir uma operação na memória e precisa derramar / página no tempdb. Devo me preocupar com derramamentos?

Exemplos

insira a descrição da imagem aqui

Eu executei sp_updatestats no banco de dados, portanto, as estatísticas devem estar atualizadas, mas você observará que existem algumas discrepâncias entre o número estimado e real de linhas.

Preocupação com a memória

Eu configurei uma configuração de memória máxima para o MSSQL de 58 dos 64gb. Atualmente, o MSSQL consumiu cerca de 35 GB dessa memória, mas possui um conjunto de trabalho de apenas 682 MB. O servidor antigo (embora em produção, manipulando carga) possui 44 GB de memória confirmada no MSSQL, dos quais 43,5 GB estão em seu conjunto de trabalho.

insira a descrição da imagem aqui

Não sei se os derramamentos podem estar relacionados a uma configuração de memória - alguém tem alguma idéia? Atualmente, o MSSQL tem muitos acres de RAM de sobra, então por que está se espalhando no tempdb para alguns tipos e correspondências de hash?

sql-server sql-server-2012

— Andy W
fonte

O alerta no plano de execução é novo em 2012. Você verificou se não estava derramando o tempo todo no servidor antigo? Você estava monitorando isso?

— Martin Smith

@ MartinSmith ah, não sabia que o alerta era novo. Eu não estava monitorando derramamentos no servidor antigo. Irá investigar isso.

Ponto ligeiramente tangente, mas estou sentado na frente de uma junção de tabela 10 que, por padrão, usa junções de mesclagem com estimativas de linha muito boas que causam derramamentos no nível 0 do tempdb e tempo de execução 25s. Forçar junções de hash (e ordem) remove os derramamentos e corre em 9s. Fiquei me perguntando se é a mesclagem versus o hash ou o vazamento que causa a diferença e se o otimizador está ponderando adequadamente o efeito de um vazamento aparentemente conhecido (porque as estimativas de linha são muito boas).

— 23414 crokusek

O novo servidor possui hardware numa?

— Stacylaray

Há várias perguntas diferentes aqui:

P: Por que as consultas não estavam sendo respondidas antes?

Eles estavam, mas o SQL Server Management Studio não apresentou isso como um erro claro antes do SQL 2012. É um ótimo exemplo de por que, ao fazer o ajuste de desempenho, você precisa ir mais longe do que o plano de execução gráfica.

P: Por que as consultas se espalham para o disco?

Porque o SQL Server não lhes concedeu memória suficiente para concluir suas operações. Talvez o plano de execução subestime a quantidade de memória necessária, ou talvez a caixa esteja sob pressão de memória, ou sejam apenas grandes consultas. (Lembre-se, o SQL Server usa memória para três coisas: armazenar em cache páginas de dados brutos, armazenar em cache planos de execução e espaço de trabalho para consultas. Essa memória do espaço de trabalho acaba sendo bastante pequena.)

P: Como posso reduzir derramamentos?

Escrevendo instruções T-SQL sargáveis, tendo estatísticas atualizadas, colocando memória suficiente no servidor, criando os índices corretos e interpretando os planos de execução quando as coisas não funcionam da maneira esperada. Confira o livro SQL Server Query Performance Tuning do livro de Grant Fritchey para obter explicações detalhadas de todas elas.

— Brent Ozar
fonte