Visión general de la actualización de Exadata Cloud@Customer Gen1 a Oracle Exadata Database Service on Cloud@Customer Gen2 Infrastructure

Gen 1 es la primera generación de Exadata Database Service en Cloud at Customer, que se despliega junto con Oracle Cloud At Customer (OCC) Gen 1 como plano de control desplegado en el centro de datos del cliente. Oracle Exadata Database Service on Cloud@Customer Gen2 se gestiona desde el plano de control de Oracle Cloud Infrastructure (OCI), que se ejecuta en la nube pública de OCI.

Cambio de versión en la nube fuera de lugar a la infraestructura de Exadata Database Service en Cloud at Customer Gen 2: si ejecuta Exadata Cloud at Customer Gen 1 en la infraestructura X6 o X7, con esta oferta Oracle sustituirá la infraestructura X6 o X7 Gen 1 por una nueva infraestructura de Exadata Cloud at Customer Gen 2 y le proporcionará instrucciones para utilizar Oracle Zero Downtime Migration (ZDM) para migrar sus bases de datos de la plataforma de Exadata Cloud at Customer Gen 1 a la plataforma de Exadata Cloud at Customer Gen2 . La sustitución de la infraestructura X6 o X7 de Exadata Cloud at Customer Gen 1 y la migración de las bases de datos a la plataforma de Exadata Cloud at Customer Gen 2 recibe el nombre de cambio de versión en la nube fuera de lugar.

Ámbito del cambio de versión en la nube fuera de lugar de Exadata Cloud at Customer Gen 1 a Gen 2

  • Las unidades de sistema X6 y X7 de Exadata Cloud at Customer son aptas para el cambio de versión fuera de lugar.
  • La migración soporta las bases de datos de Exadata Cloud@Customer Gen 1 que participen en una configuración de Data Guard. En este caso, se debe migrar la base de datos principal a Exadata Cloud at Customer Gen 2 mediante el procedimiento habitual. Una vez realizada la migración, se debe configurar la configuración de Data Guard en Exadata Cloud at Customer Gen 2 mediante el procedimiento habitual de Gen 2.
  • El cambio de versión de Exadata Cloud at Customer Gen 1 a Gen 2 solo se realiza cuando las versiones del software en los sistemas de origen y de destino son compatibles.

    • Software de Oracle Database: el origen y el destino deben tener la misma versión principal. Por ejemplo, tanto el origen como el destino deben tener la versión 19c. Sin embargo, el destino puede tener un nivel de parches superior al del origen. Por ejemplo, las versiones de los parches pueden ser 19.3 en el origen y 19.8 en el destino. La equivalencia correspondiente para 12.2 es la siguiente: tanto el origen como el destino deben tener la versión 12.2.0.1 del software de Oracle Database, pero los niveles de parches pueden ser 2019JulyRU en el origen y 2020OctRU en el destino.
    • Base de datos sin contenedor (no CDB) a no CDB.
    • Despliegue multi-inquilino (CDB/PDB) a despliegue multi-inquilino (CDB/PDB).
    • Oracle Database de instancia única: después de la migración, el origen de base de datos de instancia única se convertirá en una base de datos de Oracle Real Application Clusters (Oracle RAC) en el destino.
  • Las diferencias permitidas en las versiones de software incluyen:
    • Oracle Grid Infrastructure
    • Software de Exadata
    • Sistema operativo de VM de invitado
    • Herramientas de DBaaS
  • Además de las bases de datos de Oracle creadas mediante la consola de Gen 1, también se soportan las bases de datos de Oracle creadas en Exadata Cloud at Customer Gen 1 mediante herramientas de backend, dbaasapi y dbaascli.
  • Todas las versiones soportadas de Oracle Database en Exadata Cloud at Customer Gen 1 se siguen soportando y se migrarán a la misma versión principal en el destino. El entorno de Gen 2 se encontrará en la versión más reciente soportada de Exadata Cloud at Customer Gen 2 para el sistema operativo de VM de invitado y Oracle Grid Infrastructure.

Tenga en cuenta que lo siguiente no está dentro del ámbito del cambio de versión en la nube fuera de lugar al nuevo hardware de Gen 2:

  • Se espera que los despliegues de Exadata Cloud at Customer Gen 1 que utilicen funciones de este sistema que todavía no estén disponibles en Gen 2 no utilicen los procedimientos de cambio de versión hasta que la función correspondiente o un equivalente estén disponibles en Gen 2.
  • Dentro de este procedimiento, solo se incluye el cambio de versión de Exadata Cloud at Customer. El cambio de versión o la migración del propio OCC no se encuentra dentro del ámbito.
  • Puede revertir el cambio de versión mientras que el hardware principal y secundario permanezcan en su sitio. En función del uso de la aplicación y del tiempo de migración, es posible que se produzcan pérdidas de datos. Una vez que el hardware de Exadata Cloud at Customer Gen 1 se envíe de vuelta a Oracle, no podrá revertir el cambio de versión ni tampoco podrá volver a Exadata Cloud at Customer Gen 1.

Hardware y software necesarios para el cambio de versión en la nube fuera de lugar a una nueva infraestructura de Oracle Exadata Database Service on Cloud@Customer Gen2

Revise esta lista de comprobación para prepararse para el cambio de versión en la nube fuera de lugar a una nueva infraestructura de Gen 2:

  • Configure el entorno de Exadata Cloud at Customer Gen 2

    Un despliegue base en funcionamiento de Exadata Cloud at Customer Gen2 es un requisito para poder iniciar cualquier cambio de versión fuera de lugar de Exadata Cloud at Customer Gen1 a Gen2 fuera del lugar.

    Para obtener más información sobre la configuración de Exadata Cloud at Customer Gen 2, consulte Preparación para Exadata Cloud at Customer.

  • Configure el hardware para migrar las instancias de Oracle Database mediante Oracle Zero Downtime Migration (ZDM). Para obtener más información, consulte Preparación de un host para la instalación del software de Zero Downtime Migration.

  • Configure la red
    • Proporcione la ruta de acceso de red de los servidores de Exadata Cloud at Customer Gen 1 y Gen 2 a los servidores de ZDM que se utilizan para el cambio de versión.
    • Proporcione el acceso de red y el acceso SSH del servidor de ZDM a la infraestructura de Exadata Cloud at Customer correspondiente.
    • Para cualquier acceso de cliente a las bases de datos de destino, asegúrese de que haya una ruta de red disponible desde el host del cliente a las nuevas bases de datos desplegadas de Exadata Cloud at Customer Gen 2.
  • Software
    • El cambio de versión requerirá unas versiones mínimas de la pila de software, por lo que, antes del cambio de versión, instale la versión adecuada de Oracle Grid Infrastructure en la infraestructura de Exadata Cloud at Customer Gen 2 de destino.
    • Las versiones de Oracle Database soportadas en Exadata Cloud at Customer Gen 1 seguirán estando soportadas. En la infraestructura de destino de Gen 2, instale las versiones adecuadas del software de Oracle Database y los parches puntuales que existen en la base de datos de origen.
    • Complete todos los requisitos de los servidores de ZDM en cuanto a instalación, configuración, acceso de red y acceso SSH.
  • Seguridad
    • Exadata Cloud at Customer Gen 2 no utiliza la seguridad de Oracle Advanced Support Gateway (OASG), por lo que no se pueden solicitar logs de OASG.
  • Asegúrese de que la copia de seguridad automática no esté configurada en el destino de Gen 2 antes de la migración.

Uso de Oracle Zero Downtime Migration (ZDM) para migrar bases de datos de Oracle

Utilice ZDM para migrar bases de datos Oracle desde la infraestructura Gen1 de Exadata Cloud@Customer a Oracle Exadata Database Service on Cloud@Customer Gen2.

Para familiarizarse con las funciones de ZDM, consulte Configuración del software de Zero Downtime Migration. Como primer paso, descargue, instale y configure ZDM en el host identificado para el servidor de ZDM.

Zero Downtime Migration soporta la migración en línea y fuera de línea (copia de seguridad y recuperación). Para el cambio de versión de Exadata Cloud at Customer Gen1 a Gen2, se recomienda utilizar la migración física de ZDM. En concreto, se recomienda utilizar la Migración en línea con transferencia directa de datos (migración física en línea [MIGRATION_METHOD=ONLINE_PHYSICAL]) mediante transferencia directa de datos (DATA_TRANSFER_MEDIUM=DIRECT). Migración en línea con transferencia directa de datos está disponible con Zero Downtime Migration 21.2 y soporta la transferencia directa de datos para la metodología de migración física. Esta nueva función permite a los usuarios evitar el uso de un almacén intermedio para las copias de seguridad (normalmente NFS u OCI Object Storage). ZDM utiliza la duplicación de base de datos activa (para bases de datos 11.2) o la restauración a partir del servicio (para más de 12 bases de datos). Puede utilizar este método para migrar sus bases de datos de Exadata Cloud at Customer Gen1 a Exadata Cloud at Customer Gen2. A continuación se proporcionan ejemplos de línea de comandos y archivos de respuesta de referencia.

Para obtener más información, consulte:

  • Introducción a Zero Downtime Migration
  • Preparación para la migración de la base de datos
  • Migración de su base de datos con Zero Downtime Migration

Ejemplo 5-4 Duplicado activo

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

Ejemplo 5-5 Archivo de respuesta duplicado activo

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

Ejemplo 5-6 Restauración a partir del servicio

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

Ejemplo 5-7 Restauración a partir del archivo de respuesta del servicio

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=

Durante el cambio de versión en la nube fuera de lugar a la nueva infraestructura Gen2 de Oracle Exadata Database Service on Cloud@Customer

Supervisión: Oracle supervisará la instalación de Oracle Exadata Database Service on Cloud@Customer Gen2 desde el principio de la instalación, al igual que una instalación normal de Gen2.

Copias de seguridad: las copias de seguridad se realizan desde el cluster de VM de Exadata Cloud at Customer Gen 1 y seguirán funcionando durante el cambio de versión. Después de la migración a Oracle Exadata Database Service on Cloud@Customer Gen2, no se permiten copias de seguridad en Gen1 Oracle Cloud At Customer (OCC) Object Storage Service (OSS) y debe utilizar métodos de copia de seguridad soportados para Oracle Exadata Database Service on Cloud@Customer Gen2.

Tras el cambio de versión en la nube fuera de lugar a la nueva infraestructura Gen2 de Oracle Exadata Database Service on Cloud@Customer

La actualización trasladará sus recursos al plano de control de Gen 2 Cloud de Oracle Exadata Database Service on Cloud@Customer y al hardware de nueva generación.

Utilice la consola de OCI Gen2 para gestionar la infraestructura, los clusters, las bases de datos y los usuarios/grupos de Oracle Exadata Database Service on Cloud@Customer Gen2.

La pila de software se cambia a versiones más recientes, por ejemplo, de la siguiente manera:

  • Software de Exadata: 19.x o posterior
  • Oracle Grid Infrastructure: 19c
  • Sistema operativo de VM de invitado: Oracle Linux 7
  • Herramientas de DBaaS: 20.x
  • CSI: tendrá un nuevo CSI para su cuenta en la nube.
Nota

La pila de software se cambiará a las versiones más recientes que haya en el momento en que realice el cambio de versión en la nube fuera de lugar al nuevo hardware de Gen 2.

Aplicación de parches: el proceso de aplicación de parches de infraestructura y la consecuente notificación son diferentes en Gen 2. Para obtener más información, consulte Mantenimiento de un sistema Exadata Cloud at Customer.

Nota

Después de la migración a Exadata Cloud at Customer Gen 2, Oracle recomienda utilizar métodos de copia de seguridad soportados en Exadata Cloud at Customer Gen 2. Es su responsabilidad gestionar manualmente las copias de seguridad en Object Storage Service (OSS) de Oracle Cloud At Customer (OCC) Gen 1 y Oracle no ofrece este servicio a través de la consola, la API o la CLI de OCI.

Mejores prácticas para el cambio de versión en la nube fuera de lugar a la nueva infraestructura Gen2 de Oracle Exadata Database Service on Cloud@Customer

Para el cambio de versión, la herramienta que se recomienda utilizar es Oracle Zero Downtime Migration (ZDM).

Algunas de las mejores prácticas recomendadas en el contexto del uso de ZDM para el cambio de versión de Gen 1 a Gen 2 son las siguientes:

  • Aunque están soportados todos los métodos de migración física, se recomienda utilizar la Migración en línea con transferencia directa de datos.
    Nota

    No se recomienda utilizar OSS de Oracle Cloud At Customer Gen 1 ni OCI Object Storage para esta migración.
  • Defina ZDM_RMAN_COMPRESSION_ALGORITHM en LOW.
  • El directorio raíz de Oracle de la base de datos de destino debe estar en el mismo nivel de parches o en un nivel de parches superior al de la base de datos de origen.
  • El directorio raíz de Oracle de la base de datos de destino debe tener todos los parches puntuales, al igual que el directorio raíz de Oracle de origen.
  • Realice una ejecución de validación antes de la ejecución real.
  • En el caso de una base de datos de origen CDB, es necesario que todas las PDB del origen estén en línea.