Ein Gastartikel von André Lechner.

Hin und wieder erhält man als Automic Administrator den freundlichen Hinweis Kosten einzusparen.

Über kurz oder lang, landet man beim Thema Lizenzkosten. In meinem Fall waren es die Lizenzkosten von Oracle Datenbanken. Ein schneller Blick auf der Automic Kompatibilitätsliste lässt Hoffnung aufkommen. PostgreSQL wird seit der AE Version 12.2.x unterstützt. Dabei handelt es sich um eine freie Datenbank mit praktisch keinen Lizenzkosten. Gerade für uns bei Best blu Consulting with Energy GmbH wo wir Open Source als Unternehmensprinzip verfolgen. Und mit PostgreSQL kenne ich mich auch schon ein wenig aus.

Wie bin ich also bei der Umstellung vorgegangen?

Viele Wege führen nach PostgreSQL

Ich mache mich also frisch ans Werk und treffe erste Überlegungen: Wie bekomme ich nun meine Daten aus der Oracle Datenbank nach PostgreSQL?

Es gibt drei Möglichkeiten:

  1. Automic DBUnload und DBLoad
  2. Automic DBClientCopy
  3. Datenbankseitige Tools: In der Postgres Community gibt es einige Tools die ganze Oracle Datenbank in Postgres migrieren. Im Internet stößt man recht häufig dabei auf ora2pg

Automic DBUnload und DBLoad zu benutzen, ist meiner Meinung nach der pragmatischste Lösungsansatz. Alle Objekte und Definitionen werden übernommen und die Downtime ist auch bei größeren Systemen vertretbar, wenn man auf die Statistiken und Reports verzichtet. Die ganze Migration könnte somit auch bei laufendem Systems durchgeführt werden. Der Verlust von Statistiken und Reports ist allerdings ein großes Manko.

Automic DBClientCopy sehe ich persönlich als besten Weg an. Man kann eine schleichende Migration durchführen und ist nicht unter Zwang alles in einem gewissen Zeitfenster zu schaffen. Statistiken und Reports bleiben erhalten und das Vorgehen ist wie bei einem normalen DB Client Copy. Man kann also auf die eigenen Erfahrungen zurückgreifen und ungefähr einschätzen, wie lange etwas dauert. Dem gegenüber steht der Aufwand, ein paralleles Automic System aufzubauen.

Datenbankseitige Tools wie ora2pg sind sicher auch eine gute Lösung. Allerdings kann ich dazu nicht viel schreiben, weil ich es noch nicht geschafft habe, mir diesen Weg genau anzuschauen.

Die Ausgangslage unseres Systems

Damit ihr mein Vorgehen besser einordnen und mit eurer Situation vergleichen könnt, habe ich hier mal die Ausgangslage auf unserem System zusammengefasst.

  • Linux Server in der Cloud mit 4 CPU und 16GB RAM, sowie 150 GB HDD
  • Linux CentOS Version 7
  • AE Server in der Version 12.2.1
  • Oracle Datenbank 12 ohne ILM und knappe 20 GB Inhalt
  • Mandanten: 20 Stück
  • Objektanzahl pro Mandanten: ca. 5000 Stück

Mit diesen Voraussetzungen habe ich mich entschieden, DBUnload und DBLoad zu benutzen. Bei der recht geringen Datenbankgröße von nur etwa 20GB ist meines Erachtens das schnellste Vorgehen. Außerdem waren auch die Statistiken an dieser Stelle nicht relevant für mich.

Für die ganze Aktion hatte ich 4 Stunden eingeplant und war am Ende auch in diesen fertig geworden. Wenn man mal etwas Erfahrung mit den Tools gesammelt hat, geht es aber bestimmt auch schneller.

Vorbereitung der Migration

Ich erwähne es sicherheitshalber einmal hier an dieser Stelle, wie bei einem Automic Update/Upgrade ist es immer vom Vorteil das Process Monitoring relativ leer zu haben. Auch ein Durchlauf von Archiv/Reorg/Unload Automic Utility davor schadet nicht.

