Die Dokumentation ab Version 39.5.17 von PLANTA project finden Sie in der neuen PLANTA Online-Hilfe.
TWiki> Current Web>TechnischeDokumentation>InstallationUndUpdate>UpdatePLANTAProject>DatenbankUpdate

Datenbank-Update Neu ab DB 39.5.7

Informationen
  • Dieses Topic beschreibt das Update der PLANTA-Datenbank
    • von der Version 39.4.4.0 (Earth) auf eine 39.5er-Version (Venus) sowie
    • von einer 39.5er-Version (Venus) auf eine höhere 39.5er-Version (Venus)
  • In diesem Topic werden nur Themen behandelt, die für das alleinige Datenbank-Update gelten.
    • PLANTA empfiehlt beim Update der Datenbank den Server ebenfalls auf den aktuellsten verfügbaren Stand mitabzudaten. Die Beschreibung zum Update des Servers finden Sie je nach Ausgangsversion Ihres Systems unter UpdateServer394Auf395 oder UpdateServer395.
  • Einen gesamten Überblick über verschiedene Komponentekombinationen, je nach Stand Ihres Systems und je nach dem, auf welchen Stand Sie updaten möchten, bietet Ihnen die Beschreibung hier.

Voraussetzungen und Empfehlungen

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

Vorgehensweise

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

Ab DB 39.5.15

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: NEU 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 individuelle Änderung beibehalten oder durch den neuen PLANTA-Standard ersetzt werden soll.
    • Die Vorgehensweise beim Anwenden des Konfliktmanagement-Verfahrens variiert abhängig davon, von welcher Version Sie updaten. In der nachfolgenden Tabelle sind die beiden möglichen Optionen aufgeführt:
Update von DB < DB 39.5.14 auf DB 39.5.15 oder höher 1 Referenzsystem im Modul Referenz einspielen einspielen. (Über Referenzpfad zuerst das Schema und danach das Daten zip-File importieren. Anhand der Dateiendung (.sql oder .zip) wird entschieden, was für eine Datei es ist.)
2 Auf den Button Anpassungen finden klicken. Dadurch werden die Konflikte initiiert.
3 Im Modul Konflikte können nun die Lösungen für Konflikte in ihren jeweiligen Modulen konfiguriert und ausgeführt werden.
Update von DB 39.5.14 auf DB 39.5.15 oder höher Im Modul Konflikte können nun die Lösungen für Konflikte in ihren jeweiligen Modulen konfiguriert und ausgeführt werden.

Ab DB 39.5.14

Vorgehensweise
  • Herunterladen des Datenbank-Ordners vom PLANTA-Transfer-Server.
  • 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).
  • Prüfen der Migrationspakete
    • Schlagen Pakete fehl, müssen die Log-Dateien überprüft und ggfs. die Customizings korrigiert werden.
      • Z. B.: Schlägt das Migrationspaket A_CreateConstraints fehl, müssen die fehlerhaften Daten, die im Logfile des Migrationspaket ausgegeben werden, geprüft und entweder korrigiert oder gelöscht werden. Danach muss das Migrationspaket EnableConstraints ausgeführt werden, mit dem die zuvor noch nicht validierten Constraints validiert werden. Darf erst ausgeführt werden, nachdem alle Daten, die in A_CreateConstraints gemeldet werden, korrigiert wurden.
  • Prüfen und ggf. Durchführen des Standard-ICOU
  • Dieser Schritt hängt davon ab, von welchem Release aus Sie auf die DB 39.5.14 updaten.
    • Wenn Sie von einem Earth oder Venus on Earth-Release (DB 39.4.4.0) updaten,
    • Wenn Sie von einem Venus-Release (DB 39.5.x) updaten,
      • NEU kann ein neues Konfliktmanagement-Verfahren angewandt werden, um Konflikte zu prüfen und zu lösen, die durch das DB-Update entstehen.
        • Konflikte sind hierbei Änderungen an Standardobjekten, bei denen geprüft werden muss, ob die individuelle Änderung beibehalten oder durch den PLANTA-Standard ersetzt werden soll.
        • Referenzsystem im Modul Referenz einspielen einspielen
          • Über Referenzpfad zuerst das Schema und danach das Daten zip-File importieren. Anhand der Dateiendung (.sql oder .zip) wird entschieden, was für eine Datei es ist
        • Im selben Modul auf den den Button Anpassungen finden klicken. Dadurch werden die Konflikte initiiert.
        • Im Modul Konflikte können nun die Konflikte in ihren jeweiligen Modulen konfiguriert und ausgeführt werden. Weitere Informationen zum Konfliktmanagement während des DB-Updates

