Empirius Tech Blog


Segen und Fluch der DB2 Datenbank / heterogene Migrationen

In diesem Artikel schreibe ich über einige der Super-Features der IBM DB Version 10.5, vor allem im Zusammenhang mit heterogenen Migrationen (heterogene Systemcopy), aber auch über die ein oder anderen "Unschärfen", die mir in diesem Zusammenhang untergekommen sind.


Überblick

Für einen Kunden führen wir "gerade" eine heterogene Migration von AIX/Oracle auf Linux/DB2 durch. "Gerade" heißt in diesem Zusammenhang in einem Migrationsprojekt, das seit Oktober '13 und noch bis Ende diesen Jahres läuft. Insgesamt sind ca. 60 Systeme heterogen umzustellen und ein paar weitere Systeme entstehen danach per homogener Systemkopie.

 

Die allermeisten Systeme sind kaum der Rede Wert, weil (fast) alles ohne Probleme ablief. Allerdings sind unter den "Kandidaten" auch ein paar Problemkinder zu finden: So gibt es eine Systemlandschaft, in der das Produktivsystem und die Integrationssysteme jenseits der 20 TB (also Terabyte!) groß sind. Die größte Einzel-Tabelle ist dort 1,2 TB groß, wobei in dieser Größenordnung einige Kandidaten existieren. Auch das laufende Wachstum von ca. 0,5 TB pro Monat trägt nicht zur Entspannung bei ...

 

Die Migrations-Tests für die produktive Umstellung dieses Giganto-Systems Ende Oktober laufen ca. seit Anfang Februar. Seitdem wurden einige Dinge auf Herz und Nieren durchgetestet. Eine Problematik stellt auf die Tatsache dar, dass bei dieser Größe ALLES "ein bisschen" länger dauert: Anfangs lief alleine der R3szchk mehr als 2 Tage, ein kompletter Durchlauf - alle Abbrüche mal rausgerechnet - dauerte initial auch 2 Wochen ...

 

Array Insert vs. LoadAPI

Eigentlich kann eine DB2 Tabellen gar nicht parallel beladen.

 

Wenn überhaupt, gelingt das nur mit einem SQL Array insert, aber:

  • SQL Array insert ist langsam (langsamer, als die LOAD API)
  • Benötigt viel und bei großen Tabellen extrem viel Platz im log_dir
    Die Größe und Anzahl der Logs ist begrenzt: Ein Log kann max. 4 GB groß sein, 254 Logfiles lassen sich max. konfigurieren. Das ergibt einen max. Bereich von 1 TB log_dir. Der wird bei dieser DB Größe sehr schnell knapp!
  • Die sogenannte Lock Escalation ist bei großen Tabellen irgendwann unvermeidlich, so dass die DB2 irgendwann entscheidet, dass ein kompletter Table-Lock sinnvoller ist.
    Das heißt de facto: Auch beim Array Insert kann man nicht parallel beladen.

 

Also bleibt eigentlich nur die LoadAPI, aber:

  • Die LoadAPI kann per se keine parallelen Beladungen in ein und dieselbe Tabelle.
  • So hilfreich das Tabellensplitting beim Export auch ist:
    Man kann die Export-Zeit fast linear über die Anzahl der parallelen Jobs verkürzen.
    ABER: Beim Import hilft einem das nichts, weil man jedes Teilpaket einer Tabelle nur sequentiell laden kann.

 

Aussichtslos? Nein, ganz und gar nicht!

Mit einem 7.20er-R3load hat SAP ein absolut geniales Feature in sein Tool eingebaut!

 

 

Splitted Load? Auch für DB2!

Dieses Feature baut für jedes Teilpaket zuerst eine temporäre Tabelle. Wenn alle Teilpakete schnell und parallel per LoadAPI geladen sind, kopiert der R3load ("merged") die Teil-Pakete in die endgültige Tabelle um. Dies erfolgt quasi mit einem

create table <FinalerTabellenname> as select * from <temp-tab1> union join select * from <temp-tab2> ...

Der absolute Clou dabei ist aber:

Selbst der letzte "Merge" passiert mit der rasend schnellen LoadAPI!

Dieses Feature erfordert vom "User" aka Migrateur kein aufwendiges oder fehleranfälliges Handling. Wirklich alles wird vom R3load im Hintergrund passend "konzertiert"!

Ein weiterer, immenser Vorteil:

Bei Abbrüchen kann jede temporäre Teiltabelle sehr schnell per truncate bereinigt werden! Teil-Pakete, die schon vollständig in temporären Tabellen importiert sind, bleiben bei Fehlern in anderen Teilpaketen erhalten.

Alles gut? Naja, nicht so ganz ...

 

Problemfelder der (Splitted) LoadAPI

Das erste Problem ging los, weil wir Anfang des Jahres mit der Version 10.1 (FP2) anfingen. Das Ende Dezember freigegebene FP3 nahmen wir im März freudig mit, zumal dort das ACS Scripting Interface endlich enthalten ist (nicht erst mit 10.5, wie bei IBM oft zu lesen). Es gibt dieses Interface sogar für DB2 V9.7 FP9! Aber ACSSC ist hier nicht unser Thema ...

 

Erste Tests verliefen im März vielversprechend, jedoch gab es immer wieder unerklärliche "Unable to start child process"-Situationen beim Beladen. Glücklicherweise konnte IBM das Problem relativ schnell eingrenzen und uns einen Special Build zur Verfügung stellen. Damit gingen unsere Tests weiter, wir fassten immer mehr Vertrauen in das WESENTLICH schnellere Verfahren des (Splitted) LoadAPIs, so dass wir nach und nach dazu übergingen, ALLE Tabellem "damit zu behandeln", sogar auch die nicht gesplitteten. Dabei fällt die DB2 einfach auf die normale LoadAPI zurück, das Temp-Tabellen-Handling fällt einfach automatisch weg.

 

Zur Erinnerung:
Der große Vorteil der LoadAPI besteht darin, dass keine Logging-Infos ins log_dir geschrieben werden müssen. Man spart sich also den bei Migrationen so kostbaren I/O.

 

Da wir also mehr und mehr Tabellen (fast alle) per LoadAPI importierten, brauchten wir "natürlich" auch immer mehr Speicher für die LoadAPI, sprich: UTIL_HEAP_SIZE.  

 

Nur leider kann man in DB2 V10.1 diese util_heap_size nur auf max. 2 GB konfigurieren, was bei unseren Tabellengrößen von ca. 1 TB nicht viel ist ... Zumal, wenn man eben nicht nur eine Tabelle importieren muss, sondern eben viele.

 

Also waren wir gezwungen, auf die V10.5 zu gehen, zumal IBM sie uns wärmstens ans Herz legte. Allerdings sagte IBM auch gleich, dass der "Unable to start child process" Bug auch in der V10.5 mit aktuellem FP noch nicht behoben sei. Eine anderer Optimierungsfix für die LoadAPI, den wir für V10.1 bereits hatten, wurde uns ebenfalls noch bereit gestellt. So testeten wir also Ende Juli '14 mit DB2 10.5 FP3 + 2 Special Build Fixes.

 

Die Grundlagen: Tools zur Überwachung und Auswertung

Während der Tests ist es unerlässlich, dass man die richtigen Tools an der Hand hat, damit man die teils kniffeligen Situationen analysieren und die richtigen Schlüsse ziehen kann!

  • R3load-Tools/MigMon/MigTime
    Das sind die Basics, aber so richtig Realtime-Analysen kriegt man damit nicht hin. Zwischen zwei Testläufen ist die MigTime-Auswertung natürlich unerlässlich
  • nmon: Nigel's Monitor
    Ein IBM Enthusiast hat dieses Freeware-Tool geschrieben, das nicht nur auf AIX zur Verfügung steht. Auf AIX kann es zwar noch ein bisschen mehr, als auf anderen Plattformen. Trotzdem auch auf Linux und Co. unerlässlich

    Dazu gehört v.a. ein mächtiges Excel-Makro, dem man die Rohdaten zum Fraß vorwirft und das daraus schicke, aussagekräftige Diagramme schnitzt!
  • Eingebaute DB2 Tools, insb. db2top und für die LoadAPI db2 load query table
  • migstat
    Dieses Tool ist eine Eigenentwicklung von uns, welches momentan v.a. den Migrationsstatus schnell visualisieren kann, z.B.:
     - Gesamtübersicht, welche Prozesse laufen oder abgebrochen sind
     - Selektion nach verschiedenen Kriterien
     - Direkte Detailinfos über alle Pakete nach deren letzter Aktivität, z.B. Lade-Fortschritt, Index-Aufbau oder letzter Fehler
     - Umfangreiche Plausichecks im Nachgang an eine Migration

Falls Sie Details zum Umgang mit den Tools wissen wollen, bitte in den Kommentaren vermerken. Ggf. schreibe ich einen separaten Artikel z.B. zum Umgang mit nmon oder db2top oder auch unserem migstat

 

(to be continued ...)

 


Tech Blog <- Zurück


Kommentare (0)


Kommentar hinzufügen:





Erlaubte Tags: <b><i><br>Kommentar hinzufügen: