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 Events); 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 Events —, 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.
ClickHouse
Jede Tabelle wird aus der DDL erstellt, die der Server speichert —Engine, PARTITION BY, ORDER BY, TTL und SETTINGS eingeschlossen—, und es gibt weder Fremdschlüssel noch FK-Checks überspringen. Die Zeilen gehen in INSERT-Anweisungen zu je hundert, und eine Array-, Map- oder Tuple-Spalte kommt mit ihrem Typ an. Eine materialisierte View wird nach den Tabellen erstellt und ist zunächst leer: Sie erhält nur, was ab dann eingefügt wird. Schreibt sie mit TO in eine andere Tabelle, markiere auch diese Tabelle, um ihre Zeilen mitzunehmen.
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.
Oracle
Mit Oracle als Ziel gibt es kein FK-Checks überspringen: Oracle schaltet Fremdschlüssel nicht pro Sitzung ab. Zwischen zwei Oracle-Schemas wird ein Zielschema, das nicht existiert, als Benutzer ohne Passwort (NO AUTHENTICATION) und mit Quota auf seinem Tablespace angelegt; die Tabellen kommen mit dem DDL von Oracle, ihre Zeilen als mehrzeilige INSERTs, die beim Ausführen bestätigt werden, Datumswerte als TIMESTAMP-Literale und die Fremdschlüssel zuletzt. Oracle speichert Namen in Großbuchstaben: zwischen Familien werden eine Tabelle und ihre Spalten auch mit denen gepaart, die sich nur in der Schreibweise unterscheiden (CLIENTES mit clientes).
Mit einem Umgebungsetikett: Das Ziel schützt das Etikett seines Profils. Bestätigt es Schreibzugriffe, fragt die Migration einmal vor dem Start und zählt dabei die Objekte, und die Vorschau fragt nicht; ist es schreibgeschützt, wird nichts hineingeschrieben. Mit einem schreibgeschützten Etikett auf der Verbindung dieses Tabs wird das Werkzeug nicht angeboten.
Stichwörter: migrieren, Migration, kopieren, verschieben, Zielserver, Zielverbindung, Auswahlmenü
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.
ClickHouse
In ClickHouse wechselt das Skript die Datenbank nicht —jedes Objekt trägt seine eigene vorne—, schaltet keine Fremdschlüssel ab, weil es keine gibt, und jedes DROP trägt SYNC. Eine Array-, Map- oder Tuple-Spalte steht im INSERT als JSONExtract('…', 'Typ').
Oracle
In Oracle hat das Skript kein USE: Jedes Objekt trägt sein Schema vorne, und es beginnt mit einem PL/SQL-Block, der das Zielschema anlegt, falls es nicht existiert. Fremdschlüssel schaltet es nicht ab: Es lässt sie für das Ende.
Stichwörter: Preview, Vorschau, SQL-Vorschau, vor dem Ausführen prüfen
Vergleicht zwei Datenbanken auf demselben Server – Tabellen, Views, Routinen, Trigger und Events – und erzeugt das Migrationsskript.
Wo es zu finden ist: Workspace › Werkzeuge › Schemas vergleichen
Das Werkzeug zum Vergleichen von Schemas (Schema Diff) analysiert zwei Datenbanken auf demselben Server und zeigt genau, was sich bei Tabellen, Views, Prozeduren, Funktionen und Triggern geändert hat.
MySQLMariaDBAurora
Unter MySQL und MariaDB vergleicht es auch die Events.
SQL Server
Unter SQL Server ist jede Seite ein Schema einer Datenbank (demo.dbo), und die beiden dürfen in verschiedenen Datenbanken desselben Servers liegen.
PostgreSQL
Unter PostgreSQL ist jede Seite ein Schema der verbundenen Datenbank (demo, ventas).
Oracle
In Oracle ist jede Seite ein Schema —ein Benutzer wie DEMO oder DEMO_R1— der Datenbank, mit der du verbunden bist, und verglichen werden auch Pakete, Typen und Sequenzen.
Schema Diff öffnen:
Klicke in der Seitenleiste auf Schemas vergleichen (Symbol mit gegenläufigen Pfeilen). Es öffnet sich in einem neuen Tab.
Grundlegende Verwendung:
1. Wähle in der oberen Leiste Quelle und Ziel. Das Skript ändert die Quelle, bis sie dem Ziel entspricht: Was nur das Ziel hat, wird in der Quelle angelegt, und was nur die Quelle hat, wird gelöscht.
2. Klicke auf Vergleichen. Calíope liest die Definition jedes Objekts auf beiden Seiten, so wie der Server selbst sie schreibt.
3. Schalte Nur Änderungen ein, um Übereinstimmendes auszublenden.
4. Der Bericht ist nach Objekttyp gruppiert. Klappe eine Zeile auf: Bei einer geänderten Tabelle steht Änderung für Änderung die vorhandene und die künftige Definition; bei einer geänderten View oder Routine stehen beide vollständigen Definitionen nebeneinander; bei einem neuen oder gelöschten Objekt sein DDL.
5. Klicke auf SQL kopieren für das ganze Skript oder auf die Kopieren-Schaltfläche einer Zeile für nur dieses Objekt.
6. Führe es im SQL-Editor mit Skript ausführen aus. Mit eingeschaltetem Safe Mode hält er das Skript an, bevor es den Server erreicht. Vergleiche danach erneut: Beide Seiten sollten identisch sein.
MySQLMariaDBAurora
Die Definitionen sind das SHOW CREATE … jedes Objekts, und der Editor versteht die DELIMITER-Blöcke, in denen Routinen und Trigger kommen.
SQL Server
Die Definitionen stammen aus dem Katalog (sys.sql_modules für Views, Routinen und Trigger). Jede View, Routine und jeder Trigger kommt in ein eigenes EXEC … sp_executesql, weil T-SQL sie allein im Batch verlangt; deshalb läuft das Skript ohne GO-Zeilen.
PostgreSQL
Die Definitionen sind die, die der Server mit pg_get_viewdef, pg_get_functiondef und pg_get_triggerdef schreibt.
Oracle
Die Definitionen sind die, die der Server mit DBMS_METADATA.GET_DDL schreibt, ohne Speicher- und Tablespace-Angaben. Vor dem Vergleich wird entfernt, was Werkseinstellung ist: das ENABLE jeder Einschränkung und die Standardoptionen einer Identität oder Sequenz.
Was für Tabellen erzeugt wird:
MySQLMariaDBAurora
- Ein vollständiges CREATE TABLE IF NOT EXISTS für die in der Quelle fehlenden, mit Spalten, Indizes und Optionen.
- DROP TABLE IF EXISTS für die überzähligen.
- ALTER TABLE mit ADD/DROP/MODIFY COLUMN — Typ, Nullbarkeit, Standardwert, Kommentar, Zeichensatz und der Ausdruck einer generierten Spalte bleiben erhalten.
- Hinzufügen und Entfernen von Primärschlüssel, Indizes und CHECK-Bedingungen sowie Änderungen an Tabellenoptionen (ENGINE, DEFAULT CHARSET, COLLATE, ROW_FORMAT, COMMENT).
SQL Server
- IF OBJECT_ID(…) IS NULL CREATE TABLE für die in der Quelle fehlenden, mit Spalten, Schlüsseln und Bedingungen, und ein CREATE INDEX für jeden Index.
- DROP TABLE IF EXISTS für die überzähligen.
- ALTER TABLE mit ADD, ALTER COLUMN und DROP COLUMN; bevor eine Spalte entfernt wird, entfernt das Skript die Standardwert-Bedingung, die an ihr hängt.
- Hinzufügen und Entfernen von Primärschlüssel, Indizes und CHECK-Bedingungen.
PostgreSQL
- CREATE TABLE IF NOT EXISTS für die in der Quelle fehlenden, mit Spalten und Bedingungen, und ein CREATE INDEX für jeden Index.
- DROP TABLE IF EXISTS für die überzähligen.
- ALTER TABLE mit ADD COLUMN, DROP COLUMN und ALTER COLUMN … TYPE, SET/DROP NOT NULL und SET/DROP DEFAULT.
- Hinzufügen und Entfernen von Primärschlüssel, Indizes und CHECK-Bedingungen sowie der Tabellenkommentar (COMMENT ON TABLE).
Oracle
- CREATE TABLE IF NOT EXISTS für die, die in der Quelle fehlen, mit Spalten, Primärschlüssel, UNIQUE- und CHECK-Einschränkungen und ihrer Partitionierung, und ein CREATE INDEX pro Index. Vor einem räumlichen Index stehen seine Metadaten (USER_SDO_GEOM_METADATA), ohne die der Server ihn nicht anlegt.
- DROP TABLE IF EXISTS … CASCADE CONSTRAINTS PURGE für die überzähligen.
- ALTER TABLE mit ADD, DROP COLUMN und MODIFY, das nur schreibt, was sich ändert: den Typ, den Standardwert oder die NULL-Zulässigkeit.
- Anlegen und Entfernen von Primärschlüssel, Indizes und Einschränkungen sowie die Kommentare der Tabelle und ihrer Spalten (COMMENT ON).
Was für alles Übrige erzeugt wird:
Eine View oder eine Routine lässt sich nicht stückweise reparieren: Weicht ihre Definition ab, baut das Skript sie mit der des Ziels neu und schreibt dabei die Verweise auf das Quellschema um, damit sie an die richtige Stelle zeigt.
MySQLMariaDBAurora
Neu gebaut wird mit DROP + CREATE.
SQL Server
Neu gebaut wird mit CREATE OR ALTER, das Views, Prozeduren, Funktionen und Trigger annehmen.
PostgreSQL
Neu gebaut wird mit CREATE OR REPLACE; ein Trigger oder eine materialisierte View, die es nicht haben, werden gelöscht und neu angelegt.
Oracle
Er baut es mit dem CREATE OR REPLACE neu, das seine DDL schon mitbringt; eine Sequenz oder eine materialisierte View, die keins haben, werden gelöscht und neu angelegt. Ein Trigger wird auf der Tabelle des Schemas angelegt, das repariert wird.
Reihenfolge des Skripts:
Zuerst die Tabellen; dann die Fremdschlüssel in einem eigenen Block, denn beim Anlegen mehrerer Tabellen beachtet die alphabetische Reihenfolge die Abhängigkeiten nicht; danach die übrigen Objekte nach Typ, innerhalb jedes Typs nach Abhängigkeiten sortiert — eine View, die auf einer anderen aufbaut, kommt nach dieser.
MySQLMariaDBAuroraSQL Server
Vor dem ersten Objekt, das keine Tabelle ist, setzt das Skript die aktive Datenbank mit einem USE.
PostgreSQL
Vor den Tabellen kommen die eigenen Typen des Schemas, mit denen ihre Spalten deklariert sind.
Oracle
Oracle hat kein USE: Jede Anweisung ist mit dem Schema qualifiziert, das repariert wird. Vor den Tabellen kommen die Objekttypen (CREATE TYPE), mit denen ihre Spalten deklariert sind.
Absichtlich ignoriert:
MySQLMariaDBAurora
Der AUTO_INCREMENT-Zähler, der mit jedem Insert wächst und zwischen zwei Kopien nie übereinstimmt.
SQL ServerPostgreSQLOracle
Der aktuelle Wert einer Identitätsspalte, der mit jedem Insert wächst und zwischen zwei Kopien nie übereinstimmt.
Oracle
Auch nicht der aktuelle Wert einer Sequenz (START WITH).
Was nicht abgedeckt ist:
Spalten einer bestehenden Tabelle werden nicht umsortiert, und eine umbenannte Spalte erscheint als Löschung plus Neuanlage. Views, Routinen und Trigger werden textuell verglichen: Schon eine andere Formatierung zählt als Unterschied.
MySQLMariaDBAurora
Eine geänderte Partitionierung wird erkannt und als Hinweis vermerkt, aber nie in SQL übersetzt: Neu zu partitionieren schreibt die ganze Tabelle neu. Auch ein anderer DEFINER zählt als Unterschied, und unter MariaDB ist das DDL eines Triggers der wörtliche Text, mit dem er geschrieben wurde. Ein Event mit anderer Startzeit unterscheidet sich ebenfalls, denn diese Zeit gehört zu seiner Definition.
PostgreSQL
Eigene Typen — ENUM, Domänen, zusammengesetzte Typen — werden wie eine View verglichen, in einer eigenen Gruppe Typen. Das Skript legt die fehlenden vor den Tabellen an, die sie nutzen, und löscht die, die nur die Quelle hat, ganz am Ende. Ein ENUM, das nur am Ende Werte hinzubekommen hat, wird mit ALTER TYPE … ADD VALUE aktualisiert; jede andere Änderung eines Typs bleibt als Hinweis im Skript und ist von Hand zu machen, denn einen benutzten Typ neu anzulegen heißt, jede Spalte neu zu schreiben, die ihn nutzt. Die Typen einer Erweiterung, etwa die von PostGIS, bleiben außen vor: Sie kommen mit ihrem CREATE EXTENSION.
Oracle
Ein verwendeter Objekttyp, der abweicht, und eine geänderte Partitionierung bleiben als Hinweis im Skript, um sie von Hand zu erledigen, ebenso eine Identität für eine vorhandene Spalte, die der Server nicht zulässt. Eine Einschränkung mit Systemnamen (SYS_C…) wird über ihre Definition zugeordnet.
Prüfe das Skript immer, bevor du es in der Produktion ausführst.
Typischer Anwendungsfall:
Vor einem Deployment die Produktion (Quelle) mit dem Entwicklungsschema (Ziel) vergleichen: Das Skript bringt die Produktion auf den Stand, den die Entwicklung schon hat, ohne es von Hand zu schreiben.
Verfügbar unter macOS, iPad, iPhone und Apple Vision Pro.
ClickHouse
Bei ClickHouse vergleicht es Tabellen und Views anhand ihres SHOW CREATE. Spalten, Skip-Indizes, Projektionen, Constraints, TTL, SETTINGS und der Kommentar werden mit ALTER TABLE abgeglichen; eine Änderung von Engine, ORDER BY, PARTITION BY, PRIMARY KEY oder SAMPLE BY passt in kein ALTER, deshalb erscheint sie im Skript als Kommentar, der sagt, dass die Tabelle neu angelegt werden muss. Materialisierte Views und Wörterbücher werden nicht verglichen, und die Engine hat weder Prozeduren noch Trigger.
Stichwörter: Schema Diff, vergleichen, Schema, ALTER TABLE, Migration, Unterschiede, ADD COLUMN, DROP COLUMN, MODIFY COLUMN, SHOW CREATE TABLE, CREATE TABLE, Indizes, Fremdschlüssel, Partitionierung, nur Änderungen