Posso estar faltando algumas peças neste quebra-cabeça, mas é isso que eu tenho:
Tudo isso foi escrito para nós por uma empresa externa.
Existe uma aplicação .Net que funciona como um serviço no Servidor A.
Dentro desse aplicativo, os pacotes SSIS estão sendo chamados. DTEXEC
?
Esses pacotes (37 no total) alcançam dois SQL Servers (B&C) diferentes, extraem alguns dados, realizam cálculos neles e inserem os resultados em um banco de dados no Servidor C.
Dos 37 pacotes, apenas alguns deles são minha área problemática. Eu vi os detalhes, e há muitas, muitas tarefas neles.
Não há componentes do SQL Server (mecanismo de banco de dados ou SSIS) no Servidor A em que o aplicativo .Net reside, portanto, tudo isso ocorre internamente ao aplicativo. .Net está usando 1 nó NUMA de 20 núcleos, 1 TB de RAM na caixa.
Este aplicativo é a versão 3.0, com novas funcionalidades adicionadas. 2.4 (versão anterior) funciona bem em hardware idêntico.
Todo esse pano de fundo para perguntar isso:
Existe alguma maneira de encontrar T-SQL de baixo desempenho dentro dos pacotes SSIS que estão dentro do aplicativo .Net? Ou estou perdendo algo extremamente óbvio na equação?
O que se resume é: "onde estão os cálculos/T-SQL realmente em execução" (A vs B/C) e como faço para rastreá-los/ajustá-los se estiver dentro do espaço .Net?
Profiler, sp_whoisactive
etc. todos apontam para instâncias SQL. Tudo isso está acontecendo apenas dentro do aplicativo .Net, com pequenas exceções para selecionar dados de B e inserir em C após os cálculos. Toda a rede, disco, etc. está funcionando perfeitamente. Estou procurando uma ferramenta de ajuste que possa alcançar o .Net SSIS se tal coisa existir.
É definitivamente um problema de ajuste, mas Profiler, sp_whoisactive
etc. não mostram nada mais do que talvez 3 segundos, mais bem abaixo de 1/2 segundo ou menos. Eu não sei o suficiente sobre .Net para saber se essas tarefas T-SQL estão realmente sendo executadas no servidor A dentro desse espaço de memória como eu acho que são, ou se há tantas delas que estão agregando em "muito tempo ".
Eu gostaria de ter permissão para habilitar o log pesado no SSIS, mas isso faz parte do código do fornecedor que não tenho permissão para tocar, mesmo para log :(
O ambiente ao qual esta pergunta foi direcionada já foi demolido e redefinido várias vezes.
O problema apareceu novamente na iteração UAT atual... e descobrimos que alguém havia apontado parte do aplicativo para a versão de 32 bits do dtexec.exe em Arquivos de Programas (x86), em vez da versão correta de 64 bits.
opa. Muita pesquisa e esse post do DBA.SE me levou até lá.
Mensagens em meus logs que não tive na primeira vez:
Há também alguns contadores de perfmon específicos do SSIS que ajudaram:
Eu detalhei muitos dos meus passos aqui: http://dallasdbas.com/ssis-memory-errors/
Espero que isso ajude alguém no caminho!
Você já olhou para o refletor do RedGate ? Parece exatamente o que você está procurando.
Nota: não tenho afiliação com RedGate. Pesquisas na web resolvem problemas!