grande movimentação de dados

Gostaria de mover bilhões de linhas do schema1.table1 para o novo schema2.table2, em que a tabela2 é um refatorado da tabela1. Portanto, a estrutura da tabela é diferente. a tabela1 e a tabela2 são particionadas, mas a tabela2 está vazia. Ambos os esquemas estão no mesmo banco de dados Oracle. Qual é a maneira eficiente de executar essa migração de dados? Deseja executar o commit apenas no final ou optar pelo commit incremental? ou seja, digamos que a migração de dados falhe após a conclusão de 99% do trabalho, que levou algumas horas. Você reverte agora? Se você faz a confirmação incremental, como você lida com a falha?

Paralelo INSERT APPENDcom NOLOGGINGseria a maneira de fazer isso, então, como com todas as operações nologging, fazer um backup imediatamente em completar. Marque os índices inutilizáveis ​​primeiro, desabilite as restrições, altere a tabela, execute a operação e reative as restrições etc.

Anexar faz com que o Oracle sempre ocupe espaço livre acima da marca d'água atual, portanto, não é eficiente para reutilizar o espaço no segmento, mas evita mexer com o freelist e o UNDO. Se você tiver que começar de novo por qualquer motivo, TRUNCATEnão faça DELETE.

Quanto à confirmação incremental, isso dependerá de como seus dados são segmentados. Você pode dizer facilmente mover um mês de cada vez (por exemplo, o esquema de particionamento é o mesmo na origem e no destino)? Porque lembre-se de que, se você precisar satisfazer algum predicado, isso obviamente o atrasará. Teste para garantir que a operação não falhe logicamente (por exemplo, tipos de dados incompatíveis na origem e destino), aloque recursos suficientes e apenas faça isso em uma transação. Boa sorte!

se o esquema de partição for o mesmo (os dados da partição a na tabela 1 vão para a partição a na tabela 2 etc.), eu usaria várias sessões e cada uma delas acrescentaria seus dados em sua própria partição. Isso evita muito bloqueio e tem a melhor velocidade. Dependendo do hardware, você pode preencher os cartões HBA até o pescoço. Um commit para cada partição - assumindo mais do que algumas linhas para cada partição - não será um problema e eu certamente o faria. Supondo que o aplicativo esteja inativo durante a migração, o fallback é simples: não altere o aplicativo e trunque as partições da tabela2 antes de tentar novamente, pelo menos nas partes em que o aplicativo alterou os dados antes que uma segunda execução pudesse ocorrer.

Eu espero que isso ajude