Migración a Oracle Exadata Database Service on Dedicated Infrastructure

En esta sección se describe cómo migrar las cargas de trabajo de Oracle Exadata a Oracle Exadata Database Service on Dedicated Infrastructure y migrar las aplicaciones VMware a Oracle Cloud VMware Solution.

Arquitectura

Esta arquitectura muestra una migración de bases de datos Oracle Exadata locales y aplicaciones VMware a Oracle Exadata Database Service on Dedicated Infrastructure y Oracle Cloud VMware Solution.

Con Oracle Zero Downtime Migration, automatice la migración de su base de datos mientras experimenta un tiempo de inactividad mínimo al migrar sus datos de la ubicación local a la nube.

Migre sus aplicaciones locales que se ejecutan en VMware a Oracle Cloud VMware Solution mediante herramientas VMware como HCX y vMotion. Oracle Cloud VMware Solution te ofrece una implantación totalmente automatizada de un centro de datos definido por software (SDDC) VMware en tu arrendamiento de OCI, que se ejecuta en instancias con hardware dedicado de OCI.

En el siguiente diagrama se ilustra esta arquitectura de referencia.

A continuación se muestra la descripción de migrate-vmware-cloud-solution-exadata-dedicated-architecture.png

Descripción de la ilustración migrate-vmware-cloud-solution-exadata-dedicated-architecture.png

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

Esta arquitectura soporta los siguientes componentes:

Región
Una región de Oracle Cloud Infrastructure es un área geográfica localizada que contiene uno o más centros de datos, denominados dominios de disponibilidad. Las regiones son independientes de otras regiones, y las grandes distancias pueden separarlas (entre países e incluso continentes).
Red virtual en la nube (VCN) y subred
Una VCN es una red definida por software y personalizable que se configura en una región de Oracle Cloud Infrastructure. Al igual que las redes de los centros de datos tradicionales, las redes virtuales le proporcionan un control completo de su entorno de red. Una VCN puede tener varios bloques de CIDR no superpuestos que puede cambiar después de crear la VCN. Puede segmentar una VCN en subredes, las cuales se pueden acotar a una región o a un dominio de disponibilidad. Cada subred está formada por un rango contiguo de direcciones que no se solapan con las demás subredes de la VCN. Puede cambiar el tamaño de una subred después de la creación. Una subred puede ser pública o privada.
Oracle Exadata Database Service on Dedicated Infrastructure
Oracle Exadata Database Service on Dedicated Infrastructure proporciona Oracle Exadata Database Machine como servicio en un centro de datos de OCI. El servicio Oracle Exadata Database Service on Dedicated Infrastructure puede alojar muchas bases de datos Oracle que se ejecutan en uno o más clusters de VM que se ejecutan en un solo rack de Exadata en una región de OCI. Oracle Exadata Database Service on Dedicated Infrastructure es una plataforma ideal para la consolidación de bases de datos.
Oracle Cloud VMware Solution Centro de datos definido por software (SDDC)
Oracle y VMware se han asociado para desarrollar una implantación del centro de datos definido por software (SDDC) certificado VMware para su uso en Oracle Cloud Infrastructure. Esta implantación, denominada Oracle Cloud VMware Solution, utiliza Oracle Cloud Infrastructure para alojar un SDDC VMware de alta disponibilidad. También permite una migración perfecta de todas sus cargas de trabajo del SDDC VMware locales a Oracle Cloud VMware Solution. Oracle Cloud VMware Solution contiene los siguientes componentes VMware:
- VMware vSphere ESXi
- VMware vSAN
- VMware vCenter
- VMware NSX-T
- VMware HCX (opcional)
Hardware dedicado
Un centro de datos definido por software (SDDC) de Oracle Cloud VMware Solution contiene servidores con hardware dedicado que alojan Oracle Cloud VMware Solution. El servidor con hardware dedicado admite aplicaciones que requieren un gran número de núcleos, grandes cantidades de memoria y un gran ancho de banda (como Oracle Cloud VMware Solution). Puede desplegar Oracle Cloud VMware Solution en servidores con hardware dedicado y configurar máquinas virtuales con mejoras significativas en el rendimiento en comparación con otras nubes públicas y centros de datos locales.
Gateway de servicio
El gateway de servicios proporciona acceso desde una VCN a otros servicios, como Oracle Cloud Infrastructure Object Storage. El tráfico desde la VCN al servicio Oracle recorre el tejido de red de Oracle y no Internet.
Gateway de enrutamiento dinámico (DRG)
El DRG es un enrutador virtual que proporciona una ruta para el tráfico de red privada entre las redes virtuales de la misma región, entre una VCN y una red fuera de la región, como una VCN de otra región de Oracle Cloud Infrastructure, una red local o una red de otro proveedor en la nube.
FastConnect
Oracle Cloud Infrastructure FastConnect proporciona una forma sencilla de crear una conexión dedicada y privada entre el centro de datos y Oracle Cloud Infrastructure. FastConnect proporciona opciones de mayor ancho de banda y una experiencia de red más fiable en comparación con las conexiones basadas en Internet.
Almacenamiento de archivos
OCI File Storage se utiliza durante la migración lógica para importar la base de datos migrada desde un sistema de archivos compartido.
Object Storage
OCI Object Storage se utiliza para la migración lógica y física del almacenamiento temporal durante la migración.

Antes de empezar

Antes de comenzar, compruebe las versiones de los principales componentes utilizados en esta configuración y revise la documentación del producto para obtener más información.

Requisitos de revisión

Asegúrese de que la base de datos origen ejecuta Oracle Database versión 19.18 Enterprise Edition o posterior.
La base de datos destino debe ser Oracle Exadata Database Service on Dedicated Infrastructure X8 o posterior, en Oracle Database versión 19.18 Enterprise Edition o superior.
Oracle Zero Downtime Migration debe ser de la versión 21.4 o superior.
El almacenamiento intermedio debe incluir OCI Object Storage, Oracle ZFS Storage Appliance (NAS) y OCI File Storage.

Revisar documentación

En este manual de soluciones se describe cómo migrar las cargas de trabajo de la base de datos. Consulte la siguiente solución para obtener información sobre cómo migrar las cargas de trabajo de VMware. Los recursos adicionales son útiles para el contexto, los detalles y la referencia para la migración de la base de datos.

Descubra cómo migrar los componentes VMware de la carga de trabajo a Oracle Cloud VMware Solution.

Migración de las cargas de trabajo locales de VMware a la nube

Revise los recursos de Oracle Zero Downtime Migration:

Revise los recursos de migración física:

Revise los recursos de migración lógica:

Revise los recursos de Oracle Database:

Acerca de los productos y los roles necesarios

Esta solución requiere los siguientes productos:

Oracle Cloud Infrastructure Identity and Access Management
Recursos informáticos de OCI
OCI Object Storage
Almacenamiento de archivos de OCI
Oracle Zero Downtime Migration
Oracle Exadata
Oracle Exadata Database Service on Dedicated Infrastructure

Estos son los roles necesarios para cada producto.

Nombre de producto: Rol	Necesario para...
Oracle Cloud Infrastructure Identity and Access Management: `OCI_user`	Crear tokens de autenticación para migración física Crear claves de API para migración lógica
Recursos informáticos de OCI: `admin`	Cree una instancia de OCI Compute para ejecutar el software de Oracle Zero Downtime Migration
Almacenamiento de objetos de OCI: `Storage Admin`	Crear cubos de OCI Object Storage para migración lógica y física
Almacenamiento de archivos de OCI: `Storage Admin`	Crear OCI File Storage para migración lógica
Oracle Zero Downtime Migration: `opc`	Cree `zdmuser` para instalar y ejecutar el software Oracle Zero Downtime Migration
Oracle Zero Downtime Migration: `zdmuser`	Instalar el software Oracle Zero Downtime Migration Ejecución de Oracle Zero Downtime Migration
Oracle Exadata: `root/sudoer user`	Monte el recurso compartido del sistema de archivos de red desde el dispositivo de almacenamiento conectado a la red para exportar la base de datos para las migraciones lógicas. Activar SSH sin contraseña desde la máquina virtual de Oracle Zero Downtime Migration Ejecute los comandos `sudo` para instalar el agente de software de Oracle Zero Downtime Migration Ejecute comandos `sudo` para realizar una copia de seguridad o exportar la base de datos
Base de datos de Oracle Exadata: `sys/system`	Realizar copias de seguridad de datos mediante Oracle Recovery Manager (RMAN) para la migración física Ejecutar pump de datos para exportar la base de datos para la migración lógica
Oracle Exadata Database Service on Dedicated Infrastructure: `Database Admin`	Crear base de datos de destino de Oracle Exadata Database Service on Dedicated Infrastructure
Nodos de cluster de VM de Oracle Exadata Database Service on Dedicated Infrastructure: `opc`	Monte el recurso compartido del sistema de archivos de red desde OCI File Storage para importar la base de datos para migraciones lógicas. Activar SSH sin contraseña desde la máquina virtual de Oracle Zero Downtime Migration Instalar el agente de software de Oracle Zero Downtime Migration Ejecute los comandos `sudo` para restaurar o importar la base de datos
Base de datos de Oracle Exadata Database Service on Dedicated Infrastructure: `sys/system`	Restauración de datos mediante Oracle Recovery Manager (RMAN) para migraciones físicas Ejecutar pump de datos para importar la base de datos para la migración lógica

