Avant de commencer
Avant de commencer la migration des ressources et des applications, prenez en compte les options de migration, puis provisionnez et migrez les bases de données d'application nécessaires.
Vous pouvez fournir les infos de paramétrage des bases de données d'application en tant que bases de données distinctes ou en tant que bases de données pluggables au sein de la base de données Conteneur d'un système de base de données unique.
Oracle Grid Infrastructure (qui prend en charge les bases de données multinoeuds) ou Logical Volume Manager sont pris en charge.
Remarque :
Pour utiliser des outils de migration de base de données tels que ZDM (Zero Downtime Migration), le mot de passe SYS de base de données cible doit être identique au mot de passe SYS de la base de données source à migrer.Plusieurs stratégies de migration sont disponibles en fonction de la complexité de la charge de travail et des exigences liées au temps d'inactivité.
Pour plus d'informations sur la fourniture d'infos de paramétrage d'une base de données, reportez-vous à Fournir les infos de paramétrage d'une base de données de machine virtuelle dans ce document.
A propos de la migration des charges globales
Cette section présente un certain nombre de scénarios de migration courants.
Un ensemble d'options migre les charges de travail sur site vers un domaine nouvellement créé sur Oracle Cloud Infrastructure :
- Migrez manuellement les charges de travail à l'aide de la console d'administration WebLogic pour déployer les ressources et l'une des méthodes suivantes pour déployer les applications :
- Console d'administration WebLogic
- outils de déploiement JDeveloper
- Migrez les charges de travail à l'aide de la fonction WLDT (WebLogic Deploy Tooling).
- Migrez les charges de travail à l'aide de l'outil de script WebLogic en ciblant les scripts de déploiement d'application existants sur le nouveau domaine.
Vous pouvez également mettre à jour les outils WebLogic Server que vous utilisez pour déployer des domaines sur des locaux (tels que des scripts WebLogic ou des fichiers de modèle de déploiement WebLogic) et les cibler sur Oracle Cloud Infrastructure afin de créer un domaine et de redéployer des applications.
Migrer des bases de données Oracle vers Oracle Cloud Infrastructure
Avant de migrer des bases de données Oracle ou non-Oracle d'un centre de données on-premise vers Oracle Cloud Infrastructure, passez en revue les remarques, les prérequis et le processus d'évaluation suivants.
Remarques
Cette section s'applique à la migration de bases de données Oracle sur site vers Oracle Cloud Infrastructure, qui inclut les plates-formes de base de données répertoriées dans la section précédente. Avant de lancer toute migration, vous devez comprendre la charge de travail de la base de données, les restrictions et les dépendances éventuelles.
- Quelle est la version en cours de cette base de données ?
- Combien de bases de données de cette version seront migrées ?
- Combien de bases de données sont liées à une ligne d'activité spécifique (LOB) ?
- Toutes les bases de données présentes sur des plates-formes autres que Linux, c'est-à-dire existe-t-il des migrations cross-endianness ?
- Des bases de données dépendantes doivent-elles être migrées en même temps ?
- Existe-t-il des bases de données tierces (autres qu'Oracle) à migrer et quelles versions (par exemple, SQL Server 2016) ?
- Pour les bases de données de test et de développement, toutes les copies seront migrées ou simplement la copie maître ?
- Quelle est la taille totale des bases de données (espace disque total et espace) pour les données elles-mêmes en Go/To?
- Utilisez-vous FastConnect ou VPN pour la connectivité réseau à Oracle Cloud? La bande passante et la taille de la base de données permettront principalement d'identifier la solution de migration.
Options de migration
Il existe de nombreuses méthodes de migration de bases de données Oracle d'un environnement sur site vers Oracle Cloud Infrastructure. Chaque méthode dépend de l'objectif de point de récupération d'entreprise (RPO), de l'objectif de temps de récupération (RTO, recovery time objective) et du contrat de niveau de service de disponibilité global (SLA). Les administrateurs de migration doivent évaluer et mapper ces accords avec les méthodes appropriées.
Oracle Maximum Availability Architecture (MAA) traite en particulier ces options et méthodes. La section suivante traite brièvement ces sujets.
| Solution | Complexité | Degré de finesse de la migration | Type de migration (physique ou logique) | Effort de déploiement global | Modèle de migration | Cas d'emploi de la migration de clés |
|---|---|---|---|---|---|---|
| Export et import conventionnels Data Pump | Faible | Moyenne | Logique | Elevée | En ligne/point dans le temps |
|
| Data Pump saturé transportable | Moyenne | Faible | Physique | Moyenne | En ligne/continu
Exige que la source soit en lecture seule lors de l'export |
Base de données complète avec le même format endian (exige la version Oracle Database source 11.2.0.3) |
| Tablespace transportable Data Pump | Moyenne | Faible | Physique | Moyenne | En ligne/continu | Ensemble de tablespaces de schéma (exige la version Oracle Database source 11.2.0.3) |
| SQL*Loader ; | Faible | Elevée | Logique | Elevée | Hors ligne | Migrer des tables ou des schémas spécifiques |
| GoldenGate | Elevée | Elevée | Logique | Elevée | Hors ligne/Continu |
|
| Sauvegarde et restauration RMAN | Faible | Faible | Physique | Faible | Hors ligne/Continu | Base de données complète ou ensemble de tablespaces |
| Data Guard | Faible | Faible | Physique | Faible | En ligne/continu | Base de données complète avec aucun temps d'inactivité ou quasiment nul |
|
Clonage distant de base de données pluggable Clonage distant Transfert de base de données pluggable Migration de base de données pluggable |
Faible | Faible | Physique | Faible | En ligne/continu |
|
Remarque :
De nombreuses solutions peuvent être combinées pour créer la stratégie de migration la plus efficace. Certaines applications packagées peuvent comporter des restrictions sur les outils pris en charge pour la migration.Dimensionnement et déploiement Planning
Remarque :
L'effort de dimensionnement de capacité pour la base de données et la machine virtuelle est identique aux locaux.- Exigences de performances de la charge globale
- Transactions par seconde
- Nombre de connexions utilisateur
- Modifications futures de charge globale attendues
- Exigences en matière de capacité
- vCPUs
- Mémoire
- Capacité de stockage et d'E/S
- Augmentation future
- Gestion requise
- Services natifs et accessibilité d'Oracle Cloud Infrastructure
- Outils de surveillance
- Solutions de sauvegarde
- Fonctions d'évolutivité
- Echelle de base de données
- Echelle de la machine virtuelle
- Echelle de cluster
- Exigences de disponibilité
- Solutions Oracle High Availability
- vMotion, DRS
- Exigences relatives aux applications
- Dépendances entre les composants sur site
- Flux réseau entre les applications et les services Oracle Cloud Infrastructure
Rationalisation, standardisation et consolidation
Dans le cadre de l'effort de migration, nous recommandons à l'équipe de migration d'utiliser cette opportunité pour standardiser la version de la base de données et consolider les systèmes de base de données, le cas échéant. Oracle Database 19c doit être une version de base de données standardisée minimale car il fournit la version de prise en charge à long terme.
La consolidation est l'une des stratégies majeures que les organisations cherchent à atteindre pour améliorer l'efficacité de leurs opérations. La consolidation permet aux organisations d'augmenter l'utilisation des ressources informatiques, ce qui réduit les coûts car un nombre moindre de ressources est nécessaire pour atteindre le même résultat. Les coûts d'exploitation sont également réduits car un nombre inférieur de composants et d'objets doivent être surveillés, gérés et gérés.
Les administrateurs et DBA doivent rechercher la meilleure opportunité de consolider autant de bases de données que possible. Avec Oracle 19c, vous pouvez utiliser l'option d'architecture colocative Oracle avec un maximum de trois bases de données pluggables (PDB). Cette méthode fournit des économies d'échelle plus importantes et des densités de consolidation plus élevées sont possibles avec la modernisation de l'application et de la base de données. Par conséquent, vous devez déterminer les bases de données qui tiendraient dans le modèle de déploiement de la base de données Conteneur (CDB).
Tout comme la consolidation, la gestion de l'isolement est prise en compte. Les critères d'isolement peuvent influencer la méthode ou le degré de consolidation possible. Le niveau d'isolement requis par le système détermine si vous consolidez plusieurs bases de données pluggables dans une seule base de données, si vous hébergez plusieurs bases de données sur une seule plate-forme ou si vous utilisez une combinaison des deux approches. L'isolement peut être classé en quatre zones : erreur, ressource, sécurité et opérationnel. Chaque modèle de cloud gère l'isolement de manière légèrement différente, à l'aide des fonctionnalités intégrées du système d'exploitation ou de la base de données, souvent combinés à des fonctionnalités ou produits avancés pour fournir une solution complète, permettant de commenter le risque.