Migration vers Oracle Exadata Database Service on Dedicated Infrastructure

Cette section explique comment migrer vos charges de travail Oracle Exadata vers Oracle Exadata Database Service on Dedicated Infrastructure, et comment migrer vos applications VMware vers Oracle Cloud VMware Solution.

Architecture

Cette architecture présente une migration des bases de données Oracle Exadata sur site et des applications VMware vers Oracle Exadata Database Service on Dedicated Infrastructure et Oracle Cloud VMware Solution.

A l'aide d'Oracle Zero Downtime Migration, automatisez la migration de votre base de données tout en subissant un temps d'inactivité minimal lors de la migration de vos données sur site vers le cloud.

Migrez vos applications sur site exécutées sur VMware vers Oracle Cloud VMware Solution à l'aide d'outils VMware tels que HCX et vMotion. Oracle Cloud VMware Solution vous offre une implémentation entièrement automatisée d'un centre de données défini par logiciel (SDDC) VMware dans votre location OCI, exécuté sur des instances Bare Metal OCI.

Le diagramme suivant illustre cette architecture de référence.

Description de l'image migrate-vmware-cloud-solution-exadata-dedicated-architecture.png

Description de l'illustration migrate-vmware-cloud-solution-exadata-dedicated-architecture.png

migrate-vmware-cloud-solution-exadata-dedicated-architecture.zip

Cette architecture prend en charge les composants suivants :

Région
Une région Oracle Cloud Infrastructure est une zone géographique localisée qui contient des centres de données, appelés domaines de disponibilité. Les régions sont indépendantes les unes des autres et de grandes distances peuvent les séparer (dans des pays voire des continents).
Réseau cloud virtuel (VCN) et sous-réseau
Un VCN est un réseau personnalisable défini par logiciel que vous configurez dans une région Oracle Cloud Infrastructure. Comme les réseaux de centre de données traditionnels, les réseaux cloud virtuels vous donnent un contrôle total sur l'environnement réseau. Un réseau cloud virtuel peut comporter plusieurs blocs CIDR qui ne se chevauchent pas et que vous pouvez modifier après l'avoir créé. Vous pouvez segmenter un réseau cloud virtuel en plusieurs sous-réseaux ciblant une région ou un domaine de disponibilité. Chaque sous-réseau est composé d'une plage contiguë d'adresses qui ne chevauchent pas celles des autres sous-réseaux du réseau cloud virtuel. Vous pouvez modifier la taille d'un sous-réseau après sa création. Un sous-réseau peut être public ou privé.
Oracle Exadata Database Service on Dedicated Infrastructure
Oracle Exadata Database Service on Dedicated Infrastructure fournit Oracle Exadata Database Machine en tant que service dans un centre de données OCI. Le service Oracle Exadata Database Service on Dedicated Infrastructure peut héberger de nombreuses bases de données Oracle qui s'exécutent dans des clusters de machines virtuelles qui s'exécutent sur un rack Exadata unique dans une région OCI. Oracle Exadata Database Service on Dedicated Infrastructure est une plate-forme idéale pour la consolidation de bases de données.
Oracle Cloud VMware Solution - Centre de données défini par logiciel (SDDC)
Oracle et VMware se sont associés pour développer une implémentation de centre de données défini par logiciel (SDDC) certifié VMware à utiliser dans Oracle Cloud Infrastructure. Cette implémentation, appelée Oracle Cloud VMware Solution, utilise Oracle Cloud Infrastructure pour héberger un SDDC VMware hautement disponible. Elle permet également une migration transparente de toutes vos charges globales de SDDC VMware sur site vers Oracle Cloud VMware Solution. Oracle Cloud VMware Solution contient les composants VMware suivants :
- VMware vSphere ESXi
- VMware vSAN
- VMware vCenter
- VMware NSX-T
- VMware HCX (facultatif)
Bare Metal
Un centre de données défini par logiciel (SDDC) Oracle Cloud VMware Solution contient des serveurs Bare Metal hébergeant Oracle Cloud VMware Solution. Le serveur Bare Metal prend en charge les applications qui nécessitent un nombre élevé de coeurs, de grandes quantités de mémoire et une bande passante élevée (comme Oracle Cloud VMware Solution). Vous pouvez déployer Oracle Cloud VMware Solution sur des serveurs Bare Metal et configurer des machines virtuelles avec des améliorations significatives des performances par rapport aux autres clouds publics et centres de données sur site.
Passerelle de service
La passerelle de service fournit l'accès d'un VCN à d'autres services, tels qu'Oracle Cloud Infrastructure Object Storage. Le trafic du VCN vers le service Oracle se déplace sur la structure réseau Oracle et ne traverse jamais Internet.
Dynamic routing gateway (DRG)
Le DRG est un routeur virtuel qui fournit un chemin pour le trafic réseau privé entre les réseaux cloud virtuels de la même région, entre un VCN et un réseau en dehors de la région, tel qu'un VCN dans une autre région Oracle Cloud Infrastructure, un réseau sur site ou un réseau dans un autre fournisseur cloud.
FastConnect
Oracle Cloud Infrastructure FastConnect permet de créer facilement une connexion privée dédiée entre le centre de données et Oracle Cloud Infrastructure. FastConnect offre des options de bande passante plus élevée et une expérience réseau plus fiable par rapport aux connexions Internet.
Stockage de fichiers
OCI File Storage est utilisé lors de la migration logique pour importer la base de données migrée à partir d'un système de fichiers partagé.
Stockage d'objets
OCI Object Storage est utilisé pour la migration logique et physique du stockage temporaire pendant la migration.

