Informationen

  • Dieses Topic beschreibt die Vorgehensweise für das Update der PLANTA-Datenbank.
  • In diesem Topic werden nur Themen behandelt, die für das alleinige Datenbank-Update gelten.

Voraussetzungen und Empfehlungen

 Achtung

  • Das Update von PLANTA-Datenbank erfordert Fachkenntnisse aus dem Bereich PLANTA customizer, da einige Update-Schritte auf PLANTA customizer-Funktionen und -Module zurückgreifen. Idealerweise soll das Update von einem IT-Administrator (Parametrisierung im PLANTA -Installer) und einem Customizer (Prüfung der Update-Ergebnisse, Überprüfung der Migrationspakete, Konfliktmanagement etc.) durchgeführt werden. Die Beschreibung der customizing-spezifischen Themen, wie z.B. das Migrationsverfahren, Konfliktmanagement etc., sind in der PLANTA customizer-Dokumentation zu finden.
  • Bitte lesen Sie sich die Systemvoraussetzungen durch, bevor Sie mit dem Datenbank-Update beginnen.

Wir empfehlen 

  • vor einem Datenbank-Update
    • auf dem Quell-System den Konsistenzcheck (mindestens die Relationsprüfung) auszuführen, um die Gültigkeit der Daten zu überprüfen.
    • ein Backup des Quellsystems zu erstellen (Datenbank und Server).
  • das Datenbank-Update zuerst in einem Testsystem durchzuführen, bevor man das Produktivsystem updatet.
  • beim Update der Datenbank den Server ebenfalls auf den aktuellsten verfügbaren Stand mitabzudaten. Die Beschreibung von Server-Update finden Sie unter hier.
  • Bei Fragen zu Rahmenbedingungen eines Update-Verfahrens wenden Sie sich bitte an Ihren PLANTA-Kundenberater.

Vorgehensweise

Das Update wird inkl. des Migrationsverfahrens mit dem PLANTA-Installer durchgeführt.

Vorgehensweise

  • Schritt 1: Herunterladen des Datenbank-Ordners des gewünschten Releases vom PLANTA-Transfer-Server.
  • Schritt 2: Update der Datenbank mit Hilfe des PLANTA-Installers durchführen. Dabei werden die Schritte durchgeführt, die im Abschnitt Technischer Ablauf aufgeführt sind (je nach dem, wie der Stand des Quellsystems ist, sind hier die jeweiligen Kapitel zu beachten).
  • Schritt 3: Prüfen des Status der Migrationspakete, d.h. ob diese korrekt durchgelaufen sind, in den einzelnen Modulen des Panels Migrationspakete. Ist ein Paket nicht korrekt durchgelaufen, muss das Logfile des entsprechenden Migrationspakets geprüft und müssen ggf. entsprechende Maßnahmen ergriffen werden. Weitere Informationen finden Sie im Topic Übersicht über alle bisherigen Läufe
  • Schritt 4: Prüfen und ggf. Durchführen des Standard-ICOU
  • Schritt 5: Prüfen und Lösen der Konflikte, die durch das DB-Update entstehen, mit dem neuen Konfliktmanagement-Verfahren.
    • Konflikte sind hierbei Änderungen an Standardobjekten, bei denen geprüft werden muss, ob die individuellen Änderungen beibehalten oder durch den neuen PLANTA-Standard ersetzt werden sollen.

 Technischer Ablauf

Information

  • Nachfolgend wird der technische Ablauf für das Update der PLANTA-Datenbankbeschrieben. 

