Datenübernahme DB2 Host auf DB2 Iseries

[TARASIK]

Hallo Forum,
wir planen ein Hostsystem durch eine ISeries zu ersetzen und es sind ein paar Diskussionspunkte aufgekommen.
1.) wie kann man diese DB2 Host Dateien am einfachsten auf die DB2 der ISeries bringen. Es sind insgesamt etwa 2 Terrabyte Daten
2.) wie lange wird so ein Job laufen, wenn die grösste Datei etwa 65 Millionen Datensätze beinhaltet ?
Vielen Dank für die Beteiligung an der Diskussion.

[Fuerchau]

Fast jede DB2 kann über DB2-Connect (DRDA) externe Tabellen einbinden.
Dann können die Daten per SQL transportiert werden.

Geschwindigkeit ?

Das hängt dann wohl mehr vom Netz als von den Platten ab.

Mal mit kleinen Mengen testen.

[UFK]

Fast jede DB2 kann über DB2-Connect (DRDA) externe Tabellen einbinden.
Dann können die Daten per SQL transportiert werden.

Geschwindigkeit ?

Das hängt dann wohl mehr vom Netz als von den Platten ab.

Mal mit kleinen Mengen testen.

Ich habe schon sehr oft Daten mit DRDA übertragen, und schätze daß es im Maximum auch schon mal über Hundert Gigabytes waren.

Im Terrabyte-Bereich würde ich aber FTP empfehlen. Das dauert auch lange genug, geht aber drastisch schneller als DRDA.

Man kann ja mal überschlagen, wie lange das mit FTP läuft, wenn man z.B. allgemeinen Ethernet und einen Switch mit brutto 100 MBit nutzen kann. Ich schätze mal, daß man im normalen Betrieb ca. 100 GB pro Tag schafft, und am Wochenende, bzw. wenn man eine exklusive 100 MBit-Leitung für die Übertragung nutzen kann, ca. 500 bis (etwas unrealistisch) 1000 GB/Tag.

Wenn ein Skript dafür erwünscht wird, das alles auf einmal erledigt, bitte ich kurzfristig um Kontaktaufnahme.

[Fuerchau]

Der Nachteil bei FTP besteht darin, dass man die Daten 3 mal verarbeitet:
1. Export in z.B. CSV
2. FTP
3. Import aus CSV
Da ist ggf. das direkte Schreiben per DRDA in Summe schneller.
Ausserdem sind dann Checkpoints, Wiederanlauf usw. einfacher.

Zusätzlich kommen mitunter die Größenbeschränkungen von PC/IFS-Dateien auf 2GB.

[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.