Unter Migration versteht man bei PLANTA Anpassungen an der Datenbank, die für das Aktualisieren des Systems auf eine höhere Version erforderlich sind. Das Migrationsverfahren basiert auf in Python geschriebenen Migrationspaketen und ist in PLANTA integriert.
Migrationspakete führen Änderungen an der vorhandenen PLANTA-Installation, vor allem der Datenbank, durch.
Um die Migration zu starten, muss der Server im Migrationsmodus (siehe den Abschnitt weiter unten) gestartet werden.
Der Server startet eine neue interne Session mit dem PLANTA-Benutzer MIGRATION. Daher haben alle neuen Datensätze bzw. Änderungen, die im Migrationsmodus an Customizing etc. durchgeführt/angelegt werden, den Änderungs-/Anlagebenutzer MIGRATION. Sie auch den Eintrag unter Achtung weiter unten.
Beim Starten der Migration werden alle Pflichtpakete automatisch ausgeführt. Alle weiteren Pakete müssen manuell ausgeführt werden. Hierzu siehe Hinweise im Abschnitt Migrationsmodus.
Um die Performance zu verbessern, wird für MSSQL-Systeme empfohlen, vor der Migration zu dem Recovery-Modell RECOVERY SIMPLE zu wechseln: ALTER DATABASE <PLANTA_DB_USER> SET RECOVERY SIMPLE Nach erfolgter Migration sollte das Recovery-Modell wieder auf das ursprünglich eingestellte Modell zurückgesetzt werden. Dies ist das Standard-Modell der Datenbank.
Welche Migrationspakete mit dem gewünschten Server- oder Datenbank-Release ausgeliefert werden, wird in Release Notes angegeben.
Wenn es Probleme gibt in der Art, dass vorhandene Python-Module nicht geladen werden können (z.B. im Migrationsskript 'FillMigrationRuleTable'), kann dies durch manuelles Ausführen des Pakets CreateFolderPacket im Modul Release-übergreifende Pakete behoben werden.
Es dürfen keine Leerzeichen in diesem Pfad enthalten sein!
Um die Migration zu starten, muss das Script planta_migration im Server-Verzeichnis der erstellten Parameterdatei ausgeführt werden: planta_migration -c "Name des Parameter-Files"
Daher haben alle neuen Datensätze bzw. Änderungen, die im Migrationsmodus an Customizing etc. durchgeführt/angelegt werden, den Änderungs-/Anlagebenutzer Migration.
Die für die Migration erforderlichen Parameter werden in einer Parameterdatei angegeben.
Aufbau der Parameterdatei:
CODE
--migration-components
Server
Customizing-Hotfix
Customizing
Customer
Before DB Import
After DB Import
--abort-on-failure
--packets-to-exclude
--delete-demo-data
--change-license
Sektion
Erklärung
migration-components
Hier werden die Komponenten angegeben, die migriert werden sollen. Die "klassische" Migration mit Migrationspaketen startet nur wenn der Parameter migration-compnents gesetzt ist.
abort-on-failure
Ist diese Option vorhanden, wird die Migration abgebrochen, sobald ein Migrationspaket fehlschlägt.
packets-to-exclude
Hier kann pro Zeile der absolute pythonpfad zu einem Migrationspaket hinterlegt werden, welches bei der Migration nicht ausgeführt werden soll. Z.B.: migration.server.S_39_5_21.WI19001_add_uuid_columns_to_kdb.AddUUIDColumnsToKDB
delete-demo-data
Wird dieser Parameter in die Datei aufgenommen, werden die Demodaten aus dem System entfernt.
Achtung: Bei der "Demodaten-Bereinigung" wird kein Filter auf die Owner-Lizenz oder Ähnliches gesetzt, sondern es werden einfach alle Tabellen mit Projekt/Benutzer/etc. Daten geleert (nur Benutzer P20 und MIGRATION verbleiben). Die Funktion muss am Anfang nach Aufsetzen eines Systems ausgeführt werden und kann nicht benutzt werden, um in einem System, welches bereits produktiv benutzt wurde, die Demodaten zu bereinigen!
change-license
Wenn angegeben, werden die Lizenzdatensätze im System geändert.
Wenn keine Lizenz in der Parametdatei angegeben ist, wird die Lizenz aus der planta_server.conf genommen.
Nach dem Lizenzwechsel wird die Migration beendet und es werden keine Migrationspakete danach ausgeführt.
Die möglichen Komponenten stammen aus der __init__.py der jeweiligen Migrationsverzeichnisse
Die angegebenen Komponenten bestimmen den Update-Typ der Migration. So ist es z.B. möglich, nur das Customizing zu migrieren oder nur die Server-Komponente.
Die Parameterdatei gibt nicht nur die Komponenten vor, die migriert werden sollen, sondern auch die Reihenfolge, in der migriert wird.
Alle Pakete, die nicht unter die Liste der angegebenen Komponenten fallen, erhalten den Status Nicht relevant.
In der Beispielparameterdatei unter config/migration/migration.par sind alle Komponenten aufgeführt, die theoretisch denkbar sind. Diese Komponenten müssen unbedingt vor der Migration an die tatsächlich vorliegenden Gegebenheiten angepasst und nicht relevante Komponenten entfernt werden.