Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Phase 1 : Préparation
Pendant la phase de préparation, évaluez votre base de données existante et identifiez ses dépendances. Les sections suivantes présentent les principaux éléments à évaluer avant de planifier la migration.
Analyse des dépendances
Lors de la préparation de la migration vers Oracle, identifiez les interdépendances et leur impact sur les applications d'interfaçage. Répondez aux premières questions suivantes :
-
Contrôle de dépendance : identifiez les applications qui se connectent directement à la base de données. Pour éviter tout problème de latence, nous vous recommandons de migrer les applications en même temps que la base de données. Pour les applications qui accèdent aux données indirectement par le biais d'une API, identifiez l'impact sur les performances et les temps d'arrêt nécessaires à la migration.
-
Accès à d'autres bases de données : Oracle Database fournit un mécanisme permettant d'accéder aux données d'une autre base de données via un réseau à l'aide d'un lien de base de données
. Le lien de base de données vous permet de lire et d'écrire dans les tables d'une base de données distante. Par exemple, une application de reporting peut extraire des données d'une base de données centralisée qui utilise des liens de base de données pour extraire des données d'autres bases de données de la même unité commerciale. Il est important d'identifier toutes ces connexions et de recréer les liens de base de données après la migration. -
Tâches externes — Parfois, les tâches de base de données sont planifiées et contrôlées en dehors de la base de données. Pour éviter tout impact en aval, assurez-vous que ces tâches continuent de s'exécuter pendant la migration de la base de données.
-
Dépendances liées aux centres de données — Au cours de la migration, il peut arriver que certains de vos systèmes soient dans le cloud alors que d'autres se trouvent toujours dans le centre de données sur site. La latence du réseau joue un rôle important dans ces configurations. Décidez si vous souhaitez migrer ensemble les applications et les bases de données sensibles à la latence, ou si vous souhaitez transférer les fonctionnalités vers la base de données en cours de migration. Dans les deux cas, nous vous recommandons de migrer vos applications vers la même zone de disponibilité que votre base de données migrée afin d'éviter toute latence réseau.
-
Accès à l'hôte : certaines applications créent des rapports qui sont stockés dans un système de fichiers sur un serveur de base de données. Lorsque vous migrez votre base de données, vous pouvez également décider de moderniser la génération de vos rapports en les enregistrant dans un stockage cloud natif. En fonction de la complexité de la modification de la génération de rapports, vous pouvez décider d'utiliser Amazon EC2
, Amazon RDS ou Amazon RDS Custom comme cible pour la base de données Oracle. -
Options, fonctionnalités et exigences spécifiques à la base de données : passez en revue les fonctionnalités de base de données Oracle que vous utilisez et vos besoins après la migration. L'utilisation des fonctionnalités et les besoins après la migration permettent de déterminer la configuration de la base de données dans le cloud. Des correctifs ponctuels dans la base de données Oracle source peuvent nécessiter la migration de votre base de données vers Amazon RDS Custom ou une instance. EC2
Exigences relatives à la disponibilité
En fonction des besoins de l'entreprise, certaines bases de données doivent être opérationnelles toute la journée, tous les jours. D'autres bases de données peuvent entraîner des interruptions de service après les heures de bureau ou le week-end. Lors de la phase de préparation de la planification de la migration, il est important de comprendre l'impact commercial des interruptions de service des bases de données et de choisir la stratégie de migration appropriée. Par exemple, la migration en ligne entraîne un temps d'arrêt minimal, tandis que la migration hors ligne implique une période d'indisponibilité plus longue.
Analyse de charge de travail
Comprendre la nature de la charge de travail de votre base de données vous aide à déterminer votre stratégie de migration de base de données. Le créneau de migration et les éventuelles interruptions de service nécessaires dépendent de la charge de travail. Les charges de travail peuvent être très transactionnelles ou se composer principalement de tâches par lots et de rapports. Pour vous aider à planifier et à élaborer votre stratégie de migration, identifiez où se situe votre charge de travail dans ce spectre.
Des outils sont disponibles pour vous aider à qualifier la charge de travail de votre base de données. Les outils que vous pouvez utiliser dépendent de votre licence de base de données Oracle et incluent les suivants :
-
Les métriques de l'hôte, telles que le processeur
, les E/S et la mémoire, vous aident à déterminer les exigences en matière d'instance et de stockage pour vos bases de données dans le cloud. -
Les rapports Oracle tels que Automatic Workload Repository (AWR)
pour Oracle Database Enterprise Edition ou Statspack pour Standard Edition vous aident à déterminer la nature des transactions effectuées dans votre base de données. -
La génération de journaux de rétablissement et d'archivage
vous aide à déterminer le taux de modification de votre base de données.
