Qual a frequência de hash / classificação derramada no tempdb?

Nosso aplicativo corporativo usa o SQL Server para armazenamento de dados e é principalmente um sistema OLTP. No entanto, um componente importante de nosso aplicativo gera uma carga de trabalho OLAP significativa.

Nossa latência de gravação no tempdb é de cerca de 100 ms. Essa tendência se mantém ao longo do tempo e ALLOW_SNAPSHOT_ISOLATIONestá desativada . Estamos solucionando esse problema relativo e a única coisa interessante que encontramos até agora é que há um número significativo de derramamentos de hash e de classificação no tempdb. Supomos que isso seja proveniente de nossa carga de trabalho OLAP.

Questão

Que frequência de derramamentos é preocupante? Qualquer? Quantos derramamentos / s? Nossos dados preliminares indicam que temos cerca de 2 derramamentos de hash por segundo e 25 derramamentos de classificação por minuto.

É possível que essa frequência de derramamentos seja o principal culpado de nossa latência de gravação de alta tempdb?

Outra informação

Estamos usando vários arquivos para tempdb, conforme recomendado por número de núcleos. Os arquivos tempdb estão em uma SAN RAID 1 + 0 (com SSDs de alto desempenho), mas esse é o mesmo dispositivo que os principais arquivos de dados e log do banco de dados. Os arquivos tempdb têm tamanho grande o suficiente para crescer com pouca frequência. Não estamos usando sinalizadores de rastreamento 1117 ou 1118. Outra variável é que essa configuração é compartilhada para vários bancos de dados diferentes, todos com carga média a alta.

Nossa latência de gravação de 100 ms é muito maior do que os intervalos aceitáveis ​​para a latência de gravação tempdb encontrados no MSDN, no SQL Skills e em outros sites. No entanto, a latência de gravação para nossos outros bancos de dados é boa (abaixo de 10 ms). Com base em outras estatísticas, parece que estamos usando o tempdb intensamente, principalmente para objetos internos. Então, estamos tentando descobrir por que nosso aplicativo está usando objetos internos com tanta intensidade.

Temos realmente problemas de desempenho em nossa plataforma que se manifestam de várias maneiras. Monitoramos os contadores de desempenho, analisamos as visualizações de DM e analisamos o comportamento de nosso aplicativo para tentar descobrir as características de uso de recursos de nosso sistema. No momento, estamos focados em derramamentos, pois lemos que os derramamentos têm um impacto negativo drástico, porque são executados no disco e não na memória. E parece que temos um número muito alto de derramamentos, mas eu queria ter uma opinião sobre o que as pessoas consideram "alto".

É possível que essa frequência de derramamentos seja o principal culpado de nossa latência de gravação de alta tempdb?

Sim, é possível , embora normalmente seja o tamanho médio dos derramamentos e a profundidade deles (por exemplo, derramamentos de hash recursivos, classificações de várias passagens) que importa mais do que a frequência em si.

O SQL Server fornece uma ampla variedade de informações de métricas e DMV para ajudá-lo a solucionar os vários fatores que contribuem para a pressão do tempdb, muitos dos quais são discutidos no artigo técnico da Microsoft, "Trabalhando com tempdb no SQL Server 2005" (aplica-se a todas as versões 2005 em diante) )

Você deve poder usar as consultas de orientação e diagnóstico contidas nesse documento para começar a identificar as principais causas de qualquer pressão tempdb. Não desconsidere, por exemplo, a atividade de armazenamento de versão simplesmente porque ALLOW_SNAPSHOT_ISOLATIONnão está ativada. Muitos recursos usam o armazenamento de versão (por exemplo, gatilhos, MARS, RCSI) além do isolamento da captura instantânea.

Se os derramamentos de classificação e hash forem significativos em um nível alto, você provavelmente precisará configurar algum monitoramento específico para isso. Dependendo um pouco da sua versão do SQL Server, isso nem sempre é simples como se poderia esperar. Para conectar derramamentos de classificação e hash com a consulta específica que os causou, são necessárias Notificações de Eventos ou Eventos Estendidos. O artigo SolidQ, " Identificando e resolvendo avisos de classificação " contém detalhes e alguns bons conselhos gerais sobre como resolver causas comuns.

Você também deve trabalhar com sua equipe de armazenamento para determinar quanto da alta latência é atribuível à sua carga de trabalho, quanto vem de outros usos compartilhados e quais opções existem para a reconfiguração. Sua análise das métricas do SQL Server ajudará a informar essa discussão, assim como quaisquer métricas que o pessoal da SAN possa fornecer.