Migrer des données d'Oracle® vers Cloud SQL pour MySQL

Ce document fait partie d'une série qui explique comment migrer des données d'Oracle vers Cloud SQL pour MySQL. Les documents suivants de la série expliquent les concepts de manière plus détaillée :

Préparer la migration des données

Cette section explique comment migrer des données d'Oracle vers Cloud SQL pour MySQL. Les prérequis suivants sont essentiels pour éviter les problèmes lors de la migration à chaud :

  • La conversion de schéma d'Oracle vers Cloud SQL pour MySQL a été effectuée pour tous les objets de la base de données, y compris les tables, les vues, les procédures stockées et les fonctions.
  • Le schéma cible a été testé avec des exemples de données pour s'assurer qu'il peut contenir les mêmes données que le schéma source.

Il existe deux méthodes de base pour la migration des données : le chargement ponctuel et la réplication en temps réel. La méthode de chargement ponctuel consiste à exporter les données existantes d'Oracle et à les importer dans MySQL. La méthode de réplication en temps réel signifie que les données sont immédiatement copiées à partir d'Oracle vers MySQL lors de leur génération.

Avec la méthode de chargement ponctuel, la base de données source ne doit être ouverte que pour les écritures lors ce processus. Par conséquent, cette méthode est également appelée migration de données hors connexion. L'un des outils les plus courants pour exporter des données depuis Oracle est Oracle SQL Developer. Cet outil peut exporter les données à partir de tables Oracle dans de nombreux formats, y compris les instructions d'insertion CSV et SQL. Vous pouvez également utiliser SQL*Plus pour sélectionner et formater vos données, puis les spouler dans un fichier. Lorsque les données ont été exportées depuis Oracle vers un fichier plat, vous pouvez les charger dans MySQL à l'aide de la commande LOAD DATA INFILE. Cette méthode est souvent la méthode de migration la moins coûteuse, mais elle peut nécessiter une intervention manuelle plus importante et s'avérer plus lente qu'un outil de migration. Elle entraîne également un temps d'arrêt de l'application pendant la migration.

En revanche, la méthode de réplication en temps réel, également appelée capture de données modifiées, est une méthode de migration de données en ligne. Pendant la copie initiale des données, la base de données source reste ouverte. Un produit de réplication capture les modifications de données à mesure qu'elles se produisent sur la base de données source, puis les transfère et les applique sur la base de données cible. Pour les migrations de données de production, cette méthode permet de minimiser le temps d'arrêt requis et de garantir un temps d'arrêt quasiment nul avant le basculement. Cette méthode implique l'utilisation d'un produit tiers de capture de données modifiées tel que GoldenGate, Striim ou la réplication des données d'Informatica.

Pour autoriser la capture de données modifiées d'Oracle en tant que base de données source, nous vous recommandons d'activer la journalisation supplémentaire au niveau de la base de données, à l'aide de la commande suivante :

SQL> ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;

Database altered.

Cette commande force les fichiers journaux de rétablissement à enregistrer des données de colonne supplémentaires en plus de la clé primaire habituelle ou des colonnes d'index uniques.