Consulte Productos, soluciones y servicios de Oracle para obtener lo que necesita.

Acerca de la migración lógica y física

Oracle Zero Downtime Migration soporta dos tipos de migraciones de base de datos de Oracle Exadata a Oracle Exadata Database Service on Dedicated Infrastructure: migración lógica y migración física.

La migración lógica utiliza una combinación de Oracle Data Pump y Oracle GoldenGate, mientras que la migración física utiliza una combinación de Oracle Recovery Manager (RMAN) y Oracle Data Guard. En la siguiente tabla se explican los escenarios en los que se debe utilizar una migración lógica o física.

Migración lógica	Migración física
Se recomienda cuando se migran algunas bases de datos o esquemas de conexión.	Se recomienda cuando se migran bases de datos completas. Por ejemplo, las bases de datos de contenedor con todas las bases de datos conectables o la migración a la nube.
Se pueden migrar bases de datos de conexión (PDB) o esquemas seleccionados.	Las bases de datos de contenedor se migrarán a bases de datos de contenedor y las bases de datos sin contenedor se migrarán a bases de datos sin contenedor.
La contraseña `Sys` en el origen y el destino puede ser diferente. Los nombres de base de datos entre el origen y el destino pueden ser diferentes.	La contraseña `Sys` y el nombre de la base de datos tanto en el origen como en el destino deben ser idénticos. DB_UNIQUE_NAME en el origen y el destino deben ser diferentes.
Las bases de datos se pueden actualizar durante la migración.	Las bases de datos no se pueden actualizar como parte de la migración.

Migración mediante migración lógica

En esta sección, se describe cómo realizar una migración lógica fuera de línea. Para la migración en línea, consulte la sección Revisar documentación.

Antes de realizar la migración, tenga en cuenta lo siguiente.

La base de datos origen de Oracle Exadata no tiene que estar cifrada. Oracle Zero Downtime Migration cifrará la base de datos destino durante la migración.
Las bases de datos de origen y destino no tienen que tener la misma contraseña sys, contraseña de cartera, versión de base de datos, nombre de base de datos y nivel de parche.
Oracle Zero Downtime Migration permite migrar determinadas bases de datos de conexión (PDB) o esquemas a bases de datos de conexión en Oracle Exadata Database Service on Dedicated Infrastructure.
Se necesita un sistema de archivos compartido para las migraciones lógicas. Durante la migración lógica, Oracle Zero Downtime Migration no exportará los datos directamente a OCI Object Storage. En la base de datos de Exadata de origen, Oracle Zero Downtime Migration exporta datos a un sistema de archivos compartido (ya sea sistema de archivos de red u Oracle Advanced Cluster File System). A continuación, los datos exportados se cargan en OCI Object Storage. A continuación, Oracle Zero Downtime Migration mueve los volcados de datos de OCI Object Storage a OCI File Storage. Por último, Oracle Exadata Database Service on Dedicated Infrastructure puede importar los datos desde OCI File Storage a través de un sistema de archivos de red.
Oracle Exadata local puede ejecutar bases de datos de instancia única y RAC. Oracle Exadata Database Service on Dedicated Infrastructure ejecuta bases de datos RAC. Durante la migración de la base de datos, Oracle Zero Downtime Migration convierte una instancia única en bases de datos RAC cuando es necesario.
En Oracle Exadata local, el uso del cifrado de datos transparente de Oracle para cifrar bases de datos es opcional. Al migrar bases de datos de Exadata a Oracle Exadata Database Service on Dedicated Infrastructure, la base de datos de destino de Oracle Exadata Database Service on Dedicated Infrastructure siempre se cifrará.
En los siguientes pasos se supone que hay conectividad de red directa entre el centro de datos donde está instalado Oracle Exadata y la red virtual en la nube de OCI donde Oracle Exadata Database Service on Dedicated Infrastructure y la máquina virtual Oracle Zero Downtime Migration está configurada (mediante VPN FastConnect o IPSec, como se muestra en el diagrama de arquitectura).

