Início / dba / Perguntas / 77932
Accepted
SQLBen
Asked: 2014-09-30 03:57:34 +0800 CST

Carregamento do SSIS usando o comando SQL

  • 772

Estou tentando inserir a consulta abaixo usando o SSIS. Estou fazendo isso apenas porque existem alguns IDs sobrepostos que já são IDs existentes na tabela de destino. Tentei usar o seguinte para obter os IDs mínimo e máximo de ambas as tabelas para inserir apenas as linhas não existentes:

/*
--SourceTable
 MinID  MaxID
select 552596452-633166940

--destination table
MinID        MaxID
450485204  596693972
*/

Então agora usei isso para implementar a inserção usando o pacote SSIS. Não consegui executar este pacote. Existe alguma coisa que eu estou fazendo de errado? existe algum outro fluxo de dados SSIS que eu poderia usar para contornar isso? Escolhi usar o SSIS porque o registro é de cerca de 30 milhões de linhas, o que levará muito tempo para executar no SQL e também preencherá o logspace rapidamente, o que afetará o desempenho do servidor.

INSERT INTO dbo.destinationtable          
           ([id]      
           ,[userId]      
           ,[serviceId]      
           ,[keyId]      
           ,[wappush]      
           ,[builturl]      
           ,[datestamp]      
           ,[pocessingTime]      
           ,[UserAgent]      
           ,[Referer]      
           ,[fallBack]      
           ,[Error]
           ,[ClientIP]
           ,[AdvertUrl])  


SELECT  id, userId, serviceId, keyId, wappush, builturl, datestamp, pocessingTime, 
          UserAgent, Referer, fallBack, Error, ClientIP, AdvertUrl
FROM  sourcetable a (nolock)
WHERE (datestamp < DATEADD(d, 0, DATEDIFF(d, 0, GETDATE() - 60))) 
AND id > 596693972 and id <= 633166940
ORDER BY id
ssis

1 respostas

  1. Best Answer

    Se você for usar o SSIS, posso sugerir que você o use ? ;)

    O que acredito que você está tentando fazer é inserir alguns dados que ainda não existem no destino. Você identificou quais dados precisam ir usando sua lógica min/max e tentou fazer uma operação semelhante para o destino.

    Para começar, OLE DB Commandé algo que você deve usar com moderação. Ele executa operações singleton e, portanto, o volume de linhas que você deseja que essa coisa manipule deve estar na casa das dezenas, talvez centenas. Definitivamente não são 80 milhões.

    Seu fluxo de dados deve ser algo como isto

    insira a descrição da imagem aqui

    Tenho um OLE DB Source (pode ser usado ADO.NET mas se precisar parametrizar sua query é um pouco mais complexo). Você pode usar sua consulta existente ou se precisar dividi-la porque possui sistemas ativos, que assim seja.

    O Componente Lookup, LKP RM_DimEmplo...é a chave para esta operação. Quando o pacote for iniciado, ele executará a consulta de origem nesse componente e armazenará em cache todos os valores. Isso soa caro, então não deixe ser. Não basta selecionar dbo.destinationTable. Escreva sua consulta para trazer de volta apenas as chaves necessárias para fazer uma correspondência. Deve ser esses IDs. Isso será muito estreito e não deve ser tão ruim. A ideia aqui é que você terá suas linhas de origem e as comparará com o cache da tabela de destino com base nessas chaves. Como você não está preocupado em detectar diferenças, sabe que qualquer coisa que não corresponda precisa ser eliminada; portanto, na guia "Geral", altere "Especificar como lidar com linhas sem entradas correspondentes" para usarRedirect rows to no match output.Caso contrário, isso explodirá quando não for compatível.

    Se você achar que ainda é impactante em seus sistemas, precisará ir para uma abordagem mais avançada de usar expressões no componente de pesquisa para filtrar o intervalo de dados para corresponder aos IDs que chegam. Assim, você identificou que o intervalo de origem é 100 para 200. Não há necessidade de obter o intervalo completo de chaves de 0 a 1.000 no destino, você simplesmente faria a pesquisa armazenar em cache as chaves que estão no intervalo operacional. 80M não deve ser muito cansativo, a menos que você não tenha RAM sobrando na máquina.

    O OLE DB Commandfaz operações únicas e únicas. O OLE DB Destinationpode fazer inserções singleton (padrão para 2005 - Table or view) ou atualizações baseadas em conjunto/lote ( Table or View - fast load) que podem ser rápidos empinar chitas. Como você está carregando muitos dados, a menos que queira que seus administradores o odeiem, altere o tamanho máximo de confirmação de inserção para algo diferente do padrão de 2147483647. Isso basicamente diz para não confirmar nada até que tudo tenha sido inserido. Isso pode fazer com que seu log de transações fique grande rapidamente.

    A coisa boa sobre o seu problema é que você pode executá-lo para o conteúdo do seu coração. Digamos que 1 milhão de linhas sejam carregadas e algo ruim aconteça. Apenas reinicie. Por mais que tenha sido confirmado e quando for reiniciado, ele pode extrair os mesmos dados de origem, mas sua pesquisa terá o conjunto de chaves mais recente do destino, portanto, o resultado não será nenhuma operação executada para eles. Eu sei, você pensaria que todo mundo adora duplicatas em seu sistema de destino, mas, por algum motivo, isso simplesmente não funciona em alguns lugares ...

    Embrulhar

    Não posso recomendar a série Stairway to Integration Services o suficiente. Especificamente para este problema, Nível 3

    • 2

relate perguntas