Transferindo grande quantidade (84 milhões de linhas) de dados com eficiência

Eu tenho cerca de 84 milhões de linhas. Desses, todos eles precisam ser transferidos para um banco de dados separado no mesmo servidor, e excluo para excluir cerca de 60 milhões de linhas do banco de dados de origem.

Os 84 milhões de linhas estão todos na mesma tabela. Somente essa tabela responde por 90% de todo o banco de dados.

Então ... Fonte: 84 milhões de linhas -> 24 milhões de linhas Destino: 0 linhas -> 84 milhões de linhas

A fonte está executando o modo de recuperação completa, o destino estará executando de forma simples.

Gostaria de saber qual seria a maneira mais eficiente de fazer isso?

Plano A:

1) INSERIR NO destino SELECIONE * DA fonte

2) TRUNCATE fonte

3) INSERT NA fonte SELECT * FROM destino ONDE keep_condition = 1

Plano B:

1) Restaure um backup do banco de dados de origem como o banco de dados de destino

2) Solte todas as tabelas, exceto a necessária no banco de dados de destino

3) Fonte TRUNCATE

4) INSERIR NA ORIGEM SELECIONE * DO destino ONDE keep_condition = 1

Plano C:

1) INSERIR NO destino SELECIONE * DA fonte

2) DELETE source WHERE keep_condition = 0

ou alguma outra coisa?

obrigado

Eu acrescentaria que, por mais que você decida abordar isso, precisará lote essas transações . Ultimamente, tive muita sorte com o artigo vinculado e aprecio a maneira como ele tira proveito dos índices, em oposição à maioria das soluções em lote que vejo.

Mesmo minimamente registrados, essas são grandes transações , e você pode gastar muito tempo lidando com as ramificações do crescimento anormal de logs (VLFs, truncamento, dimensionamento correto etc.).

obrigado

"Eficiente" pode ser aplicado ao uso do arquivo de log, desempenho de E / S, tempo da CPU ou tempo de execução.

Eu tentaria obter uma operação minimamente registrada, o que seria bastante eficiente do ponto de vista do log. Isso deve economizar um tempo de execução. Se você tiver o espaço tempdb, o seguinte pode funcionar para você.

CREATE TABLE #temp;
ALTER source -> BULK_LOGGED recovery model

BEGIN TRANSACTION;

    INSERT INTO dest SELECT FROM source;
    INSERT INTO #temp SELECT FROM source WHERE keep_condition=1;
    TRUNCATE TABLE source;
    INSERT INTO source SELECT FROM #temp;

COMMIT TRANSACTION;

ALTER source -> FULL recovery model
DROP TABLE #temp;

Para que uma operação minimamente registrada ocorra, várias condições precisam ser verdadeiras, incluindo nenhum backup em execução no momento, banco de dados definido para o BULK_LOGGEDmodo de recuperação e, dependendo dos seus índices, a tabela de destino pode estar vazia. Alguns desses comportamentos também foram alterados (aprimorados) do SQL Server 2005 para 2008.

Por outro lado, sem conhecer as especificidades da sua tabela e dados, qualquer uma das suas outras opções pode ter um desempenho melhor. Tente usar

SET STATISTICS IO ON;
SET STATISTICS TIME ON;

.. e veja qual funciona melhor.

EDIT : Ao executar operações de log em massa, faça um backup (log completo ou de transações) antes e depois da operação, se você precisar de um recurso de restauração pontual e suspeitar que outras atividades possam estar acontecendo no banco de dados em ao mesmo tempo em que seu trabalho ETL está em execução.

Escrevi um post sobre operações minimamente registradas há um tempo atrás, há links para outros posts e documentação.

Por que não o BCP?

1. Fazer backup do sourcedb
2. Alterar sourcedb para logon em massa

3. Abrir prompt de comando

4. bcp server.sourcedb.table out Filename.flt -T -c

5. bcp "SELECT * FROM sourcedb.table WHERE keep_condition = 1" queryout Filename2.flt -T -c

6. bcp Server.destinationdb.table in Filename.flt -T -c -b1000

7. verifique os dados

8. No SSMS, truncar a tabela de origem
9. bcp server.sourcedb.table in Filename2.flt -T -c -b1000
10. Alterar o sourcedb de volta para completo

Não pense que você deveria recomendar a alteração do modelo de recuperação sem um backup completo do banco de dados ou um backup t-log antes e depois . Um dos recursos do modelo de recuperação BULK_LOGGED é que você perderá a capacidade de fazer a recuperação pontual para logs t que contêm operações com registro em massa. Cenário clássico: backup completo noturno, backups diários de t-log. Você altera o modelo de recuperação para logon em massa e inicia sua operação. Algo dá errado e a transação é revertida (ou você não usou uma). No entanto, você não tem certeza do que mais estava acontecendo no banco de dados, portanto, você deseja restaurar para um bom ponto conhecido.

Quando você pode restaurar de volta para? Último backup t-log de hora em hora que não contém operações de log em massa, potencialmente perdendo n minutos de transações. Um backup completo ou backup t-log antes de alterar o modelo de recuperação criará um ponto de fallback. Qual você escolhe depende do seu RTO.

Descartar partições de uma tabela é uma maneira muito rápida e eficiente em termos de recursos de remover grandes pedaços de dados de uma tabela. Se essa tabela fosse particionada de uma maneira que suporte sua divisão de origem / destino, a resposta seria restaurar uma cópia, descartar as tabelas redundantes e as partições redundantes do destino e soltar as partições complementares da origem.

No entanto, o custo de ativar o particionamento pode tornar essa operação mais cara em geral.