Los siguientes pasos describen cómo realizar una migración lógica fuera de línea.

En la consola de OCI, cree una instancia informática en la misma VCN en la que se configurará la base de datos de destino de Oracle Exadata Database Service on Dedicated Infrastructure.
Esta instancia informática puede ser cualquier unidad, con al menos dos OCPU y 16 GB de RAM, que ejecutan el sistema operativo Oracle Linux 7.9. Esta máquina virtual se utilizará para ejecutar el software Oracle Zero Downtime Migration.
Siga la documentación de instalación de Oracle Zero Downtime Migration de la sección Revisar documentación para descargar e instalar el software Oracle Zero Downtime Migration 21.4 en la instancia informática de OCI.
Ejecute el software Oracle Zero Downtime Migration como zdmuser.
Conéctese como zdmuser a la instancia informática que ejecuta el software Oracle Zero Downtime Migration y genere un par de claves ssh. Active ssh sin contraseña de la cuenta zdmuser a todos los nodos de la base de datos Exadata de origen (root, privilege-sudoer user) y a todos los nodos de cluster de VM de la cuenta opc user de la base de datos Oracle Exadata Database Service on Dedicated Infrastructure de destino.
Asegúrese de que la máquina virtual de Oracle Zero Downtime Migration se pueda comunicar con los hosts de la base de datos de origen mediante el nombre de host y la dirección IP. Verifique lo siguiente:
- Modifique el solucionador de DNS de VCN o el archivo /etc/hosts en la VM de Oracle Zero Downtime Migration si es necesario.
- Verifique que hay una regla de seguridad que permite a la máquina virtual de Oracle Zero Downtime Migration conectarse a la base de datos de origen en el puerto de listener por defecto 1521 y el puerto SSH 22.
- Asegúrese de que la máquina virtual de Oracle Zero Downtime Migration pueda acceder a los hosts de destino de Oracle Exadata Database Service on Dedicated Infrastructure en el puerto de listener por defecto 1521 y el puerto SSH 22.
En Oracle ZFS Storage Appliance, o en el dispositivo de almacenamiento conectado a la red, cree un recurso compartido del sistema de archivos de red que se utilizará como marcador de posición para los volcados de datos de la base de datos mientras avanza la migración.
Monte el recurso compartido del sistema de archivos de red en todos los nodos de la base de datos de Exadata.
Asegúrese de que todos los usuarios tienen permisos de lectura, escritura y ejecución (rwx). Tome nota del punto de montaje.
En la consola de OCI, cree un almacenamiento de archivos de OCI.
Observe el destino de montaje, la exportación y la dirección IP. La dirección IP por defecto está en la red de copia de seguridad de Oracle Exadata Database Service on Dedicated Infrastructure.
Utilice la dirección IP y exporte desde el paso 7 para montar este almacenamiento de archivos a través del sistema de archivos de red en todos los nodos del cluster de VM de Oracle Exadata Database Service on Dedicated Infrastructure.
Asegúrese de que la red virtual en la nube incluye una política de seguridad para permitir el protocolo del sistema de archivos de red en la red de copia de seguridad de Oracle Exadata Database Service on Dedicated Infrastructure. Observe el punto de montaje.
Cree una base de datos Oracle Exadata Database Service on Dedicated Infrastructure de destino mediante la consola de OCI o la API de REST. Configure la base de datos de la siguiente manera:
- La nueva base de datos destino puede tener un nombre diferente al de la base de datos origen.
- La nueva base de datos puede ser una versión más reciente que la base de datos origen.
- Proporcione una contraseña para el usuario admin. Anote la contraseña.
- No seleccione un destino de copia de seguridad ni active las copias de seguridad automáticas durante la creación de la base de datos. Estos valores se pueden activar después de la migración de la base de datos.
Anote el OCID de la base de datos después de crearla.
En la consola de OCI, cree un cubo de OCI Object Storage si aún no existe uno.
Tenga en cuenta la URL de Swift, el espacio de nombres de almacenamiento de objetos y el nombre del cubo.
Utilice la consola de OCI para crear una clave de API para el usuario de OCI propietario de la base de datos de destino de Oracle Exadata Database Service on Dedicated Infrastructure y también tiene permisos para cargar datos en el cubo de OCI Object Storage creado en el paso 10.
Anote el OCID de usuario, el OCID de arrendamiento, la huella y la región de OCI. Guarde las claves privadas y públicas correspondientes en los archivos PEM. Oracle Zero Downtime Migration utilizará esta clave de API para conectarse a OCI y obtener información de la base de datos destino durante la migración de la base de datos, así como para cargar volcados de datos en OCI Object Storage.
Copie los archivos PEM del paso anterior en la máquina virtual de Oracle Zero Downtime Migration.
Conéctese como usuario sys a la base de datos Exadata de origen para asegurarse de que el parámetro Streams_Pool_Size está definido en al menos 2G, por ejemplo:
```
SQL>show parameter streams_pool_size;
SQL>alter system set streams_pool_size=2G scope=both SID=’*’;                  
```
Utilice la plantilla de archivo de respuesta de migración lógica de Oracle Zero Downtime Migration incluida con Zero Downtime Migration para crear un archivo de respuesta para la migración. Los parámetros clave son:
- TARGETDATABASE_OCID: OCID de la base de datos destino de 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/nombre de host del primer nodo en la base de datos de Exadata de origen.
- SOURCEDATABASE_CONNECTIONDETAILS_PORT: 1521
- SOURCEDATABASE_CONNECTIONDETAILS_SERVICENAME: nombre de servicio de la PDB de origen o de la base de datos sin contenedor (no CDB). Utilice lsnrctl para buscar.
- OCIAUTHENTICATIONDETAILS_USERPRINCIPAL_TENANTID: OCID de arrendamiento del paso 11.
- OCIAUTHENTICATIONDETAILS_USERPRINCIPAL_USERID: OCID de usuario del paso 11.
- OCIAUTHENTICATIONDETAILS_USERPRINCIPAL_FINGERPRINT: huella digital del paso 11.
- OCIAUTHENTICATIONDETAILS_PRIVATEKEYFILE: ruta de archivo al archivo PEM de clave privada en el servidor de Oracle Zero Downtime Migration desde el paso 12.
- OCIAUTHENTICATIONDETAILS_REGIONID: ID de región de OCI para el usuario de OCI del paso 11.
- TARGETDATABASE_CONNECTIONDETAILS_PORT: 1521
- TARGETDATABASE_CONNECTIONDETAILS_SERVICENAME: nombre de servicio para la base de datos de conexión de destino en la base de datos de destino. Utilice lsnrctl para buscar.
- SOURCECONTAINERDATABASE_ADMINUSERNAME: system
- SOURCECONTAINERDATABASE_CONNECTIONDETAILS_HOST: IP/nombre de host del primer nodo en la base de datos de Exadata de origen.
- SOURCECONTAINERDATABASE_CONNECTIONDETAILS_PORT: 1521
- SOURCECONTAINERDATABASE_CONNECTIONDETAILS_SERVICENAME: nombre del servicio para la base de datos de contenedor de origen en la base de datos de Exadata. Utilice lsnrctl para buscar).
- DATAPUMPSETTINGS_JOBMODE: SCHEMA
- DATAPUMPSETTINGS_FIXINVALIDOBJECTS: TRUE
- DATAPUMPSETTINGS_EXPORTDIRECTORYOBJECT_NAME: mig
- DATAPUMPSETTINGS_EXPORTDIRECTORYOBJECT_PATH: punto de montaje del sistema de archivos de red del paso 6.
- DATAPUMPSETTINGS_IMPORTDIRECTORYOBJECT_NAME: mig.
- DATAPUMPSETTINGS_IMPORTDIRECTORYOBJECT_PATH: punto de montaje del sistema de archivos de red del paso 8.
- DATAPUMPSETTINGS_CREATEAUTHTOKEN: TRUE
- DATAPUMPSETTINGS_DATAPUMPPARAMETERS_IMPORTPARALLELISMDEGREE: 4
- DATAPUMPSETTINGS_DATAPUMPPARAMETERS_EXPORTPARALLELISMDEGREE: 4
- DATAPUMPSETTINGS_DATABUCKET_NAMESPACE: espacio de nombres de OCI Object Storage del paso 10.
- DATAPUMPSETTINGS_DATABUCKET_BUCKETNAME: nombre del cubo de OCI Object Storage del paso 10.
- TABLESPACEDETAILS_AUTOCREATE: TRUE
- TABLESPACEDETAILS_USEBIGFILE: TRUE
- TABLESPACEDETAILS_EXTENTSIZEMB: 512
- EXCLUDEOBJECTS-1: owner:PDBADMIN
Ejecute un trabajo de migración en seco de ejecución de Oracle Zero Downtime Migration (-eval) para validar todos los requisitos para la migración. De esta forma, se ejecuta la herramienta Cloud Pre-Migration Advisor Tool (CPAT) para validar que la base de datos origen es adecuada para la migración a Oracle Exadata Database Service on Dedicated Infrastructure mediante la migración lógica de Oracle Zero Downtime Migration. Abordar los problemas notificados por CPAT antes de continuar. Por ejemplo:
```
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
```
Este comando solicita la contraseña del usuario sys de las bases de datos de origen y destino.

