Datenmigration — Calíope-Hilfe

Objekte zwischen Servern migrieren

Kopiert Tabellen, Views, Routinen, Trigger und Events auf einen anderen Server oder in eine andere Datenbank desselben Servers.

Wo es zu finden ist: Workspace › Werkzeuge › Datenmigration

Öffne Datenmigration über die Seitenleiste des Workspace. Sie kopiert Tabellen, Views, Routinen, Trigger und Events von dieser Verbindung auf einen anderen Server oder in eine andere Datenbank desselben Servers.

Wähl aus, was kopiert wird, im Baum links. Seine Kopfzeile hat einen Filter nach Namen: Tipp einen Teil eines Datenbank- oder Objektnamens ein, um die Liste einzugrenzen, ohne Datenbank für Datenbank aufzuklappen. Objekte sind nach Art gruppiert (Tabellen, Views, Routinen, Trigger und Ereignisse); ein Klick auf ein Objekt hakt es an, und das Kontrollkästchen jeder Datenbank wählt ihren gesamten Inhalt aus oder ab, daneben die Zahl der ausgewählten Objekte von der Gesamtzahl. Leeren leert die Auswahl. Die Reihenfolge legt Calíope fest — Tabellen, Views, Routinen, Trigger und Ereignisse —, damit jedes Objekt das, wovon es abhängt, bereits erstellt vorfindet.

Wähl aus, wohin es geht. Neben Ziel: öffnest du Zielserver auswählen, wählst eine der im Verbindungsmanager gespeicherten Verbindungen und klickst auf Verbinden. In In Datenbank trägst du die Datenbank ein, in der die Objekte landen; leer behält jedes Objekt die Datenbank, die es in der Quelle hat. Calíope legt diese Datenbank an, falls es sie nicht gibt, und schreibt die Verweise einer View so um, dass sie von dort liest.

Optionen: Am Ziel ersetzen löscht alles Markierte, bevor etwas angelegt wird —zuerst, was von den Tabellen abhängt, und Kindtabellen vor ihren Elterntabellen—, sodass dieselbe Migration gefahrlos wiederholt werden kann; Daten exportieren kopiert die Zeilen jeder Tabelle; FK-Checks überspringen schaltet die Prüfung der Fremdschlüssel ab, während jedes Objekt geladen wird, damit die Tabellen in beliebiger Reihenfolge ankommen können.

Klick auf Migrieren. Das Protokoll zeigt eine Zeile pro Objekt, mit der Datenbank, in die es ging, und bei einer Tabelle den kopierten Zeilen. Stoppen hält zwischen einem Objekt und dem nächsten an.

Die Fremdschlüssel der kopierten Tabellen werden am Ende angelegt, wenn alle Tabellen mit ihren Zeilen da sind: Die Reihenfolge, in der sie ankommen, spielt keine Rolle mehr.

Zwischen verschiedenen Engine-Familien sagt ein Hinweis neben Migrieren das, bevor etwas ausgeführt wird: Das DDL der einen Engine versteht die andere nicht, also wird nichts angelegt. Kopiert werden nur Zeilen, in gleichnamige Tabellen, die im Ziel schon existieren, mit nach Namen zugeordneten Spalten; eine Tabelle, die das Ziel nicht hat, oder ein Objekt, das keine Tabelle ist, wird übersprungen, und das Protokoll sagt es.

SQL Server

Eine IDENTITY-Spalte behält ihre Werte (Calíope schaltet beim Kopieren IDENTITY_INSERT ein), aber nicht ihren Zähler: Im Ziel geht die nächste Zeile vom höchsten kopierten Wert aus weiter. Jedes Objekt landet in seinem Schema, das angelegt wird, wenn es fehlt. Steht in In Datenbank nur ein Datenbankname, behält jedes Objekt sein Schema: demo.dbo geht nach copia.dbo und demo.rrhh nach copia.rrhh.

PostgreSQL

Hier ist eine Datenbank ein Schema der verbundenen Datenbank: In Datenbank nennt das Schema, in das die Objekte gehen, und es wird angelegt, wenn es fehlt. Die Typen, die die kopierten Tabellen verwenden —ein ENUM, eine Domäne—, werden zuerst angelegt; einer, der im Ziel schon existiert, bleibt, wie er ist, denn ihn neu anzulegen hieße, jede Spalte zu löschen, die ihn verwendet. Der search_path einer kopierten Funktion zeigt auf das Zielschema, sodass ihre Trigger dorthin schreiben und nicht in die Quelle.

> Ist das Ziel derselbe Server wie die Quelle und würde ein Objekt in seiner eigenen Datenbank landen, bleibt Migrieren deaktiviert, und ein Hinweis sagt warum: Mit Am Ziel ersetzen würde die Kopie das Original löschen, bevor sie seine Zeilen liest.

> Wenn der benötigte Server nicht im Auswahlmenü erscheint, füge ihn zuerst im Verbindungsmanager hinzu und öffne die Datenmigration erneut.

Stichwörter: migrieren, Migration, kopieren, verschieben, Zielserver, Zielverbindung, Auswahlmenü

Migrations-SQL in der Vorschau ansehen

Prüfe das SQL, das ausgeführt würde, bevor du migrierst.

Wo es zu finden ist: Datenmigration › Vorschau

Hak Vorschau an, und der Button wird zu SQL generieren: Statt etwas auszuführen, schreibt Calíope das SQL, das die Migration ausführen würde, in das Ausgabe-Panel, damit du es prüfen oder kopieren kannst. Es ist dasselbe Skript, das die Migration ausführt: CREATE DATABASE IF NOT EXISTS, der Wechsel in diese Datenbank, abgeschaltete Fremdschlüssel mit FK-Checks überspringen, mit Am Ziel ersetzen zuerst das DROP alles Markierten —was von den Tabellen abhängt, dann Kindtabellen vor ihren Elterntabellen—, danach jedes Objekt und die INSERT mit Daten exportieren. Routinen und Trigger stehen zwischen DELIMITER // und DELIMITER ;, sodass das Skript auch unverändert im SQL-Editor mit Skript ausführen läuft. Im Vorschau-Modus brauchst du keine Verbindung zum Ziel.

Die Fremdschlüssel kommen ans Ende, nach allen Tabellen und ihren Zeilen.

SQL Server

In SQL Server legt das Skript Datenbank und Schema an, wenn sie fehlen (IF DB_ID(…) IS NULL), hat kein DELIMITER —jede Routine steht in ihrem eigenen EXEC— und Zeilen mit Identitätswert stehen zwischen SET IDENTITY_INSERT … ON und OFF.

PostgreSQL

In PostgreSQL legt das Skript das Schema an, wenn es fehlt (CREATE SCHEMA IF NOT EXISTS), schaltet die Fremdschlüssel mit SET session_replication_role ab, legt vor den Tabellen die Typen an, die sie verwenden, und hat kein DELIMITER: Der Rumpf einer Funktion steht zwischen $function$ -Anführungszeichen.

Stichwörter: Preview, Vorschau, SQL-Vorschau, vor dem Ausführen prüfen