Regeln und Voraussetzungen für die automatische Datenmigration

Alle Regeln und Voraussetzungen, die für das Generieren von erneut partitionierten Ausgabedateien auf Zielknoten gelten, haben auch Gültigkeit für das Feature für automatische Datenmigration.

Die folgenden Regeln und Voraussetzungen gelten für das Feature für automatische Datenmigration:

Optim™ High Performance Unload muss sowohl auf dem Quell- als auch auf dem Zielsystem installiert sein.
Es ist obligatorisch, Berechtigungsnachweise des lokalen Typs relativ zur Zielumgebung für den Benutzer, der die Ladeoperation ausführt, auf der Db2® -Zielinstanz zu erstellen.
Für Migrationszwecke kann die Option INTO in der Klausel FORMAT nur auf der SELECT-Ebene verwendet werden. Die Verwendung einer globalen Option INTO bedeutet, dass die entladenen Daten für alle Auswahlanforderungen in dieselbe Tabelle erneut geladen werden, wodurch es auf der Zieldatenbank zu Problemen wegen gleichzeitiger Zugriffsversuche kommen könnte.
Wenn ein MIGRATE-Block angegeben wird, muss auch die Klausel TARGET ENVIRONMENT angegeben werden. Sie können diese Klausel entweder in einem GLOBAL-Block oder im MIGRATE-Block angeben. Die Klausel TARGET ENVIRONMENT muss zusammen mit der Option INSTANCE angegeben werden, da sie die einzige Option ist, über die Sie angeben können, dass die Zielumgebung nicht mit der Quellenumgebung identisch ist.
Wenn Sie Daten migrieren, Optim High Performance Unload verwendet temporäre Dateien, um die Ausgabe zu speichern. Diese Dateien werden vom Ziel-LOAD-Schritt gelesen, der von Optim High Performance Unload. Daher Optim High Performance Unload ignoriert die OUTFILE-Klausel, die in einem MIGRATE-Block angegeben ist.
Sie können eine Klausel FORMAT angeben, wenn Sie Daten migrieren, aber Sie können lediglich die Schlüsselwörter DEL, DELIMITED, IXF, ASC oder MIGRATION verwenden.
Das MIGRATION-Format kann nur innerhalb eines MIGRATE-Blocks angegeben werden.
Da das DEL-Format automatisch von Optim High Performance Unload für die automatische Datenmigration verwendet wird und die LOB- und XML-Daten nicht vollständig mit diesem Format kompatibel sein können, Optim High Performance Unload unterstützt die Migration von Tabellen mit LOB- oder XML-Spalten intern nicht auf dieselbe Weise wie alle anderen Datentypen. Beachten Sie die folgenden Unterschiede:
- Wenn Sie versuchen, eine Tabelle mit LOB- oder XML-Spalten zu migrieren, werden die Daten in temporäre Dateien entladen. Wenn der Entladeschritt beendet ist, startet der Ladeschritt mit diesen temporären Dateien.
- Wenn Sie versuchen, eine Tabelle zu migrieren, die keine LOB- oder XML-Spalten enthält, werden der Entladeschritt und der Ladeschritt parallel ausgeführt und die Daten werden in benannte Pipes entladen. Der Ladeschritt startet mit diesen benannten Pipes.
Wenn Sie mehrere Tabellen über denselben MIGRATE-Block migrieren, gibt es keine Garantie in Bezug auf die Reihenfolge, in der sie verarbeitet werden. Wenn wechselseitige Integritätsbedingungen vorliegen, müssen die Tabellen einzeln verarbeitet werden, um diesen Integritätsbedingungen Rechnung zu tragen.
Wenn Sie einen Tabellenbereich oder eine Datenbank vollständig migrieren, können Sie die Daten aus einer bestimmten Datenbank nicht in dieselbe Datenbank migrieren. Wenn Sie eine ZIELUMGEBUNGS-Klausel angeben, die genau dieselbe Zieldatenbank wie die Quelldatenbank definiert, Optim High Performance Unload wird ein Fehler zurückgegeben.
Wenn Sie eine bestimmte Tabelle migrieren, können Sie ihre Daten nicht in dieselbe Tabelle in derselben Datenbank migrieren. Wenn am Migrationsprozess dieser Tabelle dieselbe Datenbank sowohl auf der Quellenebene als auch auf der Zielebene beteiligt ist, muss sich die Zieltabelle von der Quellentabelle unterscheiden. Sie können über die Option INTO der Klausel FORMAT eine andere Tabelle angeben. Wenn die Ziel- und die Quelltabelle identisch sind, Optim High Performance Unload wird ein Fehler zurückgegeben.
Wenn eine automatische Migration für dieselbe Datenbank ausgehend von einer Tabelle, die für eine Gruppe von Tabellenbereichen definiert ist, in eine andere Tabelle ausgeführt wird, die für eine Gruppe von Tabellenbereichen definiert ist, die sich mit der Tabellenbereichsgruppe der ersten Tabelle überschneidet, kann die Migration nicht mit der Option FLUSH BUFFERPOOLS YES oder mit der Option LOCK YES gestartet werden.
Die Verwendung des ASC-Formats für eine Datenmigration ist möglicherweise der beste Ansatz, wenn die berücksichtigte Tabelle Spalten des Datentyps REAL oder DOUBLE enthält. Zur Vermeidung von Genauigkeitsverlust beim Migrieren dieser Spaltenwerte ist es obligatorisch, dass sie in den Datenströmen, die für die Migration verwendet werden, binär verarbeitet werden. Das IXF-Format hat eine binäre Darstellung für diese Datentypen. Es kann jedoch nicht für das Laden von Daten in eine DPF-Datenbank berücksichtigt werden. Daher ist für das Migrieren der Daten einer Tabelle mit REAL- oder DOUBLE-Spalten zu einer DPF-Datenbank die einzige ordnungsgemäße Vorgehensweise die Verwendung des ASC-Formats, wobei die binäre Darstellung für die numerischen Werte aktiviert ist. Es kann durch die Angabe des Modifikators BINARYNUMERICS in der Option MODIFIED BY der Klausel FORMAT ASC aktiviert werden. Wenn die Migration einer Tabelle mit REAL- oder DOUBLE-Spalten mit einem Format durchgeführt wird, das eine erweiterte Darstellung für ihre Werte aufweist, werden die Werte möglicherweise annähernd in die Zieltabelle geladen. Und selbst wenn die Migration einer Tabelle mit REAL- oder DOUBLE-Spalten in den Verteilungsschlüssel mit einem Format durchgeführt wird, das eine erweiterte Darstellung für ihre Werte aufweist, können Fehler aufgrund falsch erneut partitionierter Daten auftreten.