Présentation de la mise à niveau cloud sans réutilisation de la mémoire d'Exadata Cloud@Customer Gen1 vers une infrastructure Oracle Exadata Database Service on Cloud@Customer Gen2

• Les formes de système Exadata Cloud@Customer X6 et X7 sont admissibles à la mise à niveau sans réutilisation de la mémoire.
• Les bases de données sur Exadata Cloud@Customer Gen 1 qui font partie d'une configuration Data Guard sont prises en charge par la migration. Dans ce cas, la base de données principale doit être migrée vers Exadata Cloud@Customer Gen 2 à l'aide de la procédure standard. Une fois la migration effectuée, la configuration Data Guard doit être définie côté Exadata Cloud@Customer Gen 2 à l'aide de la procédure Gen 2 standard.

• La mise à niveau d'Exadata Cloud@Customer Gen 1 vers Gen 2 est effectuée uniquement lorsque les versions logicielles sont compatibles sur les systèmes source et cible.

  • Logiciel Oracle Database : la source et la cible doivent présenter la même version majeure. Par exemple, la version de la source et de la cible doit être la version 19c. Toutefois, la cible peut avoir un niveau de patch plus élevé que la source. Par exemple, les versions de patch peuvent être 19.3 pour la source et 19.8 pour la cible. Equivalence pour la version 12.2 : la source et la cible doivent présenter la version 12.2.0.1 du logiciel Oracle Database, mais les niveaux de patch peuvent être 2019JulyRU sur la source et 2020OctRU sur la cible.
  • Base de données non Conteneur vers base de données non Conteneur.
  • Déploiement colocatif (base de données Conteneur/pluggable) vers déploiement colocatif (base de données Conteneur/pluggable).
  • Base de données Oracle Database à instance unique : après la migration, la source de base de données à instance unique est convertie en base de données Oracle RAC (Oracle Real Application Clusters) sur la cible.
• Des différences au niveau des versions logicielles sont notamment autorisées pour les éléments suivants :
  • Oracle Grid Infrastructure
  • Logiciel Exadata
  • Système d'exploitation de machine virtuelle invitée
  • Outils DBaaS
• Les bases de données Oracle créées sur Exadata Cloud@Customer Gen 1 avec des outils back-end, dbaasapi et dbaascli, sont également prises en charge, en plus des bases de données Oracle créées à l'aide de la console Gen 1.
• Toutes les versions d'Oracle Database prises en charge sur Exadata Cloud@Customer Gen 1 sont prises en charge et seront migrées vers la même version majeure sur la cible. L'environnement Gen 2 se trouve sur la dernière version prise en charge d'Exadata Cloud@Customer Gen 2 pour le système d'exploitation de machine virtuelle invitée et Oracle Grid Infrastructure.

Les éléments suivants ne sont pas concernés par la mise à niveau cloud sans réutilisation de la mémoire vers le nouveau matériel Gen 2 :

• Un déploiement Exadata Cloud@Customer Gen 1 qui utilise des fonctionnalités Exadata Cloud@Customer Gen 1 indisponibles sur Gen 2 pour l'instant ne doit pas utiliser les procédures de mise à niveau tant que les fonctionnalités appropriées ou un équivalent ne sont pas disponibles sur Gen 2.
• Seule la mise à niveau d'Exadata Cloud@Customer est concernée par la procédure décrite ici. La mise à niveau ou la migration d'OCC lui-même n'entre pas dans le champ d'application.
• Vous pouvez annuler la mise à niveau tant que le matériel principal et le matériel secondaire se trouvent sur votre site. Une perte de données est possible selon l'utilisation de l'application et le moment de l'activation. Une fois le matériel Exadata Cloud@Customer Gen 1 renvoyé à Oracle, vous ne pouvez plus annuler la mise à niveau ni rétablir Exadata Cloud@Customer Gen 1.

Consultez cette liste de contrôle pour préparer la mise à niveau cloud sans réutilisation de la mémoire vers une nouvelle infrastructure Gen 2 :

• Configuration de l'environnement Exadata Cloud@Customer Gen 2

  Pour démarrer une mise à niveau sans réutilisation de la mémoire d'Exadata Cloud@Customer Gen 1 vers Gen 2, vous devez disposer d'un déploiement Exadata Cloud@Customer Gen 2 de base opérationnel.

  Pour plus d'informations sur la configuration d'Exadata Cloud@Customer Gen 2, reportez-vous à Préparation pour Exadata Cloud@Customer.

• Configuration du matériel pour migrer les bases de données Oracle à l'aide d'Oracle Zero Downtime Migration (ZDM). Pour plus d'informations, reportez-vous à Préparation d'un hôte pour l'installation du logiciel Zero Downtime Migration.

• Configuration du réseau
  • Indiquez le chemin d'accès réseau des serveurs Exadata Cloud@Customer Gen 1 et des serveurs Gen 2 vers les serveurs ZDM utilisés pour la mise à niveau.
  • Indiquez l'accès réseau et l'accès SSH du serveur de migration sans temps d'inactivité vers l'infrastructure Exadata Cloud@Customer appropriée.
  • Pour tout accès client aux bases de données cible, assurez-vous qu'un chemin réseau est disponible de l'hôte du client vers les nouvelles bases de données Exadata Cloud@Customer Gen 2 déployées.
• Logiciel
  • La mise à niveau nécessite les versions minimales de la pile logicielle. Par conséquent, installez d'abord la version appropriée d'Oracle Grid Infrastructure sur l'infrastructure Exadata Cloud@Customer Gen 2 cible.
  • Les versions d'Oracle Database prises en charge sur Exadata Cloud@Customer Gen 1 continuent à être prises en charge. Sur l'infrastructure Gen 2 cible, installez les versions appropriées du logiciel Oracle Database et les patches ponctuels qui existent dans la base de données source.
  • Veillez au respect de toutes les exigences applicables aux serveurs de migration sans temps d'inactivité en matière d'installation, de configuration, d'accès réseau et d'accès SSH.
• Sécurité
  • Exadata Cloud@Customer Gen 2 n'utilise pas OASG (Oracle Advanced Support Gateway Security) et ne peut donc pas demander de journaux OASG.
• Assurez-vous que la sauvegarde automatique n'est pas configurée sur la cible Gen 2 avant la migration.

Utilisez la migration sans temps d'inactivité pour migrer des bases de données Oracle d'une infrastructure Exadata Cloud@Customer Gen1 vers une infrastructure Oracle Exadata Database Service on Cloud@Customer Gen2.

Pour vous familiariser avec les fonctionnalités de migration sans temps d'inactivité, reportez-vous à Configuration du logiciel de migration sans temps d'inactivité. Dans un premier temps, téléchargez, installez et configurez la migration sans temps d'inactivité sur l'hôte identifié pour le serveur de migration sans temps d'inactivité.

Zero Downtime Migration prend en charge la migration en ligne et hors ligne (sauvegarde et récupération). Pour la mise à niveau d'Exadata Cloud@Customer de Gen 1 vers Gen 2, il est recommandé d'utiliser la migration physique ZDM. Plus précisément, il est recommandé d'utiliser la migration en ligne avec transfert de données direct (migration physique en ligne [MIGRATION_METHOD=ONLINE_PHYSICAL] à l'aide du transfert de données direct [DATA_TRANSFER_MEDIUM=DIRECT]). La migration en ligne avec transfert de données direct est disponible avec Zero Downtime Migration 21.2 et prend en charge le transfert de données direct pour la méthodologie de migration physique. Cette nouvelle fonctionnalité permet aux utilisateurs d'éviter d'employer un emplacement de stockage intermédiaire pour les sauvegardes (NFS ou OCI Object Storage en général). ZDM exploite la duplication de base de données active (pour les bases de données de version 11.2) ou la restauration à partir du service (pour les bases de données de version 12 et supérieures). Vous pouvez utiliser cette méthode pour migrer vos bases de données Exadata Cloud@Customer Gen 1 vers Exadata Cloud@Customer Gen 2. Des exemples de fichiers de réponses et de ligne de commande sont fournis ci-dessous pour référence.

Pour plus d'informations, reportez-vous à :

• Introduction à la migration sans temps d'inactivité
• Préparation de la migration de base de données
• Migration de la base de données sans temps d'inactivité

zdmcli migrate database -sourcedb z19tgt1 -sourcenode scaqae03client01vm06 -srcauth zdmauth -srcarg1 user:opc -srcarg2 identity_file:/home/giusr/.ssh/id_gen1vm -srcarg3 sudo_location:/usr/bin/sudo -targetnode tgt1 -rsp /home/giusr/activeduplicate_zdm_online_19c.rsp -tgtauth zdmauth -tgtarg1 user:opc -tgtarg2 identity_file:/home/giusr/.ssh/dbaas_sshkey.priv -tgtarg3 sudo_location:/usr/bin/sudo -schedule NOW -tdekeystorepasswd
ZDM_GET_SRC_INFO .............. COMPLETED
ZDM_GET_TGT_INFO .............. COMPLETED
ZDM_PRECHECKS_SRC ............. COMPLETED
ZDM_PRECHECKS_TGT ............. COMPLETED
ZDM_SETUP_SRC ................. COMPLETED
ZDM_SETUP_TGT ................. COMPLETED
ZDM_PREUSERACTIONS ............ COMPLETED
ZDM_PREUSERACTIONS_TGT ........ COMPLETED
ZDM_VALIDATE_SRC .............. COMPLETED
ZDM_VALIDATE_TGT .............. COMPLETED
ZDM_DISCOVER_SRC .............. COMPLETED
ZDM_COPYFILES ................. COMPLETED
ZDM_PREPARE_TGT ............... COMPLETED
ZDM_SETUP_TDE_TGT ............. COMPLETED
ZDM_DUPLICATE_TGT ............. COMPLETED
ZDM_FINALIZE_TGT .............. COMPLETED
ZDM_CONFIGURE_DG_SRC .......... COMPLETED
ZDM_SWITCHOVER_SRC ............ COMPLETED
ZDM_SWITCHOVER_TGT ............ COMPLETED
ZDM_POST_DATABASE_OPEN_TGT .... COMPLETED
ZDM_DATAPATCH_TGT ............. COMPLETED
ZDM_MANIFEST_TO_CLOUD ......... COMPLETED
ZDM_POST_MIGRATE_TGT .......... COMPLETED
ZDM_POSTUSERACTIONS ........... COMPLETED
ZDM_POSTUSERACTIONS_TGT ....... COMPLETED
ZDM_CLEANUP_SRC ............... COMPLETED
ZDM_CLEANUP_TGT ............... COMPLETED

