Eu criei uma sessão de eventos estendida que observa o tipo de evento module_start e filtra com base no object_name: equal_i_sql_unicode_string]([object_name])
O objetivo desta sessão é simplesmente registrar informações básicas sempre que um proc na lista de filtros for chamado para que eu possa responder às perguntas dos desenvolvedores com 99,9% de garantia se um proc ainda é chamado em produção. A ideia é executar isso por ~ 1 mês 24 horas por dia, 7 dias por semana (sim, não leva em conta as coisas que são executadas anualmente, mas é o que é).
O problema que estou enfrentando é que a lista de procs que o desenvolvedor me deu tem cerca de 90 ou mais e a lista de filtros de uma sessão EE é limitada a 3.000 caracteres. A única ideia que tive para aumentar a taxa na qual podemos rastrear os procs é ter 2 sessões de EE separadas que são idênticas, exceto que os predicados de filtro são diferentes.
Não estou perguntando "qual será o impacto da CPU", mas mais ou menos é a preocupação deles em executar 2 das mesmas sessões de EE com diferentes predicados de filtro? É estranho para mim que a Microsoft limite a lista de filtros a 3.000 caracteres quando 'mais filtragem == melhor desempenho' porque a maneira como o EE é incorporado ao mecanismo é muito otimizado, ao contrário de um rastreamento que age mais como um proxy do que um "gatilho baseado em um evento".
É seguro assumir que, seja qual for o impacto no desempenho de executar 1 sessão, posso multiplicá-lo por 2 ou não estou considerando outras preocupações?
Não sou especialista em Eventos Estendidos de forma alguma, mas sei que há potencial para implicações de desempenho se não for feito com cuidado. Você só poderá realmente descobrir testando e monitorando ao longo do dia se houver algum impacto significativo na carga de trabalho do seu servidor/banco de dados atual. Eu acho que filtrá-lo para entidades específicas que não estão necessariamente sendo usadas pode ser bom.
Uma ideia alternativa é modificar cada procedimento armazenado de forma que ele insira em uma tabela o nome do procedimento e a data e hora atual.
Para algumas outras soluções alternativas, você pode ver as respostas desta postagem do StackOverflow . Eu teria cuidado ao usar
sys.dm_exec_procedure_statsse você seguir esse caminho, pois não é 100% garantido para fornecer os resultados que você está procurando, se um evento tiver limpado o cache do plano.