Migration de données — Aide Calíope

Migrer des objets entre serveurs

Copiez tables, vues, routines, triggers et événements vers un autre serveur, ou vers une autre base du même serveur.

Où le trouver : Espace de travail › Outils › Migration de données

Ouvrez Migration de données depuis la barre latérale du workspace. Elle copie tables, vues, routines, triggers et événements de cette connexion vers un autre serveur, ou vers une autre base du même serveur.

Choisissez quoi copier dans l’arborescence de gauche. Son en-tête a un filtre par nom : saisissez une partie du nom d’une base ou d’un objet pour restreindre la liste sans déplier base par base. Les objets sont regroupés par type (Tables, Vues, Routines, Déclencheurs et Événements) ; cliquer sur un objet le coche, et la case de chaque base coche ou décoche tout son contenu, avec à côté le nombre d’objets cochés sur le total. Effacer vide la sélection. Calíope fixe l’ordre — tables, vues, routines, déclencheurs et événements — pour que chaque objet trouve déjà créé ce dont il dépend.

Choisissez la destination. À côté de Destination :, ouvrez Choisir le serveur cible, choisissez l’une des connexions enregistrées dans le Gestionnaire de connexions et cliquez sur Connecter. Dans Dans la base, saisissez la base où arriveront les objets ; vide, chaque objet garde la base qu’il a à la source. Calíope crée cette base si elle n’existe pas, et réécrit les références d’une vue pour qu’elle lise depuis celle-ci.

Options : Remplacer à destination supprime tout ce qui est coché avant de créer quoi que ce soit —d’abord ce qui dépend des tables, et les tables filles avant leurs mères—, donc relancer la même migration est sans risque ; Exporter les données copie les lignes de chaque table ; Ignorer les vérifications FK désactive la vérification des clés étrangères pendant le chargement de chaque objet, pour que les tables puissent arriver dans n’importe quel ordre.

Cliquez sur Migrer. Le journal donne une ligne par objet, avec la base où il est allé et, pour une table, les lignes copiées. Arrêter s’arrête entre un objet et le suivant.

Les clés étrangères des tables copiées sont créées à la fin, une fois toutes les tables présentes avec leurs lignes : l'ordre d'arrivée n'a plus d'importance.

Entre familles de moteurs différentes, un avertissement à côté de Migrer le signale avant toute exécution : le DDL d'un moteur n'est pas compris par l'autre, donc rien n'est créé. Seules les lignes sont copiées, vers des tables du même nom qui existent déjà dans la destination, en appariant les colonnes par nom ; une table que la destination n'a pas, ou un objet qui n'est pas une table, est ignoré et le journal l'indique.

SQL Server

Une colonne IDENTITY conserve ses valeurs (Calíope active IDENTITY_INSERT pendant la copie), mais pas son compteur : dans la destination, la ligne suivante repart de la valeur la plus haute copiée. Chaque objet arrive dans son schéma, créé s'il n'existe pas. Avec seulement un nom de base dans Dans la base, chaque objet garde son schéma : demo.dbo va dans copia.dbo, et demo.rrhh dans copia.rrhh.

PostgreSQL

Ici, une base est un schéma de la base connectée : Dans la base nomme le schéma où vont les objets, et il est créé s’il n’existe pas. Les types qu’utilisent les tables copiées —un ENUM, un domaine— sont créés d’abord ; un type qui existe déjà dans la destination est conservé tel quel, car le refaire obligerait à supprimer chaque colonne qui l’utilise. Le search_path d’une fonction copiée pointe vers le schéma de destination, donc ses triggers écrivent là et non dans la source.

> Si la destination est le même serveur que la source et qu’un objet arriverait dans sa propre base, Migrer reste désactivé et un avertissement explique pourquoi : avec Remplacer à destination, la copie supprimerait l’original avant d’en lire les lignes.

> Si le serveur dont vous avez besoin n’apparaît pas dans le sélecteur, ajoutez-le d’abord dans le Gestionnaire de connexions et rouvrez Migration de données.

Mots-clés : migrer, migration, copier, déplacer, serveur cible, connexion cible, sélecteur

Prévisualiser le SQL de migration

Examinez le SQL qui serait exécuté avant de migrer.

Où le trouver : Migration de données › Aperçu

Cochez Aperçu et le bouton devient Générer le SQL : au lieu d’exécuter quoi que ce soit, Calíope écrit dans le panneau de sortie le SQL que la migration exécuterait, pour que vous puissiez le vérifier ou le copier. C’est le même script que celui de la migration : CREATE DATABASE IF NOT EXISTS, le passage à cette base, les clés étrangères désactivées avec Ignorer les vérifications FK, avec Remplacer à destination, d’abord le DROP de tout ce qui est coché —ce qui dépend des tables, puis les tables filles avant leurs mères—, ensuite chaque objet, et les INSERT avec Exporter les données. Les routines et les triggers sont placés entre DELIMITER // et DELIMITER ;, donc le script s’exécute aussi tel quel dans l’Éditeur SQL avec Exécuter le script. En mode Aperçu, aucune connexion à la destination n’est nécessaire.

Les clés étrangères viennent à la fin, après toutes les tables et leurs lignes.

SQL Server

Dans SQL Server, le script crée la base et le schéma s'ils manquent (IF DB_ID(…) IS NULL), n'a pas de DELIMITER —chaque routine va dans son propre EXEC— et les lignes avec une valeur d'identité vont entre SET IDENTITY_INSERT … ON et OFF.

PostgreSQL

Dans PostgreSQL, le script crée le schéma s’il manque (CREATE SCHEMA IF NOT EXISTS), désactive les clés étrangères avec SET session_replication_role, crée avant les tables les types qu’elles utilisent, et n’a pas de DELIMITER : le corps d’une fonction va entre guillemets $function$ .

Mots-clés : aperçu, preview, SQL preview, vérifier avant d'exécuter