Bis DB 39.5.14

Vorgehensweise
  • Herunterladen des Datenbank-Ordners vom PLANTA-Transfer-Server.
  • 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).
  • Prüfen der Migrationspakete
    • Schlagen Pakete fehl, müssen die Log-Dateien überprüft und ggfs. die Customizings korrigiert werden.
      • Z. B.: Schlägt das Migrationspaket A_CreateConstraints fehl, müssen die fehlerhaften Daten, die im Logfile des Migrationspaket ausgegeben werden, geprüft und entweder korrigiert oder gelöscht werden. Danach muss das Migrationspaket EnableConstraints ausgeführt werden, mit dem die zuvor noch nicht validierten Constraints validiert werden. Darf erst ausgeführt werden, nachdem alle Daten, die in A_CreateConstraints gemeldet werden, korrigiert wurden.
  • Prüfen und ggf. Durchführen des Standard-ICOU
  • Prüfen und Durchführen des individuellen ICOU

Technischer Ablauf

DB-Update 39.5.x (Venus) auf DB 39.5.y (Venus)

Information
  • Nachfolgend wird der technische Ablauf für das Update der PLANTA-Datenbank, die bereits auf einer 39.5-Version (Venus) ist, auf eine höhere 39.5-Version (Venus) beschrieben.
  • Im PLANTA-Installer heißt diese Updateart beim Update per Konsole venus und beim Update per GUI Update von Release 39.5.x (mit DB 39.5).

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.

DB-Update DB 39.4.4.0 mit S 39.5.x (Venus on Earth) auf DB 39.5.x (Venus)

Information

DB-Update 39.4.4.0 mit S 39.4.4.0 (Earth) auf DB 39.5.x (Venus)

Information
  • Ist bei Ihnen die Datenbank 39.4.4.0 mit dem Server 39.4.4.0 im Einsatz (heißt: das komplette System ist auf dem Stand Earth), können Sie Ihre Datenbank nicht direkt auf eine 39.5.x-Version (Venus) updaten.
  • Es müssen zwei einzelne Updates durchgeführt werden.
    • 1. Zunächst muss der Server auf eine 39.5.x-Version upgedated werden, im PLANTA-Installer heißt diese Updateart beim Update per Konsole r94 und beim Update per GUI Update von Release 39.4.4.0 auf Release 39.5.x (mit DB 39.4).
      • Hierzu sehen Sie die Beschreibung im Topic Update Server 39.4 auf Server 39.5
      • Wir empfehlen, von diesem Zwischenstand des DB-Updates ein Backup zu erstellen.
      • Nach diesem Schritt ist Ihr System auf dem Stand DB 39.4.4.0 mit Server 39.5.x (Venus on Earth).
    • 2. Dann kann die Datenbank auf eine 39.5.x-Version upgedated werden. Im PLANTA-Installer heißt diese Updateart beim Update per Konsole voeToVenus und beim Update per GUI Migrieren von DB 39.4 zu DB 39.5 mit Release 39.5.x.

         PLANTA project







 
  • Suche in Topic-Namen

  • Suche in Topic-Inhalten
This site is powered by the TWiki collaboration platform Powered by Perl