TGT_DB_UNIQUE_NAME=z19tgt1_uniq2
MIGRATION_METHOD=ONLINE_PHYSICAL
DATA_TRANSFER_MEDIUM=DIRECT
PLATFORM_TYPE=EXACC
SRC_HTTP_PROXY_URL=
SRC_HTTP_PROXY_PORT=
SRC_CONFIG_LOCATION=
SRC_BASTION_HOST_IP=
SRC_BASTION_PORT=
SRC_BASTION_USER=
SRC_BASTION_IDENTITY_FILE=
SRC_HOST_IP=
SRC_TIMEZONE=
SRC_OSS_PROXY_HOST=
SRC_OSS_PROXY_PORT=
SRC_SSH_RETRY_TIMEOUT=
SRC_PDB_NAME=
SRC_DB_LISTENER_PORT=
TGT_HTTP_PROXY_URL=
TGT_HTTP_PROXY_PORT=
TGT_CONFIG_LOCATION=
TGT_BASTION_HOST_IP=
TGT_BASTION_PORT=
TGT_BASTION_USER=
TGT_BASTION_IDENTITY_FILE=
TGT_HOST_IP=
TGT_SSH_TUNNEL_PORT=
TGT_SSH_RETRY_TIMEOUT=
TGT_OSS_PROXY_HOST=
TGT_OSS_PROXY_PORT=
TGT_DATADG=
TGT_REDODG=
TGT_RECODG=
TGT_DATAACFS=
TGT_REDOACFS=
TGT_RECOACFS=
BACKUP_PATH=
HOST=
OPC_CONTAINER=
SRC_ZDLRA_WALLET_LOC=
TGT_ZDLRA_WALLET_LOC=
ZDLRA_CRED_ALIAS=
NONCDBTOPDB_CONVERSION=FALSE
NONCDBTOPDB_SWITCHOVER=TRUE
SKIP_FALLBACK=TRUE
TGT_RETAIN_DB_UNIQUE_NAME=
TGT_SKIP_DATAPATCH=FALSE
MAX_DATAPATCH_DURATION_MINS=
DATAPATCH_WITH_ONE_INSTANCE_RUNNING=
SHUTDOWN_SRC=
SKIP_SRC_SERVICE_RETENTION=
SRC_RMAN_CHANNELS=6
TGT_RMAN_CHANNELS=16
ZDM_LOG_OSS_PAR_URL=
ZDM_BACKUP_FULL_SRC_MONITORING_INTERVAL=10
ZDM_BACKUP_INCREMENTAL_SRC_MONITORING_INTERVAL=10
ZDM_BACKUP_DIFFERENTIAL_SRC_MONITORING_INTERVAL=10
ZDM_CLONE_TGT_MONITORING_INTERVAL=10
ZDM_OSS_RESTORE_TGT_MONITORING_INTERVAL=10
ZDM_OSS_RECOVER_TGT_MONITORING_INTERVAL=10
ZDM_BACKUP_RETENTION_WINDOW=
ZDM_BACKUP_TAG=
ZDM_USE_EXISTING_BACKUP=
ZDM_OPC_RETRY_WAIT_TIME=
ZDM_OPC_RETRY_COUNT=
ZDM_SRC_TNS_ADMIN=
ZDM_CURL_LOCATION=
ZDM_USE_EXISTING_UNDO_SIZE=
ZDM_SKIP_DG_CONFIG_CLEANUP=
ZDM_RMAN_COMPRESSION_ALGORITHM=LOW
ZDM_SRC_DB_RESTORE_SERVICE_NAME=
ZDM_RMAN_DIRECT_METHOD=ACTIVE_DUPLICATE

zdmcli migrate database -sourcedb z12tgt1s -sourcenode scaqae03client01vm06 -srcauth zdmauth -srcarg1 user:opc -srcarg2 identity_file:/home/giusr/.ssh/id_gen1vm -srcarg3 sudo_location:/usr/bin/sudo -targetnode tgt1 -rsp /home/giusr/dir_zdm_online_121_sidb.rsp -tgtauth zdmauth -tgtarg1 user:opc -tgtarg2 identity_file:/home/giusr/.ssh/dbaas_sshkey.priv-tgtarg3 sudo_location:/usr/bin/sudo -schedule NOW -tdekeystorepasswd"
ZDM_GET_SRC_INFO .............. COMPLETED
ZDM_GET_TGT_INFO .............. COMPLETED
ZDM_PRECHECKS_SRC ............. COMPLETED
ZDM_PRECHECKS_TGT ............. COMPLETED
ZDM_SETUP_SRC ................. COMPLETED
ZDM_SETUP_TGT ................. COMPLETED
ZDM_PREUSERACTIONS ............ COMPLETED
ZDM_PREUSERACTIONS_TGT ........ COMPLETED
ZDM_VALIDATE_SRC .............. COMPLETED
ZDM_VALIDATE_TGT .............. COMPLETED
ZDM_DISCOVER_SRC .............. COMPLETED
ZDM_COPYFILES ................. COMPLETED
ZDM_PREPARE_TGT ............... COMPLETED
ZDM_SETUP_TDE_TGT ............. COMPLETED
ZDM_RESTORE_TGT ............... COMPLETED
ZDM_RECOVER_TGT ............... COMPLETED
ZDM_FINALIZE_TGT .............. COMPLETED
ZDM_CONFIGURE_DG_SRC .......... COMPLETED
ZDM_SWITCHOVER_SRC ............ COMPLETED
ZDM_SWITCHOVER_TGT ............ COMPLETED
ZDM_POST_DATABASE_OPEN_TGT .... COMPLETED
ZDM_DATAPATCH_TGT ............. COMPLETED
ZDM_MANIFEST_TO_CLOUD ......... COMPLETED
ZDM_POST_MIGRATE_TGT .......... COMPLETED
ZDM_POSTUSERACTIONS ........... COMPLETED
ZDM_POSTUSERACTIONS_TGT ....... COMPLETED
ZDM_CLEANUP_SRC ............... COMPLETED
ZDM_CLEANUP_TGT ............... COMPLETED

TGT_DB_UNIQUE_NAME=z12tgt1s_uniq
MIGRATION_METHOD=ONLINE_PHYSICAL
DATA_TRANSFER_MEDIUM=DIRECT
PLATFORM_TYPE=EXACC
SRC_HTTP_PROXY_URL=
SRC_HTTP_PROXY_PORT=
SRC_CONFIG_LOCATION=
SRC_BASTION_HOST_IP=
SRC_BASTION_PORT=
SRC_BASTION_USER=
SRC_BASTION_IDENTITY_FILE=
SRC_HOST_IP=
SRC_TIMEZONE=
SRC_OSS_PROXY_HOST=
SRC_OSS_PROXY_PORT=
SRC_SSH_RETRY_TIMEOUT=
SRC_PDB_NAME=
SRC_DB_LISTENER_PORT=
TGT_HTTP_PROXY_URL=
TGT_HTTP_PROXY_PORT=
TGT_CONFIG_LOCATION=
TGT_BASTION_HOST_IP=
TGT_BASTION_PORT=
TGT_BASTION_USER=
TGT_BASTION_IDENTITY_FILE=
TGT_HOST_IP=
TGT_SSH_TUNNEL_PORT=
TGT_SSH_RETRY_TIMEOUT=
TGT_OSS_PROXY_HOST=
TGT_OSS_PROXY_PORT=
TGT_DATADG=
TGT_REDODG=
TGT_RECODG=
TGT_DATAACFS=
TGT_REDOACFS=
TGT_RECOACFS=
BACKUP_PATH=
HOST=
OPC_CONTAINER=
SRC_ZDLRA_WALLET_LOC=
TGT_ZDLRA_WALLET_LOC=
ZDLRA_CRED_ALIAS=
NONCDBTOPDB_CONVERSION=FALSE
NONCDBTOPDB_SWITCHOVER=TRUE
SKIP_FALLBACK=TRUE
TGT_RETAIN_DB_UNIQUE_NAME=
TGT_SKIP_DATAPATCH=FALSE
MAX_DATAPATCH_DURATION_MINS=
DATAPATCH_WITH_ONE_INSTANCE_RUNNING=
SHUTDOWN_SRC=
SKIP_SRC_SERVICE_RETENTION=
SRC_RMAN_CHANNELS=6
TGT_RMAN_CHANNELS=16
ZDM_LOG_OSS_PAR_URL=
ZDM_BACKUP_FULL_SRC_MONITORING_INTERVAL=10
ZDM_BACKUP_INCREMENTAL_SRC_MONITORING_INTERVAL=10
ZDM_BACKUP_DIFFERENTIAL_SRC_MONITORING_INTERVAL=10
ZDM_CLONE_TGT_MONITORING_INTERVAL=10
ZDM_OSS_RESTORE_TGT_MONITORING_INTERVAL=10
ZDM_OSS_RECOVER_TGT_MONITORING_INTERVAL=10
ZDM_BACKUP_RETENTION_WINDOW=
ZDM_BACKUP_TAG=
ZDM_USE_EXISTING_BACKUP=
ZDM_OPC_RETRY_WAIT_TIME=
ZDM_OPC_RETRY_COUNT=
ZDM_SRC_TNS_ADMIN=
ZDM_CURL_LOCATION=
ZDM_USE_EXISTING_UNDO_SIZE=
ZDM_SKIP_DG_CONFIG_CLEANUP=
ZDM_RMAN_COMPRESSION_ALGORITHM=LOW
ZDM_SRC_DB_RESTORE_SERVICE_NAME=
ZDM_RMAN_DIRECT_METHOD=

Monitoring : Oracle surveille l'installation d'Oracle Exadata Database Service on Cloud@Customer Gen2 dès le départ, comme une installation Gen2 standard.

Sauvegardes : les sauvegardes sont effectuées à partir du cluster de machines virtuelles Exadata Cloud@Customer Gen 1. Elles continuent à fonctionner lors de la mise à niveau. Après la migration vers Oracle Exadata Database Service on Cloud@Customer Gen2, les sauvegardes vers le service Object Storage d'Oracle Cloud Client (OCC) Gen1 ne sont pas autorisées et vous devez utiliser les méthodes de sauvegarde prises en charge pour Oracle Exadata Database Service on Cloud@Customer Gen2.

La mise à niveau déplacera vos ressources vers le plan de contrôle Oracle Exadata Database Service on Cloud@Customer Gen 2 Cloud et vers le matériel nouvelle génération.

Utilisez la console OCI Gen2 pour gérer les clusters, les clusters, les bases de données et les utilisateurs/groupes, ainsi que l'infrastructure Oracle Exadata Database Service on Cloud@Customer Gen2.

La pile logicielle est mise à niveau vers des versions plus récentes, par exemple :

• logiciel Exadata : 19.x ou version ultérieure,
• Oracle Grid Infrastructure : 19c.
• système d'exploitation de machine virtuelle invitée : Oracle Linux 7,
• outils DBaaS : 20.x,
• numéro CSI : vous avez un nouveau numéro CSI pour le compte cloud.

Application de patches : le processus d'application de patches à l'infrastructure et la notification sont différents dans Gen 2. Pour plus d'informations, reportez-vous à Maintenance d'un système Exadata Cloud@Customer.

Dans le cadre de la mise à niveau, nous vous recommandons d'utiliser l'outil de migration sans temps d'inactivité Oracle.

Voici quelques bonnes pratiques recommandées dans le cadre de l'utilisation de la migration sans temps d'inactivité pour la mise à niveau de Gen 1 vers Gen 2 :

• Bien que toutes les méthodes de migration physique soient prises en charge, il est recommandé d'utiliser la migration en ligne avec transfert de données direct.
  Remarque
  
  Il n'est pas recommandé d'utiliser OCI Object Storage ou le service Object Storage Oracle Cloud@Customer Gen 1 pour cette migration.
• Définissez ZDM_RMAN_COMPRESSION_ALGORITHM sur LOW.
• Le répertoire de base Oracle de base de données cible doit présenter un niveau de patch identique ou supérieur à celui de la source.
• Le répertoire de base Oracle de base de données cible doit comporter tous les patches ponctuels du répertoire de base Oracle source.
• Effectuez une exécution de validation avant l'exécution réelle.
• Pour une base de données Conteneur source, toutes les bases de données pluggables de la source doivent être en ligne.