Technisch gesehen besteht das DB-Update aus den folgenden Schritten:

  1. Ausführen der offenen Migrationspakete im Ordner bzw. der Kategorie Customizing
    • Hierbei werden die Migrationspakete aus den verschiedenen Datenbank-Releases nacheinander ausgeführt. Diese Migrationspakete sind dazu da, das Schema an das jeweilige Datenbank-Release anzugleichen, z.B. neue Spalten in der Datenbank anzulegen. Die dazugehörigen System- sowie Modul-Customizings werden in Schritt 4 aktualisiert.
    • Für welche Datenbank-Releases ein Migrationspaket relevant ist, ist im Migrationspaket selbst definiert.
  2. Ausführen der Migrationspakete in Before DB Import, hierzu gehören u.a. die folgenden Migrationspakete, die bei jedem Datenbank-Update ausgeführt werden:
    • CorrectOwnerLicense: Setzt die Owner-Lizenz für alle Datensätze in der Q1B und Q2B mit leerer Owner-Lizenz. Ob der Datensatz die Standard- oder Kundenlizenz bekommt, wird in den meisten Datentabellen über die Autonummer entschieden. Für Datentabellen, in denen das nicht möglich ist (da die Lizenz nicht Bestandteil der Autonummer ist oder es keine Autonummer gibt), wurden eigene Regeln definiert.
    • DeleteStandardConstraintsQ1BandQ2B: Löscht alle Standard-Constraints in der Q1B und Q2B, außer Primary und Unique Constraints.
    • SetOwnerLicenseForZZZRecords: Ändert die Owner-Lizenz in den Datentabellen der Q1B und Q2B von ZZZ auf 011.
  3. DB-Import (=Ersetzen des Customizings in PLANTA project, siehe auch Datenbank-Export/Import). Hierbei werden
    • bestehende Constraints und Trigger deaktiviert,
    • die Daten mit PLANTA-Lizenz (000 und 011) in den Datentabellen der Q1/Q2 (und Teilen der Q3 (z.B. Modulvarianten), sowie den Prozessmodell-Tabellen in Q5) tabellenweise gelöscht
    • die Daten in den gleichen Datentabellen neu importiert.
    • die zuvor deaktivierten Constraints/Trigger wieder aktiviert.
  4. Ausführen der Migrationspakete in After DB Import, hierzu gehören u.a. die folgenden Migrationspakete, die bei jedem Datenbank-Update ausgeführt werden:
    • DeleteStandardConstraintsAfterDBImport: Löscht alle Constraints, die auf Standard-DIs gehen - in allen Schemas, inklusive Primary und Unique Costraints
    • DeleteStandardIndices: Löscht alle Indizes auf UUID-DIs sowie alte Indizes.
    • A_CreateConstraints: Legt alle Constraints aus der Schema-Generierung an. Hierbei werden die Constraints erst angelegt und erst in einem zweiten Schritt validiert. Probleme, die bei der Validierung, z.B. aufgrund von fehlerhaften Daten auftreten, werden ins Logfile geschrieben. Diese müssen manuell geprüft und korrigiert werden. Danach müssen die Constraints über das Migrationspakete EnableConstraints validiert werden.
    • AddSchemaExtensions: Fügt zusätzliches Indizes und Constraints hinzu, die sich nicht aus dem System-Customizing direkt ergeben.
    • UnloadAndReplan: Macht eine Neuplanung über alle aktiven Projekte.
    • Zusätzlich werden die folgenden Prüfungen des Konsistenzchecks durchgeführt (diese befinden sich im Modul Hilfspakete):
  5. Anpassen der eingespielten Daten
    • Hierbei werden v.a. die Lizenzen der neu eingespielten Daten an die Kundenlizenz angepasst.

Hinweis

  • Das Ersetzen des Customizings während des DB-Imports in Schritt 3 "DB-Import" ist analog zum Customizing-Deployment von Kundensystemen mit dem Unterschied, dass beim Customizing-Deployment alle Datensätze in der Q1B und Q2B gelöscht und neu eingespielt werden, beim DB-Import lediglich die mit den Standard-Owner-Lizenzen 011 und 000.
    • Die Voraussetzungen des Customizing-Deployments, wie der Programmstand und das gleiche Datenbankschema, werden beim Datenbank-Update vom Update-Verfahren (z.B. mithilfe der Migrationspakete) selbst hergestellt.