Después de una migración correcta de ejecución simulada, continúe con el siguiente paso.

Una vez que la migración de ejecución simulada se haya realizado correctamente, ejecute el trabajo Oracle Zero Downtime Migration. Por ejemplo:

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

Este comando solicita la contraseña del usuario sys de las bases de datos de origen y destino.

Migración mediante migración física

En esta sección, se describe cómo realizar una migración física fuera de línea. Para la migración en línea, consulte la sección Revisar documentación.

Antes de realizar la migración física, tenga en cuenta lo siguiente.

Hay un nuevo parámetro para la gestión de cifrado de tablespace en Oracle Database 19.16. Este parámetro puede provocar conflictos para migraciones físicas. Revise la gestión de cifrado de tablespaces en la sección Revisar documentación para obtener más información.
Oracle Exadata local puede ejecutar bases de datos de instancia única y RAC. Oracle Exadata Database Service on Dedicated Infrastructure ejecuta bases de datos RAC. Durante la migración de la base de datos, Oracle Zero Downtime Migration convierte una instancia única en bases de datos RAC cuando es necesario.
Se debe definir una cartera de cifrado de datos transparente (TDE) en la base de datos de origen antes de la migración, incluso si la base de datos de origen no está cifrada.
En Oracle Exadata local, el uso del cifrado de datos transparente de Oracle para cifrar bases de datos es opcional. Al migrar bases de datos de Exadata a Oracle Exadata Database Service on Dedicated Infrastructure, la base de datos de destino de Oracle Exadata Database Service on Dedicated Infrastructure siempre se cifrará.
En los siguientes pasos se supone que hay conectividad de red directa entre el centro de datos donde está instalado Exadata, y la red virtual en la nube de OCI donde Oracle Exadata Database Service on Dedicated Infrastructure y la máquina virtual Oracle Zero Downtime Migration está configurada (mediante FastConnect o VPN IPSec, como se muestra en el diagrama de arquitectura).
La base de datos origen de Oracle Exadata no tiene que estar cifrada. Oracle Zero Downtime Migration cifrará la base de datos destino durante la migración.
La contraseña sys, la contraseña de cartera, la versión de la base de datos y el nivel de parche en las bases de datos de origen y destino deben ser iguales.
Oracle Zero Downtime Migration migrará base de datos de contenedor (CDB) a CDB y no a CDB a no CDB.
Oracle Zero Downtime Migration utiliza Oracle Database Backup Cloud Service para realizar una copia de seguridad de la base de datos Exadata de origen en OCI Object Storage. A continuación, Oracle Zero Downtime Migration restaura la base de datos destino desde esta copia de seguridad.

