Copia tabelle, viste, routine, trigger ed eventi su un altro server, o in un altro database dello stesso.
Dove si trova: Workspace › Strumenti › Migrazione dati
Apri Migrazione dati dalla barra laterale del workspace. Copia tabelle, viste, routine, trigger ed eventi da questa connessione a un altro server, o a un altro database dello stesso.
Scegli cosa copiare nell’albero a sinistra. La sua intestazione ha un filtro per nome: digita parte del nome di un database o di un oggetto per restringere l’elenco senza espandere un database alla volta. Gli oggetti sono raggruppati per tipo (Tabelle, Viste, Routine, Trigger ed Eventi); fare clic su un oggetto lo seleziona, e la casella di ogni database seleziona o deseleziona tutto il suo contenuto, con accanto il numero di oggetti selezionati sul totale. Svuota svuota la selezione. L’ordine lo stabilisce Calíope — tabelle, viste, routine, trigger ed eventi — così ogni oggetto trova già creato ciò da cui dipende.
Scegli dove va. Accanto a Destinazione:, apri Seleziona server di destinazione, scegli una delle connessioni salvate nel Gestore connessioni e premi Connetti. In Nel database, scrivi il database in cui finiranno gli oggetti; vuoto, ogni oggetto mantiene il database che ha nell’origine. Calíope crea quel database se non esiste, e riscrive i riferimenti di una vista perché legga da lì.
Opzioni: Sostituisci nella destinazione elimina tutto ciò che è selezionato prima di creare qualsiasi cosa —prima ciò che dipende dalle tabelle, e le tabelle figlie prima delle madri—, quindi ripetere la stessa migrazione è sicuro; Esporta dati copia le righe di ogni tabella; Salta i controlli FK disattiva il controllo delle chiavi esterne mentre si carica ogni oggetto, così le tabelle possono arrivare in qualsiasi ordine.
Premi Migra. Il registro dà una riga per oggetto, con il database in cui è andato e, per una tabella, le righe copiate. Ferma si arresta tra un oggetto e il successivo.
Le chiavi esterne delle tabelle copiate si creano alla fine, quando ci sono tutte con le loro righe: l'ordine in cui arrivano non conta più.
Tra famiglie di motori diverse un avviso accanto a Migra lo dice prima di eseguire qualsiasi cosa: il DDL di un motore l'altro non lo capisce, quindi non si crea nulla. Si copiano solo righe, in tabelle con lo stesso nome che esistono già nella destinazione, abbinando le colonne per nome; una tabella che la destinazione non ha, o un oggetto che non è una tabella, si salta e il registro lo dice.
SQL Server
Una colonna IDENTITY conserva i suoi valori (Calíope accende IDENTITY_INSERT durante la copia), ma non il suo contatore: nella destinazione la riga successiva riparte dal valore più alto copiato. Ogni oggetto finisce nel suo schema, che viene creato se non esiste. Con solo il nome di un database in Nel database, ogni oggetto conserva il suo schema: demo.dbo va in copia.dbo, e demo.rrhh in copia.rrhh.
PostgreSQL
Qui un database è uno schema del database connesso: Nel database indica lo schema in cui vanno gli oggetti, e viene creato se non esiste. I tipi usati dalle tabelle copiate —un ENUM, un dominio— si creano prima; uno che esiste già nella destinazione si conserva così com’è, perché rifarlo obbligherebbe a eliminare ogni colonna che lo usa. Il search_path di una funzione copiata punta allo schema di destinazione, quindi i suoi trigger scrivono lì e non nell’origine.
ClickHouse
Ogni tabella viene creata dal DDL che il server conserva —motore, PARTITION BY, ORDER BY, TTL e SETTINGS compresi—, e non ci sono chiavi esterne né Salta i controlli FK. Le righe vanno in INSERT da cento alla volta, e una colonna Array, Map o Tuple arriva con il suo tipo. Una vista materializzata viene creata dopo le tabelle e nasce vuota: riceve solo ciò che viene inserito da quel momento. Se scrive in un’altra tabella con TO, seleziona anche quella tabella per portarne le righe.
Se la destinazione è lo stesso server dell’origine e un oggetto finirebbe nel suo stesso database, Migra resta disattivato e un avviso spiega perché: con Sostituisci nella destinazione, la copia eliminerebbe l’originale prima di leggerne le righe.
Se il server che ti serve non compare nel selettore, aggiungilo prima nel Gestore connessioni e riapri Migrazione dati.
Oracle
Con Oracle come destinazione non c’è Salta i controlli FK: Oracle non disattiva le chiavi esterne per sessione. Tra due schemi Oracle, uno schema di destinazione che non esiste viene creato come utente senza password (NO AUTHENTICATION) e con quota sul suo tablespace; le tabelle arrivano con il DDL di Oracle, le righe in INSERT a più righe confermati all’esecuzione, le date come letterali TIMESTAMP e le chiavi esterne alla fine. Oracle salva i nomi in maiuscolo: tra famiglie, una tabella e le sue colonne vengono abbinate anche a quelle che differiscono solo per maiuscole e minuscole (CLIENTES con clientes).
Con un’etichetta di ambiente: la destinazione la protegge l’etichetta del suo profilo. Se conferma le scritture, la migrazione chiede una volta prima di iniziare, contando gli oggetti, e l’anteprima non chiede; se è di sola lettura, non vi si scrive nulla. Con un’etichetta di sola lettura sulla connessione di questa scheda, lo strumento non viene offerto.
Parole chiave: migrare, migration, copiare, spostare, server di destinazione, connessione di destinazione, selettore
Rivedi il SQL che verrebbe eseguito prima di migrare.
Dove si trova: Migrazione dati › Anteprima
Seleziona Anteprima e il pulsante diventa Genera SQL: invece di eseguire qualcosa, Calíope scrive nel pannello di output il SQL che la migrazione eseguirebbe, così puoi rivederlo o copiarlo. È lo stesso script che esegue la migrazione: CREATE DATABASE IF NOT EXISTS, il passaggio a quel database, le chiavi esterne disattivate con Salta i controlli FK, con Sostituisci nella destinazione, prima il DROP di tutto ciò che è selezionato —ciò che dipende dalle tabelle, poi le tabelle figlie prima delle madri—, poi ogni oggetto, e gli INSERT con Esporta dati. Le routine e i trigger stanno tra DELIMITER // e DELIMITER ;, quindi lo script si esegue anche così com’è nell’Editor SQL con Esegui script. In modalità Anteprima non serve connettere la destinazione.
Le chiavi esterne vanno alla fine, dopo tutte le tabelle e le loro righe.
SQL Server
In SQL Server lo script crea il database e lo schema se mancano (IF DB_ID(…) IS NULL), non ha DELIMITER —ogni routine va nel suo EXEC— e le righe con valore di identità vanno tra SET IDENTITY_INSERT … ON e OFF.
PostgreSQL
In PostgreSQL lo script crea lo schema se manca (CREATE SCHEMA IF NOT EXISTS), disattiva le chiavi esterne con SET session_replication_role, crea prima delle tabelle i tipi che usano, e non ha DELIMITER: il corpo di una funzione sta tra virgolette $function$.
ClickHouse
In ClickHouse lo script non cambia database —ogni oggetto porta il suo davanti—, non disattiva le chiavi esterne, perché non ce ne sono, e ogni DROP porta SYNC. Una colonna Array, Map o Tuple va nell’INSERT come JSONExtract('…', 'tipo').
Oracle
In Oracle lo script non ha USE: ogni oggetto porta davanti il suo schema, e inizia con un blocco PL/SQL che crea lo schema di destinazione se non esiste. Non disattiva le chiavi esterne: le lascia per la fine.
Parole chiave: preview, anteprima, SQL preview, rivedere prima di eseguire
Confronta due database sullo stesso server — tabelle, viste, routine, trigger ed eventi — e genera lo script di migrazione.
Dove si trova: Workspace › Strumenti › Confronta schemi
Lo strumento di confronto degli schema (Schema Diff) analizza due database sullo stesso server e mostra esattamente che cosa è cambiato in tabelle, viste, procedure, funzioni e trigger.
MySQLMariaDBAurora
In MySQL e MariaDB confronta anche gli eventi.
SQL Server
In SQL Server ogni lato è uno schema di un database (demo.dbo), e i due possono stare in database diversi dello stesso server.
PostgreSQL
In PostgreSQL ogni lato è uno schema del database connesso (demo, ventas).
Oracle
In Oracle ogni lato è uno schema —un utente, come DEMO o DEMO_R1— del database a cui ti colleghi, e confronta anche package, tipi e sequenze.
Come aprire Schema Diff:
Tocca Confronta schemi (icona con frecce contrapposte) nella barra laterale. Si apre in una nuova schedina.
Uso di base:
1. Scegli l'Origine e la Destinazione nella barra superiore. Lo script modifica l'origine finché non coincide con la destinazione: ciò che ha solo la destinazione viene creato nell'origine, e ciò che ha solo l'origine viene eliminato.
2. Tocca Confronta. Calíope legge la definizione di ogni oggetto sui due lati, così come la scrive il server stesso.
3. Attiva Solo modifiche per nascondere ciò che coincide.
4. Il rapporto è raggruppato per tipo di oggetto. Espandi una riga qualsiasi: in una tabella modificata vedrai, cambiamento per cambiamento, la definizione attuale e quella che la sostituirà; in una vista o procedura modificata, le due definizioni complete a confronto; in un oggetto nuovo o eliminato, il suo DDL.
5. Tocca Copia SQL per l'intero script, o il pulsante di copia di una riga per quel solo oggetto.
6. Eseguilo nell'Editor SQL con Esegui script. Con la Modalità sicura attiva, lo script si ferma prima di raggiungere il server. Poi confronta di nuovo: i due lati devono risultare identici.
MySQLMariaDBAurora
Le definizioni sono lo SHOW CREATE … di ogni oggetto, e l'editor capisce i blocchi DELIMITER con cui arrivano procedure e trigger.
SQL Server
Le definizioni vengono dal catalogo (sys.sql_modules per viste, procedure e trigger). Ogni vista, procedura e trigger va nel proprio EXEC … sp_executesql, perché T-SQL lo vuole da solo nel suo batch, quindi lo script gira senza righe GO.
PostgreSQL
Le definizioni sono quelle che il server scrive con pg_get_viewdef, pg_get_functiondef e pg_get_triggerdef.
Oracle
Le definizioni sono quelle che il server scrive con DBMS_METADATA.GET_DDL, senza storage né tablespace. Prima del confronto si toglie ciò che è un valore di fabbrica: l’ENABLE di ogni vincolo e le opzioni predefinite di un’identità o di una sequenza.
Che cosa genera per le tabelle:
MySQLMariaDBAurora
- Un CREATE TABLE IF NOT EXISTS completo per quelle che mancano nell'origine, con colonne, indici e opzioni.
- DROP TABLE IF EXISTS per quelle in eccesso.
- ALTER TABLE con ADD/DROP/MODIFY COLUMN, conservando tipo, nullabilità, valore predefinito, commento, set di caratteri ed espressione di una colonna generata.
- Aggiunta e rimozione di chiave primaria, indici e vincoli CHECK, oltre alle modifiche delle opzioni di tabella (ENGINE, DEFAULT CHARSET, COLLATE, ROW_FORMAT, COMMENT).
SQL Server
- IF OBJECT_ID(…) IS NULL CREATE TABLE per quelle che mancano nell'origine, con colonne, chiavi e vincoli, e un CREATE INDEX per ogni indice.
- DROP TABLE IF EXISTS per quelle in eccesso.
- ALTER TABLE con ADD, ALTER COLUMN e DROP COLUMN; prima di eliminare una colonna, lo script elimina il vincolo di valore predefinito che ne dipende.
- Aggiunta e rimozione di chiave primaria, indici e vincoli CHECK.
PostgreSQL
- CREATE TABLE IF NOT EXISTS per quelle che mancano nell'origine, con colonne e vincoli, e un CREATE INDEX per ogni indice.
- DROP TABLE IF EXISTS per quelle in eccesso.
- ALTER TABLE con ADD COLUMN, DROP COLUMN e ALTER COLUMN … TYPE, SET/DROP NOT NULL e SET/DROP DEFAULT.
- Aggiunta e rimozione di chiave primaria, indici e vincoli CHECK, e il commento della tabella (COMMENT ON TABLE).
Oracle
- CREATE TABLE IF NOT EXISTS per quelle che mancano nell’origine, con colonne, chiave primaria, vincoli UNIQUE e CHECK e il loro partizionamento, e un CREATE INDEX per ogni indice. Un indice spaziale è preceduto dai suoi metadati (USER_SDO_GEOM_METADATA), senza i quali il server non lo crea.
- DROP TABLE IF EXISTS … CASCADE CONSTRAINTS PURGE per quelle in più.
- ALTER TABLE con ADD, DROP COLUMN e MODIFY, che scrive solo ciò che cambia: il tipo, il valore predefinito o la nullabilità.
- Aggiunta e rimozione di chiave primaria, indici e vincoli, e i commenti della tabella e delle sue colonne (COMMENT ON).
Che cosa genera per tutto il resto:
Una vista o una procedura non si può correggere a pezzi: se la sua definizione è diversa, lo script la rifà con quella della destinazione, riscrivendo i riferimenti allo schema di origine perché punti al posto giusto.
MySQLMariaDBAurora
La rifà con DROP + CREATE.
SQL Server
La rifà con CREATE OR ALTER, che viste, procedure, funzioni e trigger accettano.
PostgreSQL
La rifà con CREATE OR REPLACE; un trigger o una vista materializzata, che non lo hanno, vengono eliminati e ricreati.
Oracle
Lo ricrea con il CREATE OR REPLACE che il suo DDL porta già; una sequenza o una vista materializzata, che non lo hanno, vengono eliminate e ricreate. Un trigger viene creato sulla tabella dello schema che si ripara.
Ordine dello script:
Prima le tabelle; poi le chiavi esterne, in un blocco a parte, perché creando più tabelle l'ordine alfabetico non rispetta le dipendenze; quindi gli altri oggetti per tipo, e all'interno di ogni tipo ordinati per dipendenze — una vista costruita su un'altra viene emessa dopo di essa.
MySQLMariaDBAuroraSQL Server
Prima del primo oggetto che non è una tabella, lo script fissa il database attivo con un USE.
PostgreSQL
Prima delle tabelle vengono i tipi propri dello schema, con cui si dichiarano le loro colonne.
Oracle
Oracle non ha USE: ogni istruzione è qualificata con lo schema che si ripara. Prima delle tabelle vengono i tipi oggetto (CREATE TYPE) con cui sono dichiarate le loro colonne.
Ignorato di proposito:
MySQLMariaDBAurora
Il contatore AUTO_INCREMENT, che avanza a ogni inserimento e non coincide mai tra due copie.
SQL ServerPostgreSQLOracle
Il valore attuale di una colonna di identità, che avanza a ogni inserimento e non coincide mai tra due copie.
Oracle
Né il valore attuale di una sequenza (START WITH).
Che cosa non copre:
Le colonne di una tabella esistente non vengono riordinate, e una colonna rinominata appare come una rimozione più un'aggiunta. Viste, procedure e trigger si confrontano testualmente: anche solo una formattazione diversa conta come differenza.
MySQLMariaDBAurora
Una modifica del partizionamento viene rilevata e segnalata come avviso, ma mai tradotta in SQL: ripartizionare riscrive l'intera tabella. Anche un DEFINER diverso conta come differenza, e in MariaDB il DDL di un trigger è il testo letterale con cui è stato scritto. Anche un evento con orario di inizio diverso risulta differente, perché quell'orario fa parte della sua definizione.
PostgreSQL
I tipi propri — ENUM, domini, tipi compositi — si confrontano come una vista, nel loro gruppo Tipi. Lo script crea quelli che mancano prima delle tabelle che li usano ed elimina alla fine di tutto quelli che ha solo l'origine. Un ENUM che ha solo guadagnato etichette in fondo si aggiorna con ALTER TYPE … ADD VALUE; qualsiasi altra modifica di un tipo resta nello script come nota da applicare a mano, perché ricreare un tipo in uso obbliga a riscrivere ogni colonna che lo usa. I tipi creati da un'estensione, come quelli di PostGIS, restano fuori: li porta il suo CREATE EXTENSION.
Oracle
Un tipo oggetto in uso che differisce e un cambio di partizionamento restano nello script come nota da gestire a mano, e così anche aggiungere un’identità a una colonna esistente, che il server non accetta. Un vincolo con nome di sistema (SYS_C…) viene abbinato per la sua definizione.
Controlla sempre lo script prima di eseguirlo in produzione.
Caso d'uso tipico:
Prima di un rilascio, confrontare la produzione (origine) con lo schema di sviluppo (destinazione): lo script porta la produzione a ciò che lo sviluppo ha già, senza scriverlo a mano.
Disponibile su macOS, iPad, iPhone e Apple Vision Pro.
ClickHouse
In ClickHouse confronta tabelle e viste a partire dal loro SHOW CREATE. Colonne, indici di salto, proiezioni, vincoli, TTL, SETTINGS e il commento si sincronizzano con ALTER TABLE; un cambio di motore, ORDER BY, PARTITION BY, PRIMARY KEY o SAMPLE BY non sta in un ALTER, quindi esce nello script come un commento che dice che la tabella va ricreata. Le viste materializzate e i dizionari non si confrontano, e il motore non ha procedure né trigger.
Parole chiave: schema diff, confrontare, schema, alter table, migrazione, differenze, ADD COLUMN, DROP COLUMN, MODIFY COLUMN, SHOW CREATE TABLE, CREATE TABLE, indici, chiavi esterne, partizionamento, solo modifiche