Datenbank-Update Neu ab DB 39.5.7

info Informationen
  • Dieses Topic beschreibt das PLANTA-Datenbank-Update von DB 39.4.4.0 auf DB 39.5.y sowie das Update von DB 39.5.x auf DB 39.5.y.
  • Das Update wird inkl. dem Migrationsverfahren mit dem PLANTA-Installer durchgeführt.
    • warning Voraussetzung für ein Update auf DB 39.5.7 ist S 39.5.19, daher wird während des Updates auf DB 39.5.7 automatisch ein Update auf S 39.5.19 durchgeführt.

note Details

  • Standard- und individuelle Customizing-Objekte werden anhand der Owner-Lizenz unterschieden:
    • Standard-Objekte haben Owner-Lizenz 011, 000 (oder ZZZ).
    • Individuelle Objekte haben als Owner-Lizenz die Kundenlizenz (diese kann in den Systeminformationen (STRG+B) eingesehen werden).

Voraussetzungen und Empfehlungen

warning Voraussetzungen

  • Alle Datentabellen mit Foreign-Key-Constraints auf PLANTA-Datentabellen müssen in PLANTA Project als Datentabellen vorhanden sein, da es sonst u.A. beim Datenbank-Update zu Problemen kommt.
  • Vor dem Datenbank-Update müssen alle Foreign-Key-Constraints auf PLANTA-Datentabellen manuell gelöscht und nach dem Update wieder angelegt werden.

warning Wir empfehlen vor einem Datenbank-Update

  • auf dem Quell-System den Konsistenzcheck (mindestens die Relationsprüfung) auszuführen.
  • ein Backup des Quellsystems zu erstellen (Datenbank und Server).

Vorgehensweise

Ab DB 39.5.14

more Vorgehensweise
  1. Herunterladen des Datenbank-Ordners vom PLANTA-Transfer-Server.
  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).
  3. 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. warning Darf erst ausgeführt werden, nachdem alle Daten, die in A_CreateConstraints gemeldet werden, korrigiert wurden.
  4. Prüfen und ggf. Durchführen des Standard-ICOU
  5. 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,
      1. NEU kann ein neues Konfliktmanagement-Verfahren angewandt werden, um Konflikte zu prüfen und zu lösen, die durch das DB-Update entstehen.
        • warning 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.
        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. Im selben Modul auf den den Button Anpassungen finden klicken. Dadurch werden die Konflikte initiiert.
        3. 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

more Vorgehensweise
  1. Herunterladen des Datenbank-Ordners vom PLANTA-Transfer-Server.
  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).
  3. 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. warning Darf erst ausgeführt werden, nachdem alle Daten, die in A_CreateConstraints gemeldet werden, korrigiert wurden.
  4. Prüfen und ggf. Durchführen des Standard-ICOU
  5. Prüfen und Durchführen des individuellen ICOU

Technischer Ablauf

DB-Update DB 39.5.x auf DB 39.5.y (im Installer: Update von Release 39.5.x (mit DB 39.5)

info Technisch gesehen besteht das DB-Update aus den folgenden Schritten:
  1. Update auf den aktuellsten Server, mind. S 39.5.19
  2. 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.
  3. 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.
  4. DB-Import (=Ersetzen des Customizings in PLANTA Project, siehe auch Datenbank-Export/Import). Hierbei werden
    1. bestehende Constraints und Trigger deaktiviert,
    2. 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
    3. die Daten in den gleichen Datentabellen neu importiert.
    4. die zuvor deaktivierten Constraints/Trigger wieder aktiviert.
  5. 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)
  6. Anpassen der eingespielten Daten
    • Hierbei werden v.a. die Lizenzen der neu eingespielten Daten an die Kundenlizenz angepasst.

warning Hinweise

  • Das Ersetzen des Customizings während des DB-Imports in Schritt 4 erfolgt analog zum Customizing-Deployment mit dem Unterschied, dass beim CU-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.
  • Da beim Datenbank-Imports in Schritt 4 über die Owner-Lizenz entschieden wird, welcher Customizing-Datensatz gelöscht und mit dem neuen Stand wieder eingespielt wird, sind Änderungen an Standard-Customizing, wie z.B. eine neue Datenfeld-Überschrift auf einem Standard-Datenfeld "verloren", individuelle Module jedoch nicht. Weitere Informationen zum update-sicheren Customizing finden Sie hier...

DB-Update DB 39.4.4.0/S 39.5.x auf DB 39.5.y (im Installer: Update von Release 39.5.x (mit DB 39.4))

info Dieses DB-Update besteht technisch gesehen aus den gleichen Schritten wie das DB-Update DB 39.5.x auf DB 39.5.y

DB-Update DB/S 39.4.4.0 auf DB 39.5.y

info Hierbei müssen zwei einzelne Updates durchgeführt werden


index Siehe auch: Installation/Update mit dem automatischen Installer, Migrationsverfahren, Update-sicheres Customizing





 
  • Suche in Topic-Namen

  • Suche in Topic-Inhalten