Los siguientes pasos describen cómo realizar una migración física fuera de línea.

En la consola de OCI, cree una instancia informática en la misma subred en la que se configurará la base de datos destino.
Esta instancia informática puede ser cualquier unidad, con al menos dos OCPU y 16 GB de RAM, que ejecutan el sistema operativo Oracle Linux 7.9. Esta máquina virtual se utilizará para ejecutar el software Oracle Zero Downtime Migration.
Siga la documentación de instalación de Oracle Zero Downtime Migration de la sección Revisar documentación para descargar e instalar el software Oracle Zero Downtime Migration 21.4 en la instancia informática de OCI.
Ejecute el software Oracle Zero Downtime Migration como zdmuser.
Conéctese como zdmuser a la instancia informática que ejecuta el software Oracle Zero Downtime Migration y genere un par de claves ssh. Active ssh sin contraseña de la cuenta zdmuser a todos los nodos de la base de datos Exadata de origen (root, privilege-sudoer user) y a todos los nodos de cluster de VM de la cuenta opc user de la base de datos de destino.
Asegúrese de que la máquina virtual de Oracle Zero Downtime Migration se pueda comunicar con los hosts de la base de datos de origen mediante el nombre de host y la dirección IP. Verifique lo siguiente:
- Modifique el solucionador de DNS de VCN o el archivo /etc/hosts en la VM de Oracle Zero Downtime Migration si es necesario.
- Verifique que hay una regla de seguridad que permite a la máquina virtual de Oracle Zero Downtime Migration conectarse a la base de datos de origen en el puerto de listener por defecto 1521 y el puerto SSH 22.
- Asegúrese de que la máquina virtual de Oracle Zero Downtime Migration pueda acceder a los hosts de base de datos de destino en el puerto de listener por defecto 1521 y el puerto SSH 22.
En la consola de OCI, cree un cubo de OCI Object Storage si aún no existe uno.
Tenga en cuenta la URL de Swift, el espacio de nombres de almacenamiento de objetos y el nombre del cubo.
En la consola de OCI, cree un token de autenticación para OCI_user cargando datos en el cubo de OCI Object Storage.
Tenga en cuenta que el token no se volverá a mostrar.
Asegúrese de que las políticas de seguridad permiten a OCI_user cargar datos en el cubo de OCI Object Storage.
Cree una base de datos destino de Oracle Exadata Database Service on Dedicated Infrastructure mediante la GUI de OCI o la API de REST. Configure la base de datos de destino de la siguiente manera:
- Las bases de datos de destino y origen deben tener los mismos nombres, pero DB_UNIQUE_NAME diferente.
- La contraseña sys, la contraseña de cartera, la versión de la base de datos, el nivel de parche y la versión del archivo de zona horaria en las bases de datos de origen y destino deben ser iguales.
- No seleccione un destino de copia de seguridad ni active las copias de seguridad automáticas. Esta configuración se puede activar después de migrar la base de datos.
Verifique que la base de datos origen esté configurada en modo de archive log. Si el archive log no está activado, consulte Activar modo de archive log a continuación.
Si la base de datos origen no está cifrada, consulte Configuración de un almacén de claves de cifrado de datos transparente (TDE) a continuación. No es necesario cifrar los datos, solo se necesita el almacén de claves de TDE para la migración física. Asegúrese de que la contraseña del almacén de claves (cartera) es la misma que la contraseña de sys/cartera utilizada para crear la base de datos destino en Oracle Exadata Database Service on Dedicated Infrastructure.
Cree un archivo de respuesta para Oracle Zero Downtime Migration para ejecutar la migración. Los parámetros clave incluyen:
- TGT_DB_UNIQUE_NAME: nombre único de la base de datos para la base de datos de destino Oracle Exadata Database Service on Dedicated Infrastructure.
- MIGRATION_METHOD: OFFLINE_PHYSICAL o ONLINE_PHYSICAL.
- DATA_TRANSFER_MEDIUM: OSS
- PLATFORM_TYPE: EXACS
- HOST: URL de Swift para el espacio de nombres de OCI Object Storage del paso 5 con el formato: https://swiftobjectstorage.<region>.oraclecloud.com/v1/<namespace>>. Por ejemplo:
```
https://switfobjectstorage.us-phoenix-1.oraclecloud.com/v1/axwytvijqqld
```
- OPC_CONTAINER: nombre del cubo de OCI Object Storage del paso 4.
- SHUTDOWN_SRC: TRUE

