Contenção de DDL no TempDB

Eu tenho um SQL Server 2005 Standard x64 que está enfrentando problemas com a contenção de TempDB DDL nos últimos meses. O servidor enfrentará contenção no recurso de espera 2: 1: 103 (o tipo de espera sendo PAGELATCH_EX).

O problema parece ocorrer esporadicamente quando o servidor está com carga decente. Eu tenho monitorado a taxa "Tabelas temporárias para destruição" e ela pode subir para mais de 5.000 em momentos em que temos problemas com PAGELATCH_EX em 2: 1: 103. Pelo que li, esse contador deve ser 0 na maioria das vezes, mas o nosso parece permanecer entre 300 e 1100 a maior parte do tempo. O contador só vai para 0 quando há muito poucos usuários no sistema.

Como posso diminuir o que está causando a contenção de DDL no tempdb sem precisar procurar uma agulha em uma pilha de feno?

Eu já vi esse problema e o hotfix lançado para corrigi-lo foi na verdade um resultado direto do meu caso com o Microsoft CSS. Não há artigo público da KB para a correção. Verifique se você aplicou o Service Pack 4 e a atualização cumulativa mais recente no SQL Server (no momento da redação, a atualização cumulativa nº 3 (9.00.5259) ).

Até o lançamento do hotfix, a sugestão da Microsoft era simplesmente parar de criar #temp tables (bem como KB # 916086 ). Como isso significaria uma reescrita substancial de dezenas e dezenas de procedimentos de relatório, a solução alternativa no meu caso (independentemente dos sinalizadores de rastreamento ou layout do arquivo temporário) era reiniciar nosso cluster a cada dois fins de semana. Que nojo.

Para rastrear o uso do tempdb, existem vários scripts que podem ajudar, por exemplo, consulte sp_whoIsActive de Adam Machanic , especificamente:

• sp_whoisactive: Analisando a Contenção Tempdb
• Como identificar qual consulta está preenchendo o log de transações tempdb?

E também este script (e os dos comentários) de @SQLSoldier:

• Quebrando a contenção do TempDB

Gostaria de garantir que todos os seus cursores estejam usando LOCAL STATIC READ_ONLY FORWARD_ONLY(veja isso e isso ) e verifique se existem consultas caras conhecidas que fazem uso extensivo de #temp tables / @table tables, CTEs ou podem conter tipos desnecessários ou levar a junções de hash ... tudo isso pode contribuir para o problema (duvido que você encontre uma causa de ouro). A correção de varredura mais fácil como um ponto de partida para "gastar o seu dinheiro" será usar opções de cursor adequadas e baratas em vez dos padrões.

Enquanto isso, eu (a) instalaria o CU # 3 e (b) chamaria o PSS. Diga a eles que você está buscando uma correção muito específica que já foi confirmada como um bug e lançada para outros usuários como um hotfix privado: "VSTS # 109112 - A queda adiada da tabela temporária não é dimensionada para determinadas cargas de trabalho". Você pode ter que pagar a taxa do processo inicialmente, mas, como é um erro, a cobrança deve ser reembolsada.

Você provavelmente precisa do sinalizador de rastreamento 1118

Veja os mitos de Paul Randal sobre o tempdb primeiro e também o artigo TF 1118

O TF é descrito aqui no KB 328551

Não tenho experiência direta disso, mas parece que eu li

Presumo que você já tenha dividido seus arquivos de dados TempDB para tentar aliviar a disputa (via pré-produção primeiro, obviamente). Se você for mais corajoso, considere o sinalizador de rastreamento ao qual Paul Randal se refere autoritariamente: http://www.sqlskills.com/BLOGS/PAUL/post/A-SQL-Server-DBA-myth-a-day-(1230) -tempdb-deve-sempre-ter-um-arquivo-de-dados-por-processador-core.aspx

Em termos do que está causando a dor, você precisa fazer algum trabalho de investigação:

• isso apenas começou a ocorrer? o que mudou?
• o servidor está sob pressão de memória, portanto, as classificações precisam ser feitas no TempDB?
• existem processos DBA como o CheckDB ou a re-indexação online em execução?
• são usados ​​níveis de isolamento mais exóticos ou agente de serviços? dê uma olhada no sys.databases

Há uma boa consulta na parte inferior deste documento do Microsoft TempDB para tentar descobrir o que está usando o tempdb: http://technet.microsoft.com/en-gb/library/cc966545.aspx

Se você ainda está procurando rastrear isso, recentemente tive um problema de desempenho igualmente estranho com quedas de tabela síncronas. Se você tiver um grande número de bancos de dados (> 100 ou mais) em uma instância sql executando o SQL 2005 e tiver muitas instruções de criação e remoção de tabela temporária, poderá obter quedas lentas da tabela temporária. A verificação da contagem de linhas retornada de sys.dm_db_index_usage_stats pode descartar isso imediatamente, como o culpado.

O artigo da KB descreve o problema. http://support.microsoft.com/kb/2003031

O desempenho da consulta diminui quando sys.dm_db_index_usage_stats possui um grande número de linhas

Considere o seguinte cenário:

No Microsoft SQL Server 2005, você freqüentemente executa operações DDL que envolvem a remoção e recreação de muitas tabelas (especialmente tabelas temporárias no banco de dados tempdb). Você tem um grande número de entradas (100.000 ou mais) na exibição de gerenciamento dinâmico (DMV) sys.dm_db_index_usage_stats.

Retirado da minha resposta aceita a esta pergunta. Também há mais alguns detalhes. Tabela de baixa temperatura cai no sql 2005