Tenho um processo ETL mensal que é muito complicado de explicar aqui, mas basicamente obtemos uma grande quantidade de dados do cliente, carregamos em massa em várias tabelas e, em seguida, executamos uma série de processos de criação.
O volume total de dados é grande, adicionamos 25-30 milhões de registros mensalmente à maior tabela, que tem cerca de 700 milhões de registros no total. Existem tabelas de suporte de registros de 2m-300m cada também. O total de dados para este conjunto é de cerca de 3,5 TB.
Este mês, alguns processos estão demorando exponencialmente mais do que o normal. Um exemplo é um proc que normalmente é concluído em 30 minutos, demorou cerca de 40 horas antes de eu matá-lo (ainda não havia sido concluído).
Nem todos os processos são afetados e alguns são executados ainda mais rápido do que o normal.
Obviamente, a causa raiz está além do escopo de algo que posso perguntar aqui, mas há algo que me incomoda:
Temos planos de consulta reais exibidos em milhões de % para operadores individuais.
Como uma varredura de índice clusterizado para 791,358,704%
, uma junção de mesclagem para 75,566,494%
, etc. Isso ocorre em vários planos de consulta e esses são planos retirados de sys.dm_exec_query_plan
.
Esses planos de consulta são indicativos de algum outro problema maior?
Tenho certeza de que o problema não está nas estatísticas desatualizadas - executamos verificações completas em todas as tabelas principais e reconstruí manualmente a maior tabela e o banco de dados com pré-dimensionamento para eliminar a fragmentação.
JNK,
Você quis dizer algo assim?
http://sankarreddy.com/wp-content/uploads/2011/03/CropperCapture2.jpg
Este é um plano de execução estimado gerado com base nas estatísticas das ferramentas do cliente e observe que NÃO é um problema de mecanismo. Se você deseja que o MSFT corrija esse problema, vote neste item de item de conexão.
https://connect.microsoft.com/SQLServer/feedback/details/436184/huge-operator-cost-in-estimated-execution-plan
Como você mencionou o SQL Server 2008, recomendo que você consulte as informações WAIT STATS quando o trabalho estiver sendo executado. Veja por que a execução NÃO está avançando e descubra o gargalo.
http://blogs.technet.com/b/sqlos/archive/2008/07/18/debugging-slow-response-times-in-sql-server-2008.aspx
Além disso, observe as informações de sys.virtualfilestats e veja se há atrasos de E/S significativos e também o uso de memória.
HTH