Avant de commencer

Avant de commencer, vérifiez les versions des principaux composants utilisés dans cette configuration et consultez la documentation du produit pour référence ultérieure.

Vérifier les conditions requises

Assurez-vous que la base de données source exécute Oracle Database version 19.18 Enterprise Edition ou supérieure.
La base de données cible doit être Oracle Exadata Database Service on Dedicated Infrastructure X8 ou une version plus récente, sur Oracle Database version 19.18 Enterprise Edition ou supérieure.
Oracle Zero Downtime Migration doit être version 21.4 ou supérieure.
Le stockage intermédiaire doit inclure OCI Object Storage, Oracle ZFS Storage Appliance (NAS) et OCI File Storage.

Consulter la documentation

Ce guide de solution explique comment migrer les charges de travail de base de données. Reportez-vous à la solution ci-dessous pour savoir comment migrer vos charges de travail VMware. Les ressources supplémentaires sont utiles pour le contexte, les détails et la référence de votre migration de base de données.

Découvrez comment migrer les composants VMware de votre charge globale vers Oracle Cloud VMware Solution.

Migration des charges globales VMware sur site vers le cloud

Consultez les ressources Oracle Zero Downtime Migration :

Vérifiez les ressources de migration physique :

Vérifiez les ressources de migration logique :

Consultez les ressources Oracle Database :

A propos des produits et rôles requis

Cette solution requiert les produits suivants :

Oracle Cloud Infrastructure Identity and Access Management
Calcul OCI
OCI Object Storage
Stockage de fichiers OCI
Oracle Zero Downtime Migration
Oracle Exadata
Oracle Exadata Database Service on Dedicated Infrastructure

Il s'agit des rôles nécessaires pour chaque produit.

Nom du produit : Rôle	Requis pour...
Oracle Cloud Infrastructure Identity and Access Management : `OCI_user`	Créer des jetons d'authentification pour la migration physique Créer des clés d'API pour la migration logique
OCI Compute : `admin`	Créer une instance OCI Compute pour exécuter le logiciel Oracle Zero Downtime Migration
OCI Object Storage : `Storage Admin`	Créer des buckets OCI Object Storage pour la migration logique et physique
Stockage de fichiers OCI : `Storage Admin`	Création d'OCI File Storage pour la migration logique
Oracle Zero Downtime Migration : `opc`	Créez `zdmuser` pour installer et exécuter le logiciel Oracle Zero Downtime Migration.
Oracle Zero Downtime Migration : `zdmuser`	Installation du logiciel Oracle Zero Downtime Migration Exécuter Oracle Zero Downtime Migration
Oracle Exadata : `root/sudoer user`	Monter le partage du système de fichiers réseau à partir du périphérique de stockage connecté au réseau pour exporter la base de données en vue de migrations logiques Activer SSH sans mot de passe à partir de la machine virtuelle Oracle Zero Downtime Migration Exécutez les commandes `sudo` pour installer l'agent logiciel Oracle Zero Downtime Migration. Exécuter des commandes `sudo` pour sauvegarder ou exporter une base de données
Base de données Oracle Exadata : `sys/system`	Sauvegarder les données à l'aide d'Oracle Recovery Manager (RMAN) pour la migration physique Exécuter Data Pump pour exporter la base de données en vue d'une migration logique
Oracle Exadata Database Service on Dedicated Infrastructure : `Database Admin`	Créer une base de données Oracle Exadata Database Service on Dedicated Infrastructure cible
Noeuds de cluster de machines virtuelles Oracle Exadata Database Service on Dedicated Infrastructure : `opc`	Montez le partage de système de fichiers réseau à partir d'OCI File Storage pour importer la base de données pour les migrations logiques. Activer SSH sans mot de passe à partir de la machine virtuelle Oracle Zero Downtime Migration Installation de l'agent logiciel Oracle Zero Downtime Migration Exécutez les commandes `sudo` pour restaurer ou importer la base de données.
Oracle Exadata Database Service on Dedicated Infrastructure Database : `sys/system`	Restaurer des données à l'aide d'Oracle Recovery Manager (RMAN) pour les migrations physiques Exécuter Data Pump pour importer la base de données en vue d'une migration logique

Pour obtenir tout ce dont vous avez besoin, reportez-vous à Produits, solutions et services Oracle.

A propos de la migration logique et physique

Oracle Zero Downtime Migration prend en charge deux types de migration de base de données d'Oracle Exadata vers Oracle Exadata Database Service on Dedicated Infrastructure : migration logique et migration physique.

La migration logique utilise une combinaison d'Oracle Data Pump et d'Oracle GoldenGate, tandis que la migration physique utilise une combinaison d'Oracle Recovery Manager (RMAN) et d'Oracle Data Guard. Le tableau suivant décrit les scénarios dans lesquels une migration logique ou physique doit être utilisée.

Migration logique	Migration physique
Recommandé lorsque quelques bases de données pluggables et/ou schémas sont migrés.	Recommandé lorsque les bases de données complètes sont migrées. Par exemple, les bases de données Conteneur avec toutes les bases de données pluggables, ou la migration et le transfert.
Il est possible de migrer des bases de données pluggables et/ou des schémas sélectifs.	Les bases de données Conteneur seront migrées vers les bases de données Conteneur, et celles-ci seront migrées vers des bases de données non Conteneur.
Le mot de passe `Sys` sur la source et la cible peut être différent. Les noms de base de données entre la source et la cible peuvent être différents.	Le mot de passe `Sys` et le nom de base de données sur la source et la cible doivent être identiques. DB_UNIQUE_NAME sur la source et la cible doit être différent.
Les bases de données peuvent être mises à niveau pendant la migration.	Les bases de données ne peuvent pas être mises à niveau dans le cadre de la migration.

Migration logique

Cette section décrit comment effectuer une migration logique hors ligne. Pour la migration en ligne, reportez-vous à la section Consulter la documentation.

Avant d'effectuer votre migration, tenez compte des points suivants.

La base de données source sur Oracle Exadata n'a pas besoin d'être cryptée. Oracle Zero Downtime Migration chiffre la base de données cible pendant la migration.
Les bases de données source et cible ne doivent pas avoir le même mot de passe sys, le même mot de passe de portefeuille, la même version de base de données, le même nom de base de données et le même niveau de patch.
Oracle Zero Downtime Migration permet de migrer certaines bases de données pluggables (PDB) et/ou schémas vers des bases de données pluggables dans Oracle Exadata Database Service on Dedicated Infrastructure.
Un système de fichiers partagé est requis pour les migrations logiques. Lors de la migration logique, Oracle Zero Downtime Migration n'exporte pas les données directement vers OCI Object Storage. Sur la base de données Exadata source, Oracle Zero Downtime Migration exporte les données vers un système de fichiers partagé (système de fichiers réseau ou Oracle Advanced Cluster File System). Les données exportées sont ensuite téléchargées vers OCI Object Storage. Oracle Zero Downtime Migration déplace ensuite les vidages de données d'OCI Object Storage vers OCI File Storage. Enfin, Oracle Exadata Database Service on Dedicated Infrastructure peut importer les données à partir d'OCI File Storage via un système de fichiers réseau.
Oracle Exadata sur site peut exécuter des bases de données à instance unique et RAC. Oracle Exadata Database Service on Dedicated Infrastructure exécute des bases de données RAC. Lors de la migration de la base de données, Oracle Zero Downtime Migration convertit une instance unique en bases de données RAC si nécessaire.
Dans Oracle Exadata sur site, l'utilisation d'Oracle Transparent Data Encryption pour crypter les bases de données est facultative. Lors de la migration de bases de données d'Exadata vers Oracle Exadata Database Service on Dedicated Infrastructure, la base de données Oracle Exadata Database Service on Dedicated Infrastructure cible sera toujours cryptée.
Les étapes suivantes supposent qu'il existe une connectivité réseau directe entre le centre de données où Oracle Exadata est installé et le réseau cloud virtuel OCI où Oracle Exadata Database Service on Dedicated Infrastructure et la machine virtuelle Oracle Zero Downtime Migration sont configurés (via le VPN FastConnect ou IPSec, comme indiqué dans le diagramme de l'architecture).

Les étapes suivantes décrivent comment effectuer une migration logique hors ligne.

Dans la console OCI, créez une instance de calcul dans le même VCN où la base de données Oracle Exadata Database Service on Dedicated Infrastructure cible sera configurée.
Cette instance de calcul peut être n'importe quelle forme, avec au moins deux OCPU et 16 Go de RAM, exécutant le système d'exploitation Oracle Linux 7.9. Cette machine virtuelle sera utilisée pour exécuter le logiciel Oracle Zero Downtime Migration.
Suivez la documentation d'installation d'Oracle Zero Downtime Migration dans la section Consulter la documentation pour télécharger et installer le logiciel Oracle Zero Downtime Migration 21.4 sur l'instance de calcul OCI.
Exécutez le logiciel Oracle Zero Downtime Migration en tant que zdmuser.
Connectez-vous en tant que zdmuser à l'instance de calcul exécutant le logiciel Oracle Zero Downtime Migration et générez une paire de clés SSH. Activez SSH sans mot de passe du compte zdmuser vers tous les noeuds de la base de données Exadata source (root, privilege-sudoer user) et vers tous les noeuds de cluster de machines virtuelles sur le compte opc user de la base de données Oracle Exadata Database Service on Dedicated Infrastructure cible.
Vérifiez que la machine virtuelle Oracle Zero Downtime Migration peut communiquer avec les hôtes de base de données source à l'aide du nom d'hôte et de l'adresse IP. Vérifiez les points suivants :
- Modifiez le résolveur DNS VCN ou le fichier /etc/hosts dans la machine virtuelle Oracle Zero Downtime Migration si nécessaire.
- Vérifiez qu'une règle de sécurité autorise la machine virtuelle Oracle Zero Downtime Migration à se connecter à la base de données source sur le port de processus d'écoute par défaut 1521 et le port SSH 22.
- Assurez-vous que la machine virtuelle Oracle Zero Downtime Migration peut atteindre les hôtes Oracle Exadata Database Service on Dedicated Infrastructure cible sur le port de processus d'écoute par défaut 1521 et le port SSH 22.
Sur Oracle ZFS Storage Appliance, ou périphérique de stockage connecté au réseau, créez un partage de système de fichiers réseau à utiliser comme espace réservé pour les vidages de données de la base de données pendant la migration.
Montez le partage de système de fichiers réseau sur tous les noeuds de la base de données Exadata.
Assurez-vous que tous les utilisateurs disposent des droits d'accès en lecture, écriture et exécution (rwx). Notez le point de montage.
Dans la console OCI, créez un stockage de fichiers OCI.
Notez la cible de montage, l'export et l'adresse IP. Par défaut, l'adresse IP se trouve sur le réseau de sauvegarde Oracle Exadata Database Service on Dedicated Infrastructure.
Utilisez l'adresse IP et l'export à partir de l'étape 7 pour monter ce stockage de fichiers via le système de fichiers réseau sur tous les noeuds du cluster de machines virtuelles Oracle Exadata Database Service on Dedicated Infrastructure.
Assurez-vous que le réseau cloud virtuel inclut une stratégie de sécurité permettant d'autoriser le protocole de système de fichiers réseau sur le réseau de sauvegarde Oracle Exadata Database Service on Dedicated Infrastructure. Notez le point de montage.
Créez une base de données Oracle Exadata Database Service on Dedicated Infrastructure cible à l'aide de la console OCI ou de l'API REST. Configurez la base de données comme suit :
- La nouvelle base de données cible peut avoir un nom différent de celui de la base de données source.
- La nouvelle base de données peut être une version plus récente que la base de données source.
- Fournissez un mot de passe pour l'utilisateur admin. Notez le mot de passe.
- Ne sélectionnez pas de destination de sauvegarde ou n'activez pas les sauvegardes automatiques lors de la création de la base de données. Ces paramètres peuvent être activés après la migration de la base de données.
Notez l'OCID de base de données après sa création.
Dans la console OCI, créez un bucket OCI Object Storage s'il n'en existe pas déjà un.
Notez l'URL Swift, l'espace de noms Object Storage et le nom du bucket.
Utilisez la console OCI pour créer une clé d'API pour l'utilisateur OCI propriétaire de la base de données Oracle Exadata Database Service on Dedicated Infrastructure cible, ainsi que des droits d'accès permettant de télécharger des données vers le bucket OCI Object Storage créé à l'étape 10.
Notez l'OCID utilisateur, l'OCID de location, l'empreinte digitale et la région OCI. Enregistrez les clés privées et publiques correspondantes dans les fichiers PEM. Cette clé d'API sera utilisée par Oracle Zero Downtime Migration pour se connecter à OCI afin d'obtenir des informations sur la base de données cible pendant la migration de la base de données et de télécharger des dumps de données vers OCI Object Storage.
Copiez les fichiers PEM de l'étape précédente vers la machine virtuelle Oracle Zero Downtime Migration.
Connectez-vous en tant qu'utilisateur sys à la base de données Exadata source pour vous assurer que le paramètre Streams_Pool_Size est défini sur au moins 2G, par exemple :
```
SQL>show parameter streams_pool_size;
SQL>alter system set streams_pool_size=2G scope=both SID=’*’;                  
```
Utilisez le modèle de fichier de réponse de migration logique d'Oracle Zero Downtime Migration inclus avec Zero Downtime Migration pour créer un fichier de réponse pour la migration. Les paramètres de clé sont les suivants :
- TARGETDATABASE_OCID : OCID de la base de données cible Oracle Exadata Database Service on Dedicated Infrastructure.
- MIGRATION_METHOD: OFFLINE_LOGICAL
- DATA_TRANSFER_MEDIUM: OSS
- TARGETDATABASE_ADMINUSERNAME: system
- SOURCEDATABASE_ADMINUSERNAME: system
- SOURCEDATABASE_CONNECTIONDETAILS_HOST : IP/nom d'hôte du premier noeud sur la base de données Exadata source.
- SOURCEDATABASE_CONNECTIONDETAILS_PORT: 1521
- SOURCEDATABASE_CONNECTIONDETAILS_SERVICENAME : nom de service de la base de données pluggable source ou non Conteneur (base de données non Conteneur). Utilisez lsnrctl pour le rechercher.
- OCIAUTHENTICATIONDETAILS_USERPRINCIPAL_TENANTID : OCID de location à partir de l'étape 11.
- OCIAUTHENTICATIONDETAILS_USERPRINCIPAL_USERID : OCID utilisateur de l'étape 11.
- OCIAUTHENTICATIONDETAILS_USERPRINCIPAL_FINGERPRINT : empreinte de l'étape 11.
- OCIAUTHENTICATIONDETAILS_PRIVATEKEYFILE : chemin d'accès au fichier PEM de clé privée sur le serveur Oracle Zero Downtime Migration à partir de l'étape 12.
- OCIAUTHENTICATIONDETAILS_REGIONID : ID de région OCI pour l'utilisateur OCI à partir de l'étape 11.
- TARGETDATABASE_CONNECTIONDETAILS_PORT: 1521
- TARGETDATABASE_CONNECTIONDETAILS_SERVICENAME : nom de service de la base de données pluggable cible dans la base de données cible. Utilisez lsnrctl pour le rechercher.
- SOURCECONTAINERDATABASE_ADMINUSERNAME: system
- SOURCECONTAINERDATABASE_CONNECTIONDETAILS_HOST : IP/nom d'hôte du premier noeud sur la base de données Exadata source.
- SOURCECONTAINERDATABASE_CONNECTIONDETAILS_PORT: 1521
- SOURCECONTAINERDATABASE_CONNECTIONDETAILS_SERVICENAME : nom de service de la base de données Conteneur source dans la base de données Exadata. Utilisez lsnrctl pour le rechercher).
- DATAPUMPSETTINGS_JOBMODE: SCHEMA
- DATAPUMPSETTINGS_FIXINVALIDOBJECTS: TRUE
- DATAPUMPSETTINGS_EXPORTDIRECTORYOBJECT_NAME: mig
- DATAPUMPSETTINGS_EXPORTDIRECTORYOBJECT_PATH : point de montage du système de fichiers réseau à partir de l'étape 6.
- DATAPUMPSETTINGS_IMPORTDIRECTORYOBJECT_NAME: mig.
- DATAPUMPSETTINGS_IMPORTDIRECTORYOBJECT_PATH : point de montage du système de fichiers réseau à partir de l'étape 8.
- DATAPUMPSETTINGS_CREATEAUTHTOKEN: TRUE
- DATAPUMPSETTINGS_DATAPUMPPARAMETERS_IMPORTPARALLELISMDEGREE: 4
- DATAPUMPSETTINGS_DATAPUMPPARAMETERS_EXPORTPARALLELISMDEGREE: 4
- DATAPUMPSETTINGS_DATABUCKET_NAMESPACE : espace de noms OCI Object Storage à partir de l'étape 10.
- DATAPUMPSETTINGS_DATABUCKET_BUCKETNAME : nom de bucket OCI Object Storage à partir de l'étape 10.
- TABLESPACEDETAILS_AUTOCREATE: TRUE
- TABLESPACEDETAILS_USEBIGFILE: TRUE
- TABLESPACEDETAILS_EXTENTSIZEMB: 512
- EXCLUDEOBJECTS-1: owner:PDBADMIN
Exécutez un travail de migration à exécution sèche Oracle Zero Downtime Migration (-eval) pour valider tous les prérequis pour la migration. L'outil Cloud Pre-Migration Advisor Tool (CPAT) est exécuté pour valider que la base de données source est adaptée à la migration vers Oracle Exadata Database Service on Dedicated Infrastructure à l'aide de la migration logique Oracle Zero Downtime Migration. Résoudre les problèmes signalés par le CPAT avant de continuer. Par exemple :
```
zdmcli migrate database -sourcedb source_db_name \
-sourcenode IP/hostname_of_first_Exadata_node \
-srcauth zdmauth \
-srcarg1 user:root_or_sudoer_user \
-srcarg2 identity_file:path_to_ssh_private_key/ssh_private_key_file_name \
-srcarg3 sudo_location:/usr/bin/sudo \
-targetnode IP/hostname_of_first_exadata_database_dedicated_VM_cluster_node
-tgtarg1 user:opc \
-tgtarg2 identity_file:path_to_ssh_private_key/ssh_private_key_file_name \
-tgtarg3 sudo_location:/usr/bin/sudo \
-rsp path_to_response_file/response_file_name_from_step_14 \
-eval
```
Cette commande demande le mot de passe de l'utilisateur sys pour les bases de données source et cible.

Après une migration réussie de simulation, passez à l'étape suivante.

Après une migration de simulation, exécutez le travail Oracle Zero Downtime Migration. Par exemple :

zdmcli migrate database -sourcedb source_db_name \
-sourcenode IP/hostname_of_first_Exadata_node \
-srcauth zdmauth \
-srcarg1 user:root_or_sudoer_user \
-srcarg2 identity_file:path_to_ssh_private_key/ssh_private_key_file_name \
-srcarg3 sudo_location:/usr/bin/sudo \
-targetnode IP/hostname_of_first_exadata_database_dedicated_VM_cluster_node
-tgtarg1 user:opc \
-tgtarg2 identity_file:path_to_ssh_private_key/ssh_private_key_file_name \
-tgtarg3 sudo_location:/usr/bin/sudo \
-rsp path_to_response_file/response_file_name_from_step_14

Cette commande demande le mot de passe de l'utilisateur sys pour les bases de données source et cible.

Migration physique

Cette section décrit comment effectuer une migration physique hors ligne. Pour la migration en ligne, reportez-vous à la section Consulter la documentation.

Avant d'effectuer votre migration physique, tenez compte des points suivants.

Il existe un nouveau paramètre pour la gestion du cryptage de tablespace dans Oracle Database 19.16. Ce paramètre peut entraîner des conflits pour les migrations physiques. Pour plus d'informations, reportez-vous à la section Review Documentation de Tablespace Encryption Management.
Oracle Exadata sur site peut exécuter des bases de données à instance unique et RAC. Oracle Exadata Database Service on Dedicated Infrastructure exécute des bases de données RAC. Lors de la migration de la base de données, Oracle Zero Downtime Migration convertit une instance unique en bases de données RAC si nécessaire.
Un portefeuille Transparent Data Encryption (TDE) doit être défini sur la base de données source avant la migration, même si la base de données source n'est pas cryptée.
Dans Oracle Exadata sur site, l'utilisation d'Oracle Transparent Data Encryption pour crypter les bases de données est facultative. Lors de la migration de bases de données d'Exadata vers Oracle Exadata Database Service on Dedicated Infrastructure, la base de données Oracle Exadata Database Service on Dedicated Infrastructure cible sera toujours cryptée.
Les étapes suivantes supposent qu'il existe une connectivité réseau directe entre le centre de données où Exadata est installé et le réseau cloud virtuel OCI où Oracle Exadata Database Service on Dedicated Infrastructure et la machine virtuelle Oracle Zero Downtime Migration sont configurés (via le VPN FastConnect ou IPSec, comme indiqué dans le diagramme de l'architecture).
La base de données source sur Oracle Exadata n'a pas besoin d'être cryptée. Oracle Zero Downtime Migration chiffre la base de données cible pendant la migration.
Le mot de passe sys, le mot de passe de portefeuille, la version de base de données et le niveau de patch des bases de données source et cible doivent être identiques.
Oracle Zero Downtime Migration migre la base de données de conteneur (CDB) vers la base de données Conteneur et la base de données non-CDB vers une base de données non-CDB.
Oracle Zero Downtime Migration utilise Oracle Database Backup Cloud Service pour sauvegarder la base de données Exadata source dans OCI Object Storage. Oracle Zero Downtime Migration restaure ensuite la base de données cible à partir de cette sauvegarde.

Les étapes suivantes décrivent comment effectuer une migration physique hors ligne.

Dans la console OCI, créez une instance de calcul dans le même sous-réseau que celui où la base de données cible sera configurée.
Cette instance de calcul peut être n'importe quelle forme, avec au moins deux OCPU et 16 Go de RAM, exécutant le système d'exploitation Oracle Linux 7.9. Cette machine virtuelle sera utilisée pour exécuter le logiciel Oracle Zero Downtime Migration.
Suivez la documentation d'installation d'Oracle Zero Downtime Migration dans la section Consulter la documentation pour télécharger et installer le logiciel Oracle Zero Downtime Migration 21.4 sur l'instance de calcul OCI.
Exécutez le logiciel Oracle Zero Downtime Migration en tant que zdmuser.
Connectez-vous en tant que zdmuser à l'instance de calcul exécutant le logiciel Oracle Zero Downtime Migration et générez une paire de clés SSH. Activez SSH sans mot de passe à partir du compte zdmuser vers tous les noeuds de la base de données Exadata source (root, privilege-sudoer user) et vers tous les noeuds de cluster de machines virtuelles sur le compte opc user de la base de données cible.
Vérifiez que la machine virtuelle Oracle Zero Downtime Migration peut communiquer avec les hôtes de base de données source à l'aide du nom d'hôte et de l'adresse IP. Vérifiez les points suivants :
- Modifiez le résolveur DNS VCN ou le fichier /etc/hosts dans la machine virtuelle Oracle Zero Downtime Migration si nécessaire.
- Vérifiez qu'une règle de sécurité autorise la machine virtuelle Oracle Zero Downtime Migration à se connecter à la base de données source sur le port de processus d'écoute par défaut 1521 et le port SSH 22.
- Assurez-vous que la machine virtuelle Oracle Zero Downtime Migration peut atteindre les hôtes de base de données cible sur le port de processus d'écoute par défaut 1521 et le port SSH 22.
Dans la console OCI, créez un bucket OCI Object Storage s'il n'en existe pas déjà un.
Notez l'URL Swift, l'espace de noms Object Storage et le nom du bucket.
Dans la console OCI, créez un jeton d'authentification pour le téléchargement de données OCI_user vers le bucket OCI Object Storage.
Notez le jeton, il ne sera plus affiché.
Assurez-vous que les stratégies de sécurité autorisent OCI_user à télécharger des données vers le bucket OCI Object Storage.
Créez une base de données cible Oracle Exadata Database Service on Dedicated Infrastructure à l'aide de l'interface graphique OCI ou de l'API REST. Configurez la base de données cible comme suit :
- Les bases de données cible et source doivent avoir les mêmes noms, mais DB_UNIQUE_NAME différent.
- Le mot de passe sys, le mot de passe du portefeuille, la version de la base de données, le niveau de patch et la version du fichier de fuseau horaire sur les bases de données source et cible doivent être identiques.
- Ne sélectionnez pas de destination de sauvegarde ou n'activez pas les sauvegardes automatiques. Ces paramètres peuvent être activés après la migration de la base de données.
Vérifiez que la base de données source est configurée en mode Archivelog. Si Archivelog n'est pas activé, reportez-vous à la section Enable Archivelog Mode ci-dessous.
Si la base de données source n'est pas cryptée, reportez-vous à Configuration d'un fichier de clés TDE (Transparent Data Encryption) ci-dessous. Il n'est pas nécessaire de crypter les données. Seul le fichier de clés TDE est requis pour la migration physique. Assurez-vous que le mot de passe du fichier de clés (portefeuille) est identique au mot de passe sys/portefeuille utilisé pour créer la base de données cible dans Oracle Exadata Database Service on Dedicated Infrastructure.
Créez un fichier de réponses pour qu'Oracle Zero Downtime Migration exécute la migration. Les paramètres clés sont les suivants :
- TGT_DB_UNIQUE_NAME : nom unique de base de données pour la base de données Oracle Exadata Database Service on Dedicated Infrastructure cible.
- MIGRATION_METHOD : OFFLINE_PHYSICAL ou ONLINE_PHYSICAL.
- DATA_TRANSFER_MEDIUM: OSS
- PLATFORM_TYPE: EXACS
- HOST : URL Swift pour l'espace de noms OCI Object Storage de l'étape 5 au format : https://swiftobjectstorage.<region>.oraclecloud.com/v1/<namespace>>. Exemple :
```
https://switfobjectstorage.us-phoenix-1.oraclecloud.com/v1/axwytvijqqld
```
- OPC_CONTAINER : nom de bucket OCI Object Storage à partir de l'étape 4.
- SHUTDOWN_SRC: TRUE

Exécutez un travail de migration à exécution sèche Oracle Zero Downtime Migration (-eval) pour valider tous les prérequis pour la migration. Par exemple :

zdmcli migrate database -sourcedb source_db_name \
-sourcenode IP/hostname_of_first_Exadata_node \
-srcauth zdmauth \
-srcarg1 user: root_or_sudoer_user \
-srcarg2 identity_file: path_to_ssh_private_key/ssh_private_key_file_name
\
-srcarg3 sudo_location:/usr/bin/sudo \
-targetnode IP/hostname_of_first_exadata_database_dedicated_VM_cluster_node
-tgtarg1 user:opc \
-tgtarg2 identity_file: path_to_ssh_private_key/ssh_private_key_file_name
\
-tgtarg3 sudo_location:/usr/bin/sudo \
-rsp path_to_response_file/response_file_name_from_step_10 \
-backupuser “OCI_user_id_for_user_allowed_to_upload_data_to_OCI_object_storage_bucket”
-eval

Cette commande demande deux mots de passe. Le premier mot de passe est le mot de passe sys de la base de données source. Le deuxième mot de passe est le mot de passe OCI_user pour l'utilisateur qui télécharge des données vers le bucket OCI Object Storage. N'entrez pas le mot de passe utilisateur ici. Entrez plutôt le jeton d'authentification à partir de l'étape 6.

Après un séchage réussi, passez à l'étape suivante.

Exécutez le travail Oracle Zero Downtime Migration. Par exemple :

zdmcli migrate database -sourcedb source_db_name \
-sourcenode IP/hostname_of_first_Exadata_node \
-srcauth zdmauth \
-srcarg1 user: root_or_sudoer_user \
-srcarg2 identity_file: path_to_ssh_private_key/ssh_private_key_file_name
\
-srcarg3 sudo_location:/usr/bin/sudo \
-targetnode IP/hostname_of_first_exadata_database_dedicated_VM_cluster_node
-tgtarg1 user:opc \
-tgtarg2 identity_file: path_to_ssh_private_key/ssh_private_key_file_name
\
-tgtarg3 sudo_location:/usr/bin/sudo \
-rsp path_to_response_file/response_file_name_from_step_10 \
-backupuser “OCI_user_id_for_user_allowed_to_upload_data_to_OCI_object_storage_bucket”

La migration physique hors ligne est terminée.

Activer le mode de consignation des archives

Le mode Archivelog doit être activé sur la base de données source pour les migrations physiques Oracle Zero Downtime Migration. Ces étapes décrivent comment configurer le mode Archivelog sur la base de données source.

Vérifiez que la base de données source n'est pas configurée en mode Archivelog.
```
SQL> select log_mode from v$database;
LOG_MODE
------------
NOARCHIVELOG
```

Configurez la destination de l'archive de journal de base de données source. Etant donné que cette configuration concerne une base de données exécutée dans Exadata, la destination du journal d'archivage doit être le groupe de disques Oracle RECO ASM.

SQL> alter system set log_archive_dest_1='LOCATION=+RECOC1' scope=both SID='*';
System altered.
SQL> select destination,STATUS from v$archive_dest where statuS='VALID';
DESTINATION
--------------------------------------------------------------------------------
STATUS
---------
+RECOC1
VALID

Arrêtez la base de données.
```
$ srvctl stop database -d db_name
```
Commencez à monter la base de données sur le premier noeud.
```
SQL> startup mount;
ORACLE instance started.
```
Activez le mode Archivelog.
```
alter database archivelog;
```
Ouvrez la base de données.
```
alter database open;
```

Vérifiez que la base de données est en mode Archivelog.

SQL> select log_mode from v$database;
LOG_MODE
------------
ARCHIVELOG
SQL> select destination,STATUS from v$archive_dest where status='VALID';
DESTINATION
--------------------------------------------------------------------------------
STATUS
---------
+RECOC1
VALID

Redémarrez la base de données sur le deuxième noeud.

$ srvctl start instance -d db_name -n hostname_node2

Vérifiez que les bases de données pluggables sont en mode ouvert, lecture et écriture sur les deux noeuds. Si les bases de données pluggables ne sont pas ouvertes, ouvrez-les sur les deux noeuds et enregistrez l'état.
```
SQL> Alter pluggabale database pdb_name open instances=all;
SQL>Alter pluggable database pdb_name save state instances=all;
```

Configuration d'un fichier de clés Transparent Data Encryption (TDE)

Les migrations physiques Oracle Zero Downtime Migration nécessitent un portefeuille/fichier de clés de cryptage TDE auto_login (même si la base de données source n'est pas cryptée). Ce fichier de clés doit être configuré avec le même mot de passe que le fichier de clés de la base de données cible. Ces étapes décrivent comment configurer un fichier de clés d'accès sur la base de données source.

Vérifiez si un emplacement de fichier de clés par défaut est configuré pour la base de données.

SQL> select * from v$encryption_wallet;
WRL_TYPE
--------------------
WRL_PARAMETER
--------------------------------------------------------------------------------
STATUS WALLET_TYPE WALLET_OR KEYSTORE FULLY_BAC
------------------------------ -------------------- --------- -------- ---------
CON_ID
----------
FILE
/u01/app/oracle/admin/db_name/wallet
NOT_AVAILABLE UNKNOWN SINGLE NONE UNDEFINED
1
SQL>

Cette sortie indique qu'aucun fichier de clés ou portefeuille n'est configuré.

Définissez la variable TNS_ADMIN pour l'utilisateur oracle sur les deux noeuds Exadata.
```
$ORACLE_HOME/network/admin/db_name
```
Créez un répertoire pour stocker le fichier sqlnet.ora sur les deux noeuds Exadata pointés par TNS_ADMIN.
```
mkdir -p $ORACLE_HOME/network/admin/db_name
```
Créez le fichier sqlnet.ora dans le répertoire désigné par TNS_ADMIN avec le contenu suivant sur les deux noeuds Exadata.
```
ENCRYPTION_WALLET_LOCATION=(SOURCE=(METHOD=FILE)
 (METHOD_DATA=(DIRECTORY=/u01/app/oracle/admin/db_name/wallet)))
```
Créez un répertoire pour stocker le fichier de clés ou le portefeuille à l'emplacement indiqué par sqlnet.ora sur les deux noeuds Exadata.
```
$mkdir -p $/u01/app/oracle/admin/db_name/wallet
```
Sur le premier noeud, créez le keystore protégé par un mot de passe.
Le fichier de clés de la base de données cible doit également être configuré avec ce mot de passe.
```
SQL>administer key management create keystore '/u01/app/oracle/admin/db_name/wallet' identified by keystore_password;
```
Sur le premier noeud, ouvrez le fichier de clés.
Si la base de données source est une base de données non Conteneur, enlevez container = ALL.
```
SQL> ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY keystore_password container = ALL;
```
Créez une sauvegarde pour le fichier de clés.
Si la base de données source est une base de données non Conteneur, enlevez container = ALL.
```
SQL> ADMINISTER KEY MANAGEMENT SET KEY IDENTIFIED BY keystore_password with backup container = ALL;
```

Vérifiez que le fichier de clés a été créé et sauvegardé.

SQL> SELECT * FROM v$encryption_keys;
Snip…
ACTIVATING_PDBNAME
--------------------------------------------------------------------------------
ACTIVATING_PDBID ACTIVATING_PDBUID ACTIVATING_PDBGUID CON_ID
---------------- ----------------- -------------------------------- ----------
ATOlrcGaa0/iv/dFeRSkNSIAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
--------------------------------------------------------------------------------
ACTIVATING_PDBID ACTIVATING_PDBUID ACTIVATING_PDBGUID CON_ID
---------------- ----------------- -------------------------------- ----------
db_name
ACTIVATING_PDBID ACTIVATING_PDBUID ACTIVATING_PDBGUID CON_ID
---------------- ----------------- -------------------------------- ----------
1 86B637B62FDF7A65E053F706E80A27CA
Snip…

Créez un fichier de clés auto_login à partir du fichier de clés créé à l'étape 7.

SQL> ADMINISTER KEY MANAGEMENT CREATE AUTO_LOGIN KEYSTORE FROM KEYSTORE '/u01/app/oracle/admin/db_name/wallet' IDENTIFIED BY keystore_password ;

Fermez le fichier de clés de l'étape 7.

SQL> ADMINISTER KEY MANAGEMENT SET KEYSTORE CLOSE IDENTIFIED BY keystore_password;

Vérifiez que le keystore auto_login est toujours ouvert.

SQL> SELECT * FROM v$encryption_wallet;
WRL_TYPE
--------------------
WRL_PARAMETER
--------------------------------------------------------------------------------
STATUS WALLET_TYPE WALLET_OR KEYSTORE FULLY_BAC
------------------------------ -------------------- --------- -------- ---------
CON_ID
----------
FILE
/u01/app/oracle/admin/db_name/wallet
OPEN AUTOLOGIN SINGLE NONE NO

Créez des fichiers de portefeuille du noeud 1 vers le noeud 2.

cd /u01/app/oracle/admin/db_name/wallet.
scp * node_2:/u01/app/oracle/admin/db_name/wallet

Redémarrez la base de données sur les deux noeuds Exadata.

$ srvctl stop database -d db_name
$ srvctl start database -d db_name
$ srvctl status database -d db_name
Instance db_name1 is running on node node_1
Instance db_name2 is running on node node_2

Vérifiez que le portefeuille auto_login est ouvert sur les deux noeuds.

SQL> SELECT * FROM v$encryption_wallet;
WRL_TYPE
--------------------
WRL_PARAMETER
--------------------------------------------------------------------------------
STATUS WALLET_TYPE WALLET_OR KEYSTORE FULLY_BAC
------------------------------ -------------------- --------- -------- ---------
CON_ID
----------
FILE
/u01/app/oracle/admin/db_name/wallet/
OPEN AUTOLOGIN SINGLE NONE NO
1
WRL_TYPE
--------------------
WRL_PARAMETER
--------------------------------------------------------------------------------
STATUS WALLET_TYPE WALLET_OR KEYSTORE FULLY_BAC
------------------------------ -------------------- --------- -------- ---------
CON_ID
----------
FILE
OPEN AUTOLOGIN SINGLE UNITED NO
2
WRL_TYPE
--------------------
WRL_PARAMETER
--------------------------------------------------------------------------------
STATUS WALLET_TYPE WALLET_OR KEYSTORE FULLY_BAC
------------------------------ -------------------- --------- -------- ---------
CON_ID
----------
FILE
OPEN_NO_MASTER_KEY AUTOLOGIN SINGLE UNITED UNDEFINED
3
SQL>

Vérifiez que les bases de données pluggables sont en mode ouvert, lecture et écriture sur les deux noeuds. Si les bases de données pluggables ne sont pas ouvertes, ouvrez-les sur les deux noeuds et enregistrez l'état.
```
SQL> Alter pluggabale database pdb_name open instances=all;
SQL>Alter pluggable database pdb_name save state instances=all;
```