Schema-Export | PLANTA Online-Hilfe

Information

Es besteht die Möglichkeit, die derzeitige Definition der Datenbank (Datentabellen, Spalten, Constraints etc.) im Oracle- bzw. MSSQL-Format zu exportieren.

Voraussetzung

Das Verzeichnis, in welches exportiert werden soll, kann unter Customizer → Stammdaten → Globale Einstellungen in dem Datenfeld Template-Code für die globale Einstellung export_path_databasescheme als Defaultwert hinterlegt werden.

Vorgehensweise

Wählen Sie Customizer → Datenbanken → Datenbankschema-Export, um einen Schema-Export anzustoßen.
- Es muss ein für den worker Container schreibbarer Pfad eingetragen werden, zB /var/planta
- Ein Export kann ca. 30 Sekunden bis 1 Minute dauern.
Danach befindet sich das exportierte Schema in dem angegebenen Verzeichnis unter \SQLServer_<Export-Zeitstempel>\SQLServer_create.sql bzw. \Oracle10g_<Export-Zeitstempel>\Oracle10g_create.sql.
Die drop -Skripte beinhalten Informationen darüber, wie das derzeitige Schema gelöscht wird.
Die hibernate_mapping -Unterverzeichnisse enthalten Definitionen der Datenbank-Tabellen für Java.
Um das exportierte Schema in eine neue Datenbank zu überführen, kann der Inhalt der _create.sql theoretisch einfach ausgeführt werden, z.B. in SqlPlus oder SqlDeveloper.
- Es wird dringend empfohlen, dies in einem regulären Installationsprozess zu tun.

Hinweise

Es wird nur die Datenbank-Definition (das Schema) exportiert, nicht der Datenbank-Inhalt (echte Daten).
Es wird prinzipiell immer ein Schema sowohl im Oracle- als auch im MSSQL-Format erstellt, unabhängig davon, welches Format die tatsächlich verwendete Datenbank hat.
- Daher ist es nicht nötig, den Schema-Export zweimal (etwa mit einer Oracle- und einer MSSQL-Datenbank) aufzurufen.

Detaillierter Aufbau des Skript-Inhalts

In einem create-Skript erfolgen zuerst die Definitionen aller Datentabellen einschließlich ihrer Spalten.
Es werden folgende Datentabellen exportiert:
- Alle aktivierten PLANTA-Datentabellen, d.h. alle Datentabellen, für deren Schema die Checkbox Aktiviert aktiviert ist und zusätzlich die Checkbox Aktiviert für die Datentabelle selbst aktiviert ist.
- Für jede Datentabelle der Schemas Q1B und Q2B außerdem eine Datentabelle gleichen Namens mit der Endung _HIS und gleichen Spalten, die Hibernate Envers benötigt, um Historie-Daten zu speichern. Siehe auch Historisierung.
- Ferner die interne Tabelle REVINFO von Envers.
Definition der Datentabellenspalten:
- Sämtliche Spalten, die auf Aktiviert gesetzt sind, werden geschrieben.
- Jede Datentabelle (mit Ausnahme von REVINFO) hat ab Version S 39.5.0 eine Spalte UUID, die für jeden Datensatz eine eindeutige ID enthält.
- Die Primärschlüssel stehen jeweils vor dem UUID-Feld und werden am Ende der Datentabelle definiert.
- Default-Werte und NOT NULL Constraints:
  - Alle Spalten des Primärschlüssels implizieren einen NOT NULL Constraint.
  - Alle numerischen Felder (Integer, Short, Double) haben einen NOT NULL Constraint und als Standardwert 0.
  - Alle Datumsfelder haben einen NOT NULL Constraint und als Standardwert den 01.01.1970 (je in Oracle- oder MSSQL-Notation).
  - Die UUID-Felder kreieren als Standardwert einen neuen, eindeutigen UUID-Wert (je in Oracle- bzw. MSSQL-Notation) und haben ebenfalls einen NOT NULL Constraint.
  - Eine Ausnahme bilden numerische Felder, die Teil eines Fremdschlüssels sind, in deren referenzierter Datentabelle NULL erlaubt aktiviert ist. Solche Spalten haben weder Default-Wert noch NOT NULL Constraint.
Danach folgen die Definitionen der Indizes und Constraints zu allen Datentabellen.
- Es gibt dabei verschiedene Arten von Indizes und Constraints:
  - I-Text-Indizes für jede Datentabelle, deren Datensätze einen I-Text beinhalten. Dieser Index-Typ hat keinen Constraint.
  - Fremdschlüssel-Indizes für jede Datentabelle, die einen Link auf eine andere Datentabelle definiert. Dieser Index-Typ definiert zudem noch einen Constraint (oder, in MSSQL, einen Trigger für Update- und Delete-Funktionalität).
  - Envers legt für seine History-Tabellen des Weiteren noch Constraints an, die auf die allgemeine Envers-Tabelle REVINFO verweisen. Envers legt dafür keine Indizes an
Zuletzt enthält das Skript noch (für Oracle-Datenbanken) eine neue Datenbank-Sequenz, die von Envers benötigt wird.

Export über docker compose

Der Schema- bzw. Datenexport kann auch über das Migrationsverfahren mit Hilfe der docker compose aufgerufen werden. Siehe auch Migrationsverfahren

Beispiel Aufbau:

docker compose

services:
  manager:
    image: registry.planta.services/project/manager:stable
    environment:
      - "SKIP_INIT=1"
      - "planta__server__hibernate__connection__url=<DB_CONNECTION_URL>"
      - "planta__server__hibernate__connection__username=<DB_USERNAME>"
      - "planta__server__hibernate__connection__password=<DB_PASSWORD>"
    command: ["migration", "-c /planta/parameter.par"]
    depends_on:
      customizing:
        condition: service_completed_successfully
        restart: true
    networks:
      - internal
    volumes:
      - transfer:/mnt/transfer:ro
      - ./data_export.par:/planta/data_export.par:ro
      - ./:/var/planta/export:rw

  worker:
    image: registry.planta.services/project/worker:stable
    environment:
      - "SESSION_LINK=manager:54242"
    depends_on:
      manager:
        condition: service_healthy
        restart: true
      customizing:
        condition: service_completed_successfully
        restart: true
    networks:
      - internal
    volumes:
      - transfer:/mnt/transfer:ro
      - ./export.par:/planta/parameter.par:ro

  customizing:
    image: registry.planta.services/project/customizing:stable
    environment:
      - LOG_LEVEL=INFO
    volumes:
      - transfer:/mnt/transfer:rw

networks:
  internal:
volumes:
  transfer:

export.par

--export-data
    /planta/data_export.par 
--export-schema
    /var/planta/export/schema

data_export.par

--exclude-licenses
    ZZZ

--output-file
    export/data

--exclude-tables
    MIGRATIONRULE
    MIGRATIONHISTORY
    DT153
    DT348
    DT396
    DT547
    DT953
    DT820
    DT004
    DT936