Le Blog Amazon Web Services
Amazon RDS for Oracle – Partie 2 : Migration de données
Oracle occupe une position dominante dans le paysage des bases de données relationnelles depuis des décennies. Cette prédominance historique crée des défis spécifiques lorsque les organisations souhaitent migrer leurs bases de données Oracle vers Amazon Web Services (AWS).
Nous vous proposons une série de 4 blog posts qui répondent aux questions suivantes :
- Comment gérer votre projet de migration ?
- Quels sont les outils pour migrer vos données ?
- Comment opérer vos bases de données ?
- Comment moderniser votre base de données ?
Le précédent blog post nous a permit de déterminer notre cible de migration, il ne vous reste plus qu’à migrer vos données. Différentes solutions techniques pour pouvoir migrer d’une base de données Oracle, ou d’ailleurs non-Oracle, vers Amazon Relational Database Service (RDS) .Nous allons d’abord traiter les migrations vers Amazon RDS à partir d’une base de données cible Oracle. Puis nous finirons avec un cas moins courant : la migration hétérogène vers RDS.
Migration homogène
Vous avez une base de données Oracle On-premise et vous avez décidé de migrer vers RDS. Vous avez, durant votre phase d’Assessment vérifié que vous étiez conforme aux prérequis RDS pour Oracle. Se pose maintenant la question de savoir comment vous allez migrer vos données.
Nous avons des solutions physiques et logiques pour migrer et nos patterns de migration peuvent être « One Step », « Two Steps » ou « Continous replication ».
Quelques rappels de définitions avant de pouvoir avancer sur le choix :
- La migration « One Step » consiste à arrêter l’application, migrer la base de données en une seule opération et relancer l’application en pointant sur la base Amazon RDS.
- La migration « Two Steps» s’effectue en plusieurs itérations avec une sauvegarde complète suivie d’une ou plusieurs sauvegardes incrémentales.
- La réplication continue (« Continuous replication») réplique les données en temps réel sans attendre qu’une sauvegarde soit effectuée et restaurée.
- Une migration physique : Nous allons reproduire la base de données physiquement chez AWS : Identique au bloc près. De plus il n’y a pas d’effort d’acquisition de connaissances à faire, car les outils utilisés sont des outils natifs d’Oracle que les équipes utilisent déjà.
- Une migration logique : Cela peut demander des outils en plus de ceux fournis par Oracle, qui parfois nécessiteront du licensing. Une migration logique est plus sensible en termes de cohérence mais également en termes de performances (Nous réorganisons la base de données). Une phase de tests de non-régression stricte est nécessaire.
Migration Physique
Cette partie Amazon RDS ne permet pas l’accès au serveur ni à la base de données avec un compte SYSDBA. Ce principe exclut l’utilisation de RMAN et des bases de données de secours physiques. L’option de migration physique disponible utilise les tablespaces transportables
Tablespace Transportable :
L’option de migration physique recommandée est l’utilisation des tablespaces transportables.
Cette solution va consister en la copie physique d’un ensemble de tablespaces d’une base de données Oracle (On premise ou sur EC2), vers une base de données sur RDS Oracle.
En plus des avantages liés à une migration physique, elle présente d’autres avantages :
- Nous pouvons effectuer une migration « One step », et également « Two steps ». Il est possible de faire des sauvegardes incrémentales avec les tablespaces Transportables.
- Nous pouvons également utiliser cette solution pour revoir la répartition de vos schémas applicatifs lors de cette migration (Consolidation sur une base ou à l’inverse, éclatement des schémas sur plusieurs bases).
Cette solution a certaines limitations et prérequis qu’il convient de vérifier, notamment l’indian de la base de données, le characterSet, le tablespace name …
Vous trouverez toutes ces informations ici : https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/oracle-migrating-tts.html
Solutions de Migration Logique:
Datapump :
Oracle Data Pump constitue la première solution de migration logique One Step.
https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Oracle.Procedural.Importing.DataPump.html
Cette solution « One Step » va dumper la base de données dans un fichier externe que vous allez pouvoir importer dans votre base de données RDS Oracle. Les limitations et prérequis sont les mêmes que pour une utilisation classique de Datapump
La solution export/import, prédécesseur de Data Pump, reste disponible bien qu’elle ne soit plus supportée depuis la version 11g. Elle peut s’avérer utile lors de migration d’anciennes bases version 9i et antérieures, comme expliqué dans la documentation suivante.
https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Oracle.Procedural.Importing.ExportImport.html
Réplication de données :
Ici nous sommes dans le cadre d’une réplication de données via un outil tiers. Nous aborderons deux outils : Oracle Golden Gate et AWS Database Migration Service (DMS).
Oracle GoldenGate est un produit logiciel qui vous permet de répliquer, filtrer et transformer des données d’une base de données vers une autre bases de données.
https://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/UserGuide/Appendix.OracleGoldenGate.html
Il est possible de faire un chargement complet (Initial Load) des données vers une base de données cible, de manière consistante.
Il est aussi possible de répliquer les données au fil de l’eau (change replication) d’une base de données à une autre.
Et bien entendu, il est possible de coupler les deux modes dans le cadre d’une migration vers RDS d’Oracle. Nous pouvons charger les données de manière consistante (Initial Load), puis enclencher une réplication au fil de l’eau, les deux opérations se basant sur le SCN (« séquence Change Number »).
AWS Database Migration Service :
AWS Database Migration Service (AWS DMS) est un service cloud permettant la migration de données d’une base de données source vers une base de données cible, ces deux bases étant appelées « points de terminaison ». Vous pouvez effectuer des migrations entre des points de terminaison source et cible utilisant le même moteur de base de données, ce que l’on appelle une migration homogène, comme par exemple d’une base de données Oracle vers une autre base de données Oracle. Vous pouvez également effectuer des migrations entre des points de terminaison utilisant des moteurs de base de données différents, ce que l’on appelle des migrations hétérogènes, comme par exemple d’une base de données Oracle vers une base de données PostgreSQL dans le cadre d’une modernisation.
La seule exigence pour utiliser AWS DMS est que l’un des points de terminaison soit hébergé sur un service AWS. Vous pouvez effectuer un chargement complet de votre base de données (Full Load), une réplication continue (on-going replication), ou combiner les deux modes (Full Load suivi d’une réplication continue).
En plus de la licence nécessaire pour Golden Gate, vous pouvez retrouver une comparaison entre les deux produits : https://broadcast.amazon.com/videos/317815
Ajoutés aux avantages des solutions logiques de migration, GoldenGate et AWS DMS vont présenter trois avantages :
- Nous allons pouvoir tirer bénéfice de cette occasion pour purger / transformer / réorganiser les données avant insertion. Cette réorganisation peut également être un moyen de diminuer la taille de votre base
- On a une base de données ouverte et répliquée, qui peut servir de test de non-régression avant la migration vers RDS.
- Le flux est bidirectionnel, il est donc possible de rediriger le flux vers la base on-premise post-migration et donc d’avoir ainsi soit une solution de PRA, soit une solution pour un éventuel rollback.
Mais la migration logique présente une contrainte forte qui est la composante tests de non-régression. En effet, la migration logique réorganise vos données, reconstruit vos index, modifie vos statistiques et donc peut influer sur les plans d’exécution et sur la performance.
Il est donc important d’avoir une phase de tests de non-régression très approfondie. Le dernier outil disponible pour migrer vos données est SQL*Loader :
https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Oracle.Procedural.Importing.SQLLoader.html
Cette solution, limitée à des uses cases qui n’ont pas beaucoup de données, avec très peu de modification, est souvent écartée ; d’autant plus lorsque nous devons gérer la création des segments indépendamment.
Le choix de votre pattern de migration ainsi que de la solution est dictée par :
- Le temps d’interruption de service acceptable pour cette migration
- Les prérequis et limitations de chaque solution
Migration hétérogène
Lors d’une migration hétérogène vers RDS Oracle (Migration d’une base de données autre qu’Oracle vers RDS Oracle), seule la migration logique est disponible. Mais toutes les solutions que nous avons vues précédemment ne sont pas disponibles.
Par exemple, Datapump ne peut être utilisé que sur des bases source et cible Oracle.
Il nous reste donc la possibilité d’effectuer cette migration via les outils de réplication de données et qui acceptent le moteur de base de données pour votre base source.
- Golden Gate : https://docs.oracle.com/en/cloud/paas/goldengate-service/wxntz/index.html#GUID-16ACC5AF-8474-4E86-965D-D9AE14A45D70
Là aussi, il faut vérifier que les limitations et les prérequis avec l’outil sont compatibles avec votre use case : Par exemple, si votre base de données source est du PostgreSQL et que vous souhaitez migrer vos données via GoldenGate :
https://docs.oracle.com/en/middleware/goldengate/core/19.1/gghdb/understanding-whats-supported-postgresql.html#GUID-E0104CC8-0FB4-4490-B2EE-CB3B33F562CE
Ou alors la seconde solution, concerne surtout des uses cases ayant une volumétrie plus faible et peu évolutive. Il est en effet possible d’exporter les données sur des fichiers plats et de les réinsérer via SQL Loader.
https://docs.oracle.com/en/database/oracle/oracle-database/23/sutil/oracle-sql-loader.html
Cela peut s’avérer pertinent dans le cas de bases de données réglementaires ayant peu de modifications de données.
Migration Best practices
Vous avez déterminé, quel serait votre pattern de migration ainsi que l’outil. Avant de vous lancer dans une migration, voici quelques conseils, non exhaustifs, pour vous aider à effectuer une bonne migration :
- « Right-Sizing » durant le processus de migration (Server et Stockage) : La migration, surtout le chargement complet de la base de données, n’est pas une activité classique de la base de données. Il y a une activité très importante de lecture et d’écriture en base. Afin d’éviter tout goulot d’étranglement, il peut être pertinent d’augmenter la configuration serveur : Choisir une classe d’instance supérieure et le stockage (augmenter les IOPS).
- L’espace disque provisionné doit être déterminé en fonction de la taille post-migration des données. Il faut ajouter à cet espace, le fait de stocker temporairement les fichiers dumps (pour Datapump) et les fichiers (Transportable tablespace).
- Eviter la contention : Comme nous venons de le dire, la migration pouvant être consommatrice de ressources sur la base source et cible, nous vous invitons à effectuer cette opération de migration hors des périodes de fortes charges sur la cible.
Sur la base cible, là aussi une configuration temporaire peut être mise en place lors d’un chargement important de données :
-
- Mode NoArchivelog
- Ne pas avoir de Sauvegarde durant l’initial load
- Le chargement des données se fait en single-AZ
- Comprendre sa migration : Une migration réussie est souvent due à de multiples exercices de migration (notamment pour les migrations one/two steps). Plus vous vous exercerez, plus vous ferez face aux différents challenges.
Amazon Cloud Watch Database Insight sera également un allié dans votre recherche des causes de ralentissement lors d’un chargement important de données :
https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Database-Insights.html
- La migration est également une occasion pour migrer en multitenant, afin de pouvoir rationaliser les ressources et les licences :
https://aws.amazon.com/blogs/database/get-started-with-the-multi-tenant-feature-of-amazon-rds-for-oracle/
Une fois votre migration terminée et avant d’ouvrir le service aux utilisateurs, il convient de garder en tête quelques recommandations, là aussi c’est une liste non exhaustive.
- Votre base est en production : première chose à faire, Activez donc le logging et les sauvegardes.
- Si vous aviez mis en place une configuration serveur et stockage spécifique pour la migration, revenez à une configuration plus en adéquation avec votre load.
- En fonction des critères SLA (Service-Level Agrement) de votre application, déterminez quelle est la meilleure solution pour votre PRA et implémentez-la : Multi-AZ, Read Replicat, Read Replicat cross Region
- Supprimez toutes les opérations spécifiques à la migration sur votre base de données : Création d’utilisateurs uniquement pour la migration, élévation de privilèges …)
Conclusion
Nous venons de passer en revue les différentes méthodes pour migrer vos données sont migrées. Cette étape primordiale est peut varier en fonction de la possibilité d’interruption de service de votre applicatif, ainsi que l’état de votre base source & cible.
Une fois que votre base de données a été migrée nous verrons dans le prochain article comment nous devons les opérer dans RDS Oracle, et notamment comment se débarrasser des opérations fastidieuses pour celles à plus forte valeur ajoutée.