Tenho um script SQL que executo quando quero ver o que está acontecendo no banco de dados. O script tem muitas consultas que retornam informações dos DMVs, mas as duas que mais uso são "Requests" ( sys.dm_exec_requests , sys.dm_exec_sessions , etc.) e "Locks" ( sys.dm_tran_locks ). A saída é semelhante ao SQL Server Activity Monitor, mas exibe mais informações.
Às vezes, uma solicitação aparece na consulta Requests, mas é concluída antes da execução da consulta Locks. Por exemplo, a consulta Requests pode mostrar que o SPID 51 está aguardando um recurso de bloqueio, mas a consulta Locks não inclui nenhuma informação de bloqueio para SPID 51. (Eu sei sobre as colunas wait_typee de .)wait_resourcesys.dm_exec_requests
Existe uma maneira de garantir que essas duas consultas separadas exibam um instantâneo coerente da atividade do banco de dados?
Espero que os aplicativos comerciais de monitoramento de banco de dados encontrem o mesmo problema.
Eu experimentei executar essas consultas em simultaneidade SERIALIZABLE e adicionei dicas de bloqueio às junções DMV, mas as consultas não adquiriram bloqueios. Eu não gostaria de fazer isso na produção de qualquer maneira.
As melhores ideias que tenho até agora são:
Execute essas consultas simultaneamente em diferentes sessões.
Junte solicitações e bloqueios em uma consulta. Considerando que vi mais de 100.000 bloqueios de uma só vez, essa junção retornaria muitas solicitações duplicadas e dados de sessão, mas pode funcionar.
Não estou familiarizado o suficiente com eventos estendidos para saber se eles funcionariam melhor - emparelhamento de eventos, talvez?
Não é possivel. Esses DMVs não oferecem nem mesmo garantias de autoconsistência. Por exemplo, é possível que um recurso apareça em diferentes estados mutuamente exclusivos , na mesma execução, no mesmo conjunto de resultados. Se tais DMVs tomassem as medidas necessárias para 'estabilizar' os dados durante uma varredura, os resultados seriam desastrosos para o desempenho (imagine todos os bloqueios sendo congelados no lugar enquanto uma varredura
sys.dm_tran_locksestá em andamento).Eventos estendidos oferecem uma imagem muito melhor, mas obviamente é a imagem de eventos , não de estado. Em teoria, é sempre possível reconstruir o estado a partir da sequência de eventos conhecendo o estado inicial e obter a mesma imagem que você obtém do despejo de estado (os DMVs), mas isso é apenas teoria ...