Ejecute un trabajo de migración en seco de ejecución de Oracle Zero Downtime Migration (-eval) para validar todos los requisitos para la migración. Por ejemplo:

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

Este comando solicita dos contraseñas. La primera contraseña es la contraseña sys para la base de datos origen. La segunda contraseña es la contraseña OCI_user para el usuario que carga datos en el cubo de OCI Object Storage. No introduzca la contraseña de usuario aquí, en su lugar, introduzca el token de autenticación del paso 6.

Después de una correcta ejecución simulada, continúe con el siguiente paso.

Ejecute el trabajo Oracle Zero Downtime Migration. Por ejemplo:

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”

Se completó la migración física fuera de línea.

Activar Modo Archivelog

El modo de archive log debe estar activado en la base de datos de origen para las migraciones físicas de Oracle Zero Downtime Migration. En estos pasos se describe cómo configurar el modo Archivelog en la base de datos origen.

Valide que la base de datos origen no esté configurada en modo de archive log.
```
SQL> select log_mode from v$database;
LOG_MODE
------------
NOARCHIVELOG
```

Configure el destino del archivo log de la base de datos origen. Dado que esta configuración es para una base de datos que se ejecuta en Exadata, el destino de archive log debe ser el grupo de discos de 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

Cierre la base de datos.
```
$ srvctl stop database -d db_name
```
Inicie el montaje de la base de datos en el primer nodo.
```
SQL> startup mount;
ORACLE instance started.
```
Active el modo Archivelog.
```
alter database archivelog;
```
Abra la base de datos.
```
alter database open;
```

