Bewegung großer Datenmengen

Ich möchte Milliarden von Zeilen von schema1.table1 nach new schema2.table2 verschieben, wobei table2 eine überarbeitete von table1 ist. Daher ist ihre Tabellenstruktur unterschiedlich. Sowohl Tabelle1 als auch Tabelle2 sind partitioniert, aber Tabelle2 ist leer. Beide Schemas befinden sich in derselben Oracle-Datenbank. Was ist eine leistungsfähige Methode zur Durchführung dieser Datenmigration? Möchten Sie das Festschreiben nur ganz am Ende durchführen oder sich für ein inkrementelles Festschreiben entscheiden? Angenommen, die Datenmigration schlägt fehl, nachdem 99% des Auftrags abgeschlossen wurden, der einige Stunden gedauert hat. Rollbackst du jetzt? Wie gehen Sie mit dem Fehler um, wenn Sie das inkrementelle Commit ausführen?

Parallel INSERT APPENDmit NOLOGGINGwäre die Art und Weise , dies zu tun, dann wie bei allen NOLOGGING Operationen, nehmen Sie eine Sicherung unmittelbar auf den Abschluss. Markieren Sie Indizes zuerst als unbrauchbar, deaktivieren Sie Einschränkungen, ändern Sie die Tabelle, führen Sie die Operation aus und aktivieren Sie dann Einschränkungen erneut usw.

Durch das Anhängen erhält Oracle immer freien Speicherplatz über der aktuellen Hochwassermarke, sodass der Speicherplatz im Segment nicht effizient wiederverwendet werden kann. Es wird jedoch vermieden, mit der Freelist und dem UNDO-Overhead herumzuspielen. Wenn Sie aus irgendeinem Grund erneut beginnen müssen TRUNCATE, tun Sie dies nicht DELETE.

Was das inkrementelle Festschreiben betrifft, hängt es davon ab, wie Ihre Daten segmentiert sind. Können Sie leicht sagen, dass Sie jeweils einen Monat verschieben (z. B. ist das Partitionierungsschema in Quelle und Ziel gleich)? Denken Sie daran, dass Sie offensichtlich langsamer werden, wenn Sie ein Prädikat erfüllen müssen. Testen Sie, ob der Vorgang nicht logisch fehlschlägt (z. B. inkompatible Datentypen in Quelle und Ziel), weisen Sie dann ausreichende Ressourcen zu und führen Sie ihn einfach in einer Transaktion aus. Viel Glück!

Wenn das Partitionsschema das gleiche ist (Daten von Partition a in Tabelle 1 gehen zu Partition a in Tabelle 2 usw.), würde ich mehrere Sitzungen durchführen und jede Sitzung ihre Daten in ihrer "eigenen" Partition anhängen lassen. Dies verhindert viel Verriegeln und hat die beste Geschwindigkeit. Je nach Hardware können Sie die HBA-Karten bis zum Hals füllen. Ein Commit für jede Partition - vorausgesetzt, mehr als ein paar Zeilen für jede Partition - ist kein Problem, und ich würde dies auf jeden Fall tun. Angenommen, die Anwendung ist während der Migration nicht verfügbar, ist der Fallback einfach: Ändern Sie die App nicht und kürzen Sie die Partitionen von Tabelle2, bevor Sie es erneut versuchen, zumindest für die Teile, in denen die App die Daten geändert hat, bevor ein zweiter Lauf stattfinden kann.

ich hoffe das hilft