Datenübernahme DB2 Host auf DB2 Iseries

[UFK]

Ich bin natürlich davon ausgegangen, daß das Hostsystem ebenfalls FTP kann, und daß es möglich ist, zwischen den beiden Systemen (Host und i-Series) nicht nur eine DRDA-Verbindung sondern auch eine direkte FTP-Verbindung aufzubauen.

Mit ein paar FTP-Befehlen kann man FTP-Server und -Client dann so auf einander abstimmen, daß die Daten direkt von der einen Datei in die andere Datei fließen können, ohne Konvertierung ins CSV-Format, und ganz ohne PC-Dateien.

Ich hatte im Gegenteil bei DRDA immer den Eindruck, daß auf dem Zielsystem erstmal eine temporäre (versteckte) Datei eingelegt und gefüllt wird, und daß erst nach Abschluß eines Selects von dieser in die Zieldatei rüber kopiert wird. Diese interne Kopie (Platte>Platte) geht natürlich wesentlich schneller. Im sich öfters wiederholenden Prozeß kann das Erstellen, Kopieren, und Löschen von Dateien aber schon zu Buche schlagen, d.h. wenn man an hunderte oder tausende von Dateien denkt, ist es schon lohnenswert, sich den optimalen Ablauf zurecht zu legen und aus zu probieren.

[Fuerchau]

Die "temporäre Kopie" hängt stark von der Implemetierung der DB ab.
Bei sog. Client-Cursorn wird natürlich das Recordset komplett in den Hauptspeicher gezogen.
Bei Server-Cursorn verbleiben die Daten auf dem Server so dass ggf. direkt aus den Tabellen gelesen wird.
Allerdings hängt dies von der Art des Selects ab.

FTP kann aber einfach nur Dateien kopieren, ich kenne zumindest kein FTP-Programm, dass direkt per SQL auf eine DB zugreift.
Hier muss natürliche eine Umweg geschaffen werden.

Beim Insert über DRDA auf die AS/400 wird nichts in einem temporären Bereich zwischengespeichert.
Einzig auf Journale ist zu achten wenn die datei aufgezeichnet wird. Dadurch kommt es natürlich zur Verdopplung des benötigten Platzes.
Auch die Commitgrenze (Anzahl offener Sätze je Transaktion) ist zu beachten.

[UFK]

Wir reden hier doch aber von so großen Datenbanken (Terrabytes), daß die größeren Dateien mit z.B. 65 Millionen Datensätzen sowieso nicht in den RAM passen würden.

Bei der normalen SQL-Einstellung legt die SQL-Engine dann ggf. ganz von alleine temporäre Dateien an, um die Zugriffe und den ganzen Prozeß zu optimieren.

Die Journalisierung würde ich bei diesem Massen-Kopieren sowieso erst dann einschalten, wenn die Kopie fertig ist. Wenn die Quell-Datenbank laufend weiter geändert wird, würde ich einen ganz anderen Ansatz wählen (Remote-Journal, oder Data-Mirror)

FTP kann aber einfach nur Dateien kopieren, ich kenne zumindest kein FTP-Programm, dass direkt per SQL auf eine DB zugreift. Hier muss natürliche eine Umweg geschaffen werden.

Da hast Du mich mißverstanden, denn das habe ich nicht behauptet. Ich meinte nur, wenn beide Maschinen SQL (DRDA) miteinander reden, dann können sie wohl auch in FTP miteinander reden, denn ein FTP-Server setzt viel weniger voraus als ein SQL-Server. FTP und SQL haben sonst aber nichts miteinander zu tun, meine ich.