Verifique que la base de datos está en modo 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

Reinicie la base de datos en el segundo nodo.

$ srvctl start instance -d db_name -n hostname_node2

Verifique que las bases de datos de conexión están en modo abierto, de lectura y escritura en ambos nodos. Si las bases de datos de conexión no están abiertas, abra las bases de datos de conexión en ambos nodos y guarde el estado.
```
SQL> Alter pluggabale database pdb_name open instances=all;
SQL>Alter pluggable database pdb_name save state instances=all;
```

Configuración de un almacén de claves de cifrado de datos transparente (TDE)

Las migraciones físicas de Oracle Zero Downtime Migration requieren un almacén de claves/cartera de cifrado TDE auto_login (incluso si la base de datos de origen no está cifrada). Este almacén de claves se debe configurar con la misma contraseña que el almacén de claves de la base de datos destino. En estos pasos se describe cómo configurar un almacén de claves en la base de datos origen.

Compruebe si hay una ubicación de almacén de claves por defecto configurada para la base de datos.

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>

Esta salida muestra que no hay ningún almacén de claves ni cartera configurados.

Defina la variable TNS_ADMIN para el usuario oracle en ambos nodos de Exadata.
```
$ORACLE_HOME/network/admin/db_name
```
Cree un directorio para almacenar el archivo sqlnet.ora en ambos nodos de Exadata a los que apunta TNS_ADMIN.
```
mkdir -p $ORACLE_HOME/network/admin/db_name
```
Cree el archivo sqlnet.ora en el directorio al que apunta TNS_ADMIN con el siguiente contenido en ambos nodos de Exadata.
```
ENCRYPTION_WALLET_LOCATION=(SOURCE=(METHOD=FILE)
 (METHOD_DATA=(DIRECTORY=/u01/app/oracle/admin/db_name/wallet)))
```
Cree un directorio para almacenar el almacén de claves o la cartera en la ubicación a la que apunta sqlnet.ora en ambos nodos de Exadata.
```
$mkdir -p $/u01/app/oracle/admin/db_name/wallet
```
En el primer nodo, cree el almacén de claves protegido con una contraseña.
El almacén de claves de la base de datos destino también se debe configurar con esta contraseña.
```
SQL>administer key management create keystore '/u01/app/oracle/admin/db_name/wallet' identified by keystore_password;
```
En el primer nodo, abra el almacén de claves.
Si la base de datos origen no es una CDB, elimine container = ALL.
```
SQL> ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY keystore_password container = ALL;
```
Cree una copia de seguridad para el almacén de claves.
Si la base de datos origen no es una CDB, elimine container = ALL.
```
SQL> ADMINISTER KEY MANAGEMENT SET KEY IDENTIFIED BY keystore_password with backup container = ALL;
```

Verifique que se haya creado y realizado una copia de seguridad del almacén de claves.

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…

Cree un almacén de claves auto_login a partir del almacén de claves creado en el paso 7.

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

Cierre el almacén de claves del paso 7.

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

Verifique que el almacén de claves auto_login aún está abierto.

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

Cree archivos de cartera del nodo 1 al nodo 2.

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

Reinicie la base de datos en ambos nodos de 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

Verifique que la cartera auto_login está abierta en ambos nodos.

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>

Verifique que las bases de datos de conexión están en modo abierto, de lectura y escritura en ambos nodos. Si las bases de datos de conexión no están abiertas, abra las bases de datos de conexión en ambos nodos y guarde el estado.
```
SQL> Alter pluggabale database pdb_name open instances=all;
SQL>Alter pluggable database pdb_name save state instances=all;
```