Die folgenden Schritte habe ich zur Vorbereitung der Migration durchgeführt:

  1. Postgres Server, Client und Contrib Version 10 herunterladen
  2. Grafische Oberfläche installieren (ich habe pgadmin4 benutzt)
  3. Passenden JDBC Treiber für die AE herunterladen und ins korrekte Verzeichnis kopieren
  4. Initialdatenbank vom Postgres einrichten
  5. AE Server in der postgresql.conf auf md5 freigeben
  6. Einrichten des Postgres10 Services und Starten des Postgres
  7. Wechseln auf den Postgres System-User postgres
  8. Einrichten nach Automic Dokumentation: Recommendations for PostgreSQL
    ACHTUNG Keine Initialdaten Laden!
  9. In der AE die nötigen SQL Varas schon auf Postgres anpassen
  10. AE Server Ini Datei duplizieren und SQLConnection auf Postgres Datenbank anpassen
  11. Reorg und Archiv mit Automic Utilitys über die AE Datenbank Oracle laufen lassen.

Es geht ans Eingemachte: Daten migriert

Nachdem die Vorbereitung abgeschlossen war, habe ich mit der eigentlichen Datenmigration begonnen.

Als erstes habe ich natürlich per ServiceManagerDialog die AE heruntergefahren. Danach konnte ich DBUnload starten und dort „Export all Data“ auswählen.

Das Ergebnis ist ein uc_data.txt die nur die reinen Daten der Oracle Datenbank enthält. Bei mir waren es 1,5 GB reine Daten.

ACHTUNG, an dieser Stelle ist ein großer Stolperstein versteckt. Bei einer großen Datenbank würde der Schritt so in der Art, zum Abbruch des DBUnload führen, weil der RAM einfach vollläuft. Um den Schritt zu schaffen, darf man die entsprechenden Tabellen A*, R*, E* und MELD nicht mitentladen. Außerdem sollte das Logging deaktiviert werden.

Für die eigentliche Migration habe ich dann die folgenden zwei Schritte ausgeführt:

  • Zuerst habe ich die Statements aus uc_dll.sql ausgeführt, ich habe dies mit pgadmin4 direkt auf die Datenbank abgesetzt. Dabei dürfen auf keinen Fall Initialdaten geladen sein, ansonsten ist das Datenchaos vorprogrammiert. Überprüfe also am besten nochmal, ob wirklich nur Schemas und Stored Procedure geladen worden sind.
  • Danach habe ich die entladenen Daten mit DBLoad in die Postgres Datenbank geladen.

Damit ist die Migration auch schon abgeschlossen. Ich habe also ganz schnell den AE-Server heruntergefahren und folgendermaßen auf die Postgres Datenbank umgeleitet:

  • Die ucserv.ini gesichert und anschließend die ucserv_postgres.ini umbenannt auf ucserv.ini.
  • Per ServiceManagerDialog die einzelnen WPs und CPs gestartet, mit dem Modus Kalt-Start.

Ende der Migration: alles gut?

Ich bin ehrlich, ich kann die obige Frage gar nicht beantworten. Meiner persönlichen Meinung nach, ich es toll, Lizenzkosten zu sparen. Allerdings wagt man sich damit auch auf einen neuen Weg der Datenbanken, der sicherlich auch seine Tücken bereit hält.

Auf einer produktiven Umgebung, hätte ich nach obiger Vorgehensweise Statistiksätze und Reports verloren. Da muss jeder für sich entscheiden, ob es den Wechsel wert ist.

Ich hoffe der kleine Artikel hat dir gezeigt, dass es möglich ist zu PostgreSQL zu wechseln, und dir ein paar Anhaltspunkte gegeben, wie du dabei vorgehen kannst. Mit etwas mehr Zeit und (Budget) kann man relativ schnell die Datenmigration vollbringen.

Habt Spaß beim Ausprobieren

André Lechner

 

André Lechner

Business Process Automation / Administration – Consultant

Ich bin 41 Jahre jung und bei der Best-blu consulting with energy GmbH als Senior Consultant für Business Process Automation und Administration tätig. Ich habe mich in einem beschaulichen Dorf in Niedersachsen niedergelassen und mich für den altmodischen Weg als Arbeitsvorbereiter EDV entschieden. Ich betreibe Process Automation auf verschiedensten Betriebssystemen, angefangen bei BS2000 Mainframe und z/OS bis hin zu SAP. Weil das alleine nicht reicht, hatte ich irgendwann einmal die Idee nebenbei noch den Weg des Automic Administrators einzuschlagen. Seitdem darf ich mich zusätzlich mit Updates und Upgrades beschäftigen und gehe diesem Hobby nun schon seit über 10 Jahren nach.

Xing

Website

E-Mail