Início / dba / Perguntas / 226843
Accepted
LCJ
Asked: 2019-01-11 14:02:02 +0800 CST

recurso de espera sp_WhoIsActive

  • 772

Eu tenho uma consulta enorme no SQL Server 2016 – quando executo a consulta para um subconjunto de registros, ela é concluída em 15 minutos. Quando eu extrapolo para o número total de registros, ele deve ser concluído em 1 hora. Mas não está completo mesmo após 3 horas. Quando verifiquei master.sys.sysprocesses, há uma espera CXPACKET com 10293331 waittime

SELECT waittime, waittype, lastwaittype,  open_tran, cpu, physical_io, [sid], loginame, [sql_handle]      
FROM master.sys.sysprocesses WHERE SPID=58

Nota: eu fiz exec sp_Who2para obter o SPID = 58 específico

insira a descrição da imagem aqui

De Como usar sp_WhoIsActive para encontrar consultas lentas do SQL Server

@get_task_info = 2 – se uma consulta for paralela e você estiver solucionando problemas de esperas do CXPACKET, você poderá descobrir o que cada tarefa na consulta está aguardando.

Executei sp_WhoIsActive com @get_task_info = 2.

O wait_infodá o seguinte:

(5x: 68/168850/635541ms)CXPACKET:15, (3x: 3/16/32ms)CXPACKET:7, (1x: 10207374ms)CXPACKET:1

Como determinar o que cada tarefa está esperando a partir dessas informações?

ATUALIZAR

Esta questão é mais sobre encontrar uma "maneira" de descobrir os recursos em espera (usando sp_WhoIsActive ou similar) do que realmente corrigir esse problema de desempenho atual adicionando MAXDOP ou analisando o plano de execução.

sql-server performance

1 respostas

  1. Best Answer

    Esta pergunta é mais sobre encontrar uma "maneira" de descobrir os recursos em espera (usando sp_WhoIsActive ou similar) do que realmente corrigir esse problema de desempenho atual

    Se você está procurando o que esses números significam, confira a documentação sp_whoisactive .

    Na página de Adam Machanic no identificador de nó CXPACKET , você pode ver que esta linha em sua saída:

    (5x: ​​68/168850/635541ms)CXPACKET:15
    (3x: 3/16/32ms)CXPACKET:7
    (1x: 10207374ms)CXPACKET:1

    Significa que existem

    • 5 tarefas aguardando no CXPACKET no nó 15 do plano de execução
    • 3 tarefas aguardando no CXPACKET no nó 7 do plano de execução
    • 5 tarefas esperando no CXPACKET no nó 1 do plano de execução

    Os 3 números separados por barras estão documentados aqui :

    (Nx: MINms/AVGms/MAXms)[wait_type] onde Nx é o número de tarefas, MINms é a menor duração de espera das tarefas, AVGms é a duração média de espera das tarefas e MAXms é a maior duração de espera das tarefas

    A saída de @get_task_info = 2está dizendo a você

    • onde exatamente no plano de execução sua consulta está travando
    • quantas tarefas estão ficando presas lá, e
    • quanto tempo eles estão presos lá (min, max e em média)

    Espero que isso forneça informações suficientes para que você possa descobrir qual parte da sua consulta está travando nessas esperas de paralelismo para que você possa investigar mais.

    • 4

relate perguntas