grand mouvement de données

Je voudrais déplacer des milliards de lignes de schema1.table1 à nouveau schema2.table2 où table2 est une refactorisée de table1. Par conséquent, leur structure de table est différente. table1 et table2 sont partitionnées mais la table2 est vide. Ces deux schémas se trouvent dans la même base de données Oracle. Quelle est la manière la plus efficace d'effectuer cette migration de données? Souhaitez-vous effectuer la validation uniquement à la toute fin ou opter pour une validation incrémentielle? c'est-à-dire que la migration des données échoue après avoir terminé 99% du travail, ce qui a pris quelques heures. Revenez-vous maintenant? Si vous effectuez la validation incrémentielle, comment gérez-vous l'échec?

Parallèlement INSERT APPENDà NOLOGGINGserait le moyen de le faire, puis comme pour toutes les opérations de NOLOGGING, effectuez une sauvegarde immédiatement après avoir terminé. Marquez les index inutilisables en premier, désactivez les contraintes, modifiez la table, effectuez l'opération, puis réactivez les contraintes, etc.

Append oblige Oracle à toujours récupérer de l'espace libre au-dessus de la ligne des hautes eaux actuelle, il n'est donc pas efficace de réutiliser l'espace dans le segment, mais il évite de jouer avec la liste libre et les frais généraux UNDO. Si vous devez recommencer pour une raison quelconque TRUNCATE, ne le faites pas DELETE.

Quant à la validation incrémentielle, elle dépendra de la façon dont vos données sont segmentées, pouvez-vous facilement dire déplacer la valeur d'un mois à la fois (par exemple, le schéma de partitionnement est-il le même en source et en cible)? Parce que rappelez-vous que si vous devez satisfaire un prédicat, cela vous ralentira évidemment. Testez pour vous assurer que l'opération ne va pas échouer logiquement (par exemple, des types de données incompatibles dans la source et la cible) puis allouez des ressources suffisantes et allez-y simplement en une seule transaction. Bonne chance!

si le schéma de partition est le même (les données de la partition a dans le tableau 1 vont à la partition a dans le tableau 2, etc.), je choisirais plusieurs sessions et chaque session ajouterait ses données dans sa «propre» partition. Cela empêche beaucoup de verrouillage et a la meilleure vitesse. Selon le matériel, vous pouvez remplir les cartes HBA jusqu'au cou. Un commit pour chaque partition - en supposant plus de quelques lignes pour chaque partition - ne sera pas un problème et je le ferais certainement. En supposant que l'application est arrêtée pendant la migration, la solution de rechange est simple: ne modifiez pas l'application et tronquez les partitions de table2 avant de réessayer, au moins pour les parties où l'application a modifié les données avant qu'une deuxième exécution puisse avoir lieu.

J'espère que ça aide