Eu tenho um pacote SSIS - duas tarefas de fluxo de dados, oito componentes cada, lendo de dois arquivos simples, nada de espetacular. Se eu executar em APOSTAS, demora de forma confiável cerca de 60 segundos. Eu tenho um servidor de banco de dados de sandbox com o pacote em execução em um trabalho que também leva de forma confiável 30 a 60 segundos. No meu servidor de produção, o mesmo trabalho com o mesmo pacote leva de 30 segundos a12 horas.

Com a criação de log ativada no pacote, parece que isso atrasa - inicialmente pelo menos - na fase de pré-execução de uma ou outra (ou ambas) tarefas de fluxo de dados. Mas eu também posso ver os dados entrando - lentamente, em partes, então eu acho que ele se move a partir de lá mais tarde. O subsistema IO é sobrecarregado, e o SSIS gera muitos arquivos temporários grandes (cerca de 150MB de valor - meus arquivos de dados de entrada são apenas cerca de 24MB juntos) e está lendo e escrevendo vigorosamente a partir desses arquivos (thrashing?).

De nota, se eu apontar minha instância BIDS do pacote no servidor de produção, ainda levará apenas 60 segundos para ser executada! Portanto, deve ser algo com o dtexec em execução, não o próprio DB.

Eu já tentei otimizar meu pacote, reduzindo o tamanho do byte de linha de entrada, e fiz com que as duas tarefas de fluxo de dados fossem executadas em série e não em paralelo - sem sucesso.

Ambos os servidores de banco de dados estão executando o MSSQL 2008 R2 de 64 bits, mesmo nível de correção. Ambos os servidores são VMs no mesmo host, com a mesma alocação de recursos. A carga no servidor de produção não deve ser muito maior do que no servidor da sandbox agora. A única diferença que posso ver é que o servidor de produção está em execuçãojanelas Server 2008, enquanto o sandbox está no Windows Server 2008R2.

Socorro!!! Qualquer idéia para tentar é bem-vinda, o que poderia estar causando essa enorme discrepância?

Apêndice A

Aqui está o meu pacote parece ...

O fluxo de controle é extremamente simples:

O fluxo de dados é assim:

A segunda tarefa de fluxo de dados é exatamente a mesma, apenas com um arquivo de origem e uma tabela de destino diferentes.

Notas

A restrição de conclusão no Fluxo de Controle está lá apenas para fazer as tarefas serem executadas em série para tentar reduzir os recursos necessários ao mesmo tempo (não que isso tenha ajudado a resolver o problema) ... não há dependência real entre as duas tarefas.

Estou ciente de possíveis problemas com o bloqueio e o bloqueio parcial de transformações (não posso dizer que eu os compreenda completamente, mas pelo menos um pouco) e sei que a junção de agregação e mesclagem está bloqueando e pode causar problemas. No entanto, novamente, tudo isso corre bem e rapidamente em todos os outros ambientes, exceto o servidor de produção ... então, o que dá?

O motivo da junção de mesclagem é fazer com que a tarefa aguarde até que ambas as ramificações da multidifusão sejam concluídas. A ramificação direita localiza o datetime mínimo na entrada e exclui todos os registros na tabela após essa data, enquanto a ramificação esquerda transporta os novos registros de entrada para inserção - portanto, se a ramificação direita prosseguir antes da agregação e exclusão, os novos registros ser deletado (isso aconteceu). Não tenho conhecimento de uma maneira melhor de gerenciar isso.

A saída de erro de "Excluir registros" está sempre vazia - isso é deliberado, já que na verdade não quero nenhuma linha daquela ramificação na mesclagem (a mesclagem só existe para sincronizar a conclusão conforme explicado acima).

Veja o comentário abaixo sobre os ícones de aviso.