Eu tenho um fluxo de dados para migrar dados de um banco de dados antigo para um novo. O design antigo tinha todos os dados e informações históricas (alterações) armazenados em uma única tabela com uma "versão" (inteiro incrementado) na linha.
O novo design tem duas tabelas, uma para o estado "atual" dos dados e uma tabela de auditoria (ou histórico) que registra as alterações usando um gatilho. Portanto, existe apenas uma linha para os dados "atuais" e há muitas linhas de histórico.
Em meu pacote SSIS, estou usando os seguintes componentes para copiar os dados atuais para uma tabela, mas enviar todos os dados para a tabela de auditoria.
O Multicast é usado para dividir o fluxo de dados e a Divisão Condicional identifica a linha "atual" e a envia para a tabela Order (a tabela não é realmente chamada Order , antes que alguém comente sobre o uso de uma palavra reservada para um nome de tabela).
Criei este fluxo porque não consegui ver uma maneira de usar o Conditional Split para enviar todos os dados para o destino Audit e apenas a linha atual para o outro.
Presumo que criar todos os dados duplicados e, em seguida, descartá-los em um destino de lixo não seja muito eficiente e, como tenho cerca de 52 milhões de linhas para migrar, estou preocupado que a transformação demore dias.
Existe uma maneira melhor (mais eficiente) de obter a divisão de dados?
Nota sobre os dados: apliquei um row_number()aos dados que me permitem identificar a linha "atual" como número 1, todas as linhas, incluindo "atual", precisam ir para o destino da tabela de auditoria.
EDIT: Encontrei uma alternativa para a divisão multicast e condicional sugerida por esta postagem no blog do SSIS Junkie: várias saídas de uma transformação de script síncrona
Ele usa um componente de script para enviar dados para uma ou mais saídas. Estou tentando esse método para ver se é mais rápido, mas depois de ver a resposta e a sugestão de Kenneth sobre a remoção do destino da lixeira, não tenho certeza se será.
Não vejo nenhum problema gritante com esse fluxo de dados. Sempre sugiro trabalhar o máximo possível em suas consultas de origem, portanto, se você puder criar um conjunto de dados desde o início que permita preencher as duas tabelas por meio de uma divisão simples, certamente usará menos memória. Mas coisas assim nem sempre são possíveis, dependendo da fonte e do formato dos dados.
Além disso, o destino do lixo é bom para desenvolvimento/depuração, mas não é bom na produção. Remova. Deixe os 'Dados indesejados' expirarem na divisão. O SSIS pode descobrir o resto.
Desde que você evite componentes de bloqueio (UNION, MERGE, etc.), não há razão para que esse processo demore dias. Eu frequentemente processo muitos milhões de linhas no SSIS sem problemas. O SSIS é tão lento quanto a pessoa que projetou o processo.
Atualmente está tendo problemas de desempenho?