Usando o SQL Server Business Intelligence Development Studio, faço muitos fluxos de arquivos simples para os dados de destino do OLE DB para importar dados para minhas tabelas do SQL Server. Em "Modo de acesso a dados", no editor de destino OLE DB, o padrão é "tabela ou exibição" em vez de "tabela ou exibição - carregamento rápido". Qual é a diferença; a única diferença discernível que consigo perceber é que a carga rápida transfere os dados muito mais rapidamente.
Os modos de acesso a dados do componente de destino OLE DB são oferecidos em dois tipos - rápido e não rápido.
Rápido, "tabela ou exibição - carregamento rápido" ou "tabela ou nome da variável - carregamento rápido" significa que os dados serão carregados de maneira baseada em conjunto.
Lento - a variável "table or view" ou "table or view name" resultará no SSIS emitindo instruções de inserção singleton para o banco de dados. Se você estiver carregando 10, 100, talvez até 10000 linhas, provavelmente haverá pouca diferença significativa de desempenho entre os dois métodos. No entanto, em algum momento, você saturará sua instância do SQL Server com todas essas solicitações incómodas. Além disso, você abusará do seu log de transações.
Por que você iria querer os métodos não rápidos? Dados incorretos. Se eu enviasse 10000 linhas de dados e a 9999ª linha tivesse uma data de 29-02-2015, você teria 10k inserções atômicas e confirmações / reversões. Se eu estivesse usando o método Rápido, todo o lote de 10 mil linhas será salvo ou nenhum deles. E se você quiser saber quais linhas com erro, o nível mais baixo de granularidade que você terá é de 10 mil linhas.
Agora, existem abordagens para obter o máximo de dados carregados o mais rápido possível e ainda manipular dados sujos. É uma abordagem de falha em cascata e parece algo como
A idéia é que você encontre o tamanho certo para inserir o máximo possível de uma só vez, mas se você obtiver dados incorretos, tente salvar novamente os dados em lotes sucessivamente menores para obter as linhas incorretas. Aqui, comecei com um tamanho máximo de confirmação de inserção (FastLoadMaxInsertCommit) de 10000. Na disposição da linha de erros, altero para Redirect Rowde Fail Component.
O próximo destino é o mesmo que acima, mas aqui eu tento carregar rapidamente e salvá-lo em lotes de 100 linhas. Mais uma vez, teste ou faça algum pretexto de ter um tamanho razoável. Isso resultará em 100 lotes de 100 linhas enviadas porque sabemos que, em algum lugar , há pelo menos uma linha que violou as restrições de integridade da tabela.
Em seguida, adiciono um terceiro componente ao mix, dessa vez economizo em lotes de 1. Ou você pode simplesmente mudar o modo de acesso à tabela da versão do Fast Load, pois produzirá o mesmo resultado. Salvaremos cada linha individualmente e isso nos permitirá fazer "algo" com as únicas linhas ruins.
Finalmente, tenho um destino à prova de falhas. Talvez seja a tabela "mesma" que o destino pretendido, mas todas as colunas são declaradas como nvarchar(4000) NULL. Tudo o que acaba nessa mesa precisa ser pesquisado e limpo / descartado ou qualquer que seja o seu processo de resolução de dados incorreto. Outros despejam em um arquivo simples, mas, na verdade, o que faz sentido para como você deseja acompanhar dados ruins funciona.
O Fast Load está bem documentado nas opções FAST LOAD
Mantenha os valores de identidade do arquivo de dados importados ou use valores exclusivos atribuídos pelo SQL Server.
Mantenha um valor nulo durante a operação de carregamento em massa.
Verifique as restrições na tabela de destino ou visualize durante a operação de importação em massa.
Adquira um bloqueio no nível da tabela pela duração da operação de carregamento em massa. Especifique o número de linhas no lote e o tamanho da confirmação.
Qual é a diferença; a única diferença discernível que consigo perceber é que a carga rápida transfere os dados muito mais rapidamente.
Sob o capô, table or viewusará o comando SQL individual para cada linha para inserir vs table or view - with fast loadusará o comando BULK INSERT.
Se você vir as opções acima, disponíveis no BULK INSERT, por exemplo, number of rows in the batch= ROWS_PER_BATCHe commit size=BATCHSIZE
Outro cenário será ..
O tamanho máximo de confirmação de inserção padrão (2147483647) é muito alto. Portanto, por exemplo, você está inserindo 500 mil linhas e, devido à violação da PK, o lote falha. Nesse cenário, o lote inteiro falhará quando você usar a opção FAST LOAD. Você não poderá obter a descrição do erro também.
É aqui que você pode ter table or viewcomo destino a saída de erro. Portanto, em 500K, você usa o FAST LOAD como iniciando com um tamanho de confirmação de inserção de 5K. Se uma linha nesse lote falhar, você redirecionará o lote de 5K para table or viewcarregar - que usa somente linha por linha para inserir 5K linhas e também poderá redirecionar o erro de table or viewum arquivo simples. Assim, se alguma linha falhar no lote se 5K, você poderá identificar o que causou a falha.
A vantagem do método acima é que, se nenhuma das linhas falhar, ele usará BULK INSERT (carregamento rápido) para todo o lote.
O aficionado do SSIS billinkc respondeu a uma pergunta semelhante no Stackoverflow .