Recentemente, com alguma surpresa, descobri que em um dos departamentos de uma grande empresa onde trabalho, o uso do SQL profiler é proibido SQL profiler durante o horário comercial.
Não sei como eles conseguem analisar problemas de desempenho que ocorrem justamente durante o horário comercial. Afinal, as visualizações de desempenho muitas vezes não fornecem uma imagem precisa, especialmente se uma ou duas stored procedures/queries estão causando lentidão sem sobrecarregar o servidor. Um pequeno query, que é executado várias vezes por hora e leva 10 segundos em vez de um (mas fazendo algo muito importante para o cliente muito nervoso) certamente não aparecerá nas DMV views. E um select com CROSS APPLY nos textos das queries sobrecarrega o servidor consideravelmente.
No entanto, estou curioso para entender de onde vem esse medo. Em algumas empresas SQL profiler o SQL profiler é uma ferramenta de trabalho, enquanto em outras é temido como o fogo (em algum tempo, trabalhei como consultor e pude fazer comparações). Estou quase certo de que a situação era assim:
Houston, temos um problema. O banco está lento. Resolva isso.
Aqui tem tantos marcadores... O que eu preciso?
Ok, vou marcar tudo e depois decido.
O que fica na cabeça da alta administração? Alguém rodou SQL profiler e tudo parou. E depois eles contam isso uns aos outros durante uma partida de golfe.
A propósito, a tentativa de registrar tais ‘estamos registrando tudo’ traces não em arquivo, mas no banco no mesmo servidor – uma vez eu fui testemunha de um caso assim.
E como estão as coisas por aí? Por favor, participe da enquete
Apenas usuários registrados podem participar da pesquisa. , por favor.
É permitido rodar o SQL profiler em PROD?
Somos uma empresa pequena, tudo aqui é simples
Os administradores de produção podem, é claro
Os administradores de produção podem depois de aprovações e rezando
Santo, santo, santo
Quatro usuários votaram. Três se abstiveram.
Fonte: habr.com