Vous pouvez utiliser un produit tiers de capture de données modifiées pour le chargement initial, en transférant toutes les données existantes (jusqu'à plusieurs téraoctets de données) à partir de l'environnement de base de données Oracle, ainsi que pour capturer toutes les modifications de données en cours jusqu'à ce que les deux environnements soient synchronisés, avant d'effectuer le basculement entre les deux plates-formes. Un produit de capture de données modifiées fournit généralement des fonctionnalités supplémentaires, telles que des conversions de type de données et d'autres transformations simples.

Effectuer la migration des données

Lors de la migration des données, suivez ces instructions. La plupart s'appliquent aux méthodes de chargement ponctuel et de réplication en temps réel :

  • Ensembles de caractères : assurez-vous que le jeu de caractères de la base de données Oracle source est compatible avec celui de la base de données MySQL cible.
  • Clés étrangères : pour accélérer l'ingestion, désactivez temporairement les contraintes de clé étrangères sur la base de données MySQL cible. Une fois le chargement terminé, activez les contraintes de clé étrangère.
  • Index : de même que pour les clés étrangères, les index de la base de données MySQL cible peuvent considérablement ralentir le chargement initial. Assurez-vous que les index ne sont pas créés sur la base de données cible tant que le chargement initial n'est pas terminé.
  • Séquences Oracle : MySQL accepte AUTO_INCREMENT plutôt que des séquences. Assurez-vous que les attributs AUTO_INCREMENT sont désactivés lors du chargement initial afin d'éviter d'écraser les valeurs générées par les séquences Oracle. Ajoutez l'attribut AUTO_INCREMENT à la colonne de clé primaire une fois le chargement initial terminé.
  • Connectivité réseau : si vous utilisez la capture de données modifiées, assurez-vous que les environnements source et cible peuvent établir une connexion réseau au produit de capture de données modifiées. Cela permet à la capture de données d'être effectuée sur Oracle et au chargement de données d'être effectué sur Cloud SQL pour MySQL.

Cas d'utilisation de GoldenGate

Cette section examine en détail une migration en ligne vers Cloud SQL effectuée avec GoldenGate, l'offre de capture de données modifiées d'Oracle. La première étape consiste à préparer l'environnement pour GoldenGate en installant GoldenGate sur les systèmes source et cible. Du côté source, vous pouvez installer l'application sur le serveur Oracle ou sur un serveur distant qui se connecte à la base de données Oracle via une connexion SQL*Net. Du côté cible, vous devez utiliser une VM de préproduction sur Google Cloud pour exécuter l'application GoldenGate, car vous ne pouvez pas installer GoldenGate directement sur la machine Cloud SQL. GoldenGate est livré avec un utilitaire de ligne de commande nommé GGSCI qui vous permet de configurer et d'exécuter divers processus GoldenGate.

Une fois l'environnement configuré, vous configurez et ajoutez le processus EXTRACT pour capturer les modifications de données. Nous procédons de cette façon avant le début du chargement initial des données afin d'éviter la perte de toute modification transactionnelle pendant que le chargement est en cours. Comme indiqué précédemment, la capture de données modifiées nécessite l'activation de la journalisation supplémentaire sur la base de données Oracle source. Les transactions validées sont capturées à partir des journaux de rétablissement, converties en enregistrements logical change records (LCRs), puis écrites dans des fichiers de trace en local et dans la zone de préproduction distante (VM Google Cloud). Vous devez déterminer comment dimensionner les fichiers de trace pour qu'ils soient conservés suffisamment longtemps sans consommer l'intégralité de l'espace disque disponible.

L'étape suivante consiste à configurer le processus de capture GoldenGate appelé EXTRACT pour exécuter le chargement initial des données. Cela inclut la création d'un fichier de paramètre qui spécifie une liste de mappages entre les tables sources dans Oracle et les tables cibles dans MySQL (par exemple, MAP schema/table to TARGET database.table). Contrairement au processus de capture de données modifiées, le chargement initial utilise les tables sources et non les journaux de rétablissement pour obtenir les données sources. Nous exécutons le processus de chargement initial en démarrant le processus EXTRACT et en vérifiant les résultats. La durée du chargement initial dépendra du volume de vos données et du débit du réseau.

Une fois le chargement initial des données terminé, vous configurez la diffusion des modifications, c'est-à-dire l'application de LCRs à la base de données MySQL cible. Le processus REPLICAT lit ces enregistrements à partir des fichiers de trace distants, les convertit en instructions LMD et LDD, et les applique à la base de données MySQL cible. Le processus REPLICAT dispose de son propre fichier de paramètres, qui comprend une section sur la gestion des conflits et d'autres exceptions.

La méthode la plus simple pour déterminer si la réplication de données fonctionne est d'exécuter un nombre de lignes sur une table source et de comparer les résultats à sa table cible. GGSCI dispose d'une commande permettant de consulter les statistiques et les erreurs de réplication.

Critères de réussite

La migration des données (hors connexion ou en ligne) ne doit être considérée comme réussie que si les critères suivants sont remplis :

  • Des transferts de données se sont produits sans erreur ni échec de traitement.
  • Si vous utilisez un chargement ponctuel, la durée du chargement n'a pas dépassé l'intervalle d'arrêt autorisé de votre entreprise.
  • Si vous utilisez le processus de capture de données modifiées, les utilisateurs de votre application n'ont pas observé de perte de performances lors du chargement initial.
  • Si vous utilisez le processus de capture de données modifiées, le délai de réplication est réduit au fil du temps, de sorte que la base de données cible rattrape la base de données source.

Vérifier l'intégrité des données après la migration

Au cours de cette phase, vous souhaitez identifier les problèmes et incohérences avec l'environnement MySQL cible afin de pouvoir résoudre rapidement les écarts entre les données. Procédez comme suit :

  1. Comparez le nombre de lignes entre les tables de la base de données source et cible afin d'identifier les écarts. Outre l'exécution de count, exécutez également sum, avg, min et max sur le même ensemble de tables.
  2. Exécutez des instructions SQL fréquemment utilisées sur l'environnement MySQL cible pour vous assurer que les données correspondent à la base de données Oracle source.
  3. Connectez l'application aux bases de données source et cible, et vérifiez que les résultats correspondent.

Étape suivante