Oracle Cloud Infrastructure
La modernización y operación de workloads empresariales requiere mucho más que una migración puntual. Requiere un modelo de Managed Services que acompañe todo el ciclo, desde el diseño y la preparación hasta la migración, el despliegue y la resolución de incidencias operativas.
En este artículo, compartimos el paso a paso de la migración de una base de datos Oracle 19c Multitenant, ejecutándose sobre Exadata On-Premises, hacia un Oracle Database System en Oracle Cloud Infrastructure (OCI) mediante Oracle Zero Downtime Migration (ZDM). La migración utilizó el método ONLINE_PHYSICAL, junto con RMAN, Data Guard y Direct Data Transfer.
Conocé cómo abordamos este tipo de proyectos y los principales desafíos técnicos que pueden surgir durante una migración.
📌 NOTA: Por tratarse de un caso real, algunos nombres de host, dominios y contraseñas del documento original fueron reemplazados por valores genéricos de ejemplo antes de publicar este artículo. La estructura de los comandos, parámetros y mensajes de error se mantiene sin cambios.
El desafío
El objetivo era migrar una base de datos Oracle 19c Multitenant desde un entorno Exadata on-premises hacia una base Oracle 19c ejecutándose en OCI.
La arquitectura de migración involucró tres componentes principales:
- Entorno origen: Oracle 19c sobre Exadata on-premises.
- Entorno destino: Oracle 19c Multitenant sobre OCI DB System.
- Servidor de migración: servidor dedicado para Oracle Zero Downtime Migration.
La estrategia seleccionada permitió mantener los entornos sincronizados mediante una configuración temporal de Data Guard y realizar posteriormente el switchover hacia OCI.
En este escenario, ZDM realizó la transferencia directa de los datafiles entre origen y destino, sin utilizar un staging intermedio en Object Storage.
De la migración a la gestión del workload
Este proyecto no se limita a demostrar que una base Oracle puede ser trasladada a OCI.
También permite mostrar las distintas capacidades que intervienen en el ciclo de vida de un workload empresarial:
Build
Preparación de la infraestructura y de los componentes necesarios para soportar el workload en OCI.
Migrate
Migración controlada del workload Oracle desde infraestructura on-premises hacia OCI.
Deploy
Configuración del entorno destino, networking, seguridad, TDE, Oracle Net y componentes requeridos por ZDM.
Run
Validación, monitoreo y seguimiento de la ejecución de la migración y de sus diferentes fases.
Manage
Resolución de incidentes, troubleshooting, validación de configuración y preparación del entorno para su operación continua.
Este tipo de trabajo requiere un modelo de Managed Services, donde la responsabilidad no termina cuando una aplicación o base de datos llega a la nube.
¿Cómo se realizó la migración?
1. Preparación del entorno Oracle
La base de datos origen era Oracle 19c Multitenant y fue preparada para soportar la migración física online.
Entre las validaciones realizadas se incluyeron:
- Configuración ARCHIVELOG.
- Estado de las PDBs.
- Configuración de TDE.
- Wallet y keystore.
- Master keys para CDB y PDBs.
- Configuración SPFILE.
- Compatibilidad entre origen y destino.
Para una migración física online, la alineación de las características del entorno origen y destino es especialmente importante.
Entre otros requisitos, deben considerarse el sistema operativo, versión de Oracle Database, edición, character set y configuración de SPFILE.
2. Preparación de OCI
En OCI se creó la base de datos destino que actuaría como placeholder durante el proceso de migración.
La preparación incluyó:
- Configuración de Oracle Database.
- Storage ASM.
- Parámetros de memoria.
- Configuración TDE.
- Wallet.
- Oracle Net.
- Acceso SSH.
- Conectividad entre origen, destino y servidor ZDM.
La preparación del target fue una parte fundamental del proyecto: una migración automatizada solamente puede ser tan confiable como los prerrequisitos sobre los que se ejecuta.
Networking y conectividad
Uno de los aspectos críticos del proyecto fue garantizar la conectividad entre los tres componentes de la arquitectura.
Se validaron principalmente dos canales:
SSH — TCP/22
Necesario para que ZDM pudiera administrar los servidores origen y destino.
Se configuró autenticación mediante claves SSH y se verificó la conectividad sin contraseña.
Oracle Net — TCP/1521
Necesario para la comunicación entre las bases de datos y la sincronización utilizada por Data Guard.
Durante el proyecto se comprobó que no era suficiente con validar solamente conectividad IP.
También era necesario garantizar la resolución de los nombres utilizados efectivamente por ZDM.
La importancia de validar antes de migrar
Una de las prácticas más importantes del proyecto fue ejecutar primero la evaluación de ZDM utilizando el parámetro -eval.
Esta etapa permite validar los principales prerrequisitos sin ejecutar todavía la migración.
En el proyecto, la evaluación permitió identificar problemas de conectividad y configuración antes de completar el proceso de migración.
El -eval finalizó correctamente antes de ejecutar el job definitivo.
Para un servicio de Managed Services, esta práctica refleja un principio fundamental:
Detectar y resolver los riesgos antes de intervenir sobre el workload.
Troubleshooting: cuando la documentación no alcanza
Uno de los principales aprendizajes del caso es que la automatización reduce el trabajo manual, pero no reemplaza el conocimiento especializado. Durante la migración surgieron problemas relacionados con resolución de nombres, configuración de TDE/wallets y particularidades del entorno OCI.
La resolución de estos incidentes requirió analizar logs, validar el estado de la base de datos y adaptar la configuración del entorno.
En conjunto, las experiencias muestran que una migración automatizada requiere validar no solo los prerrequisitos documentados, sino también la conectividad, la configuración criptográfica, el estado operativo de CDB/PDB y las convenciones específicas de la plataforma cloud.
La principal conclusión es que el éxito de este tipo de proyectos depende de combinar automatización + capacidad de troubleshooting + conocimiento de Oracle Database, Cloud Infrastructure y Operations.
Resultado
Después de resolver los problemas de conectividad, configuración de TDE y paths de wallet, la migración se ejecutó exitosamente.
El job de ZDM reportó:
La duración documentada del job fue de:
40 minutos y 31 segundosAl finalizar:
- La base de datos destino en OCI quedó como primary.
- Los datos fueron migrados desde el entorno on-premises.
- La configuración temporal de Data Guard fue eliminada por ZDM.
- El entorno quedó preparado para continuar con las actividades posteriores de validación y operación.
Migrar un workload Oracle a OCI requiere combinar conocimiento de base de datos, infraestructura cloud, networking, seguridad y operaciones.
En este caso, llevamos adelante una migración Oracle 19c desde Exadata on-premises hacia OCI utilizando Oracle Zero Downtime Migration, resolviendo durante el proceso problemas reales relacionados con resolución de nombres, TDE, master keys y configuración específica del entorno OCI.
El resultado fue una migración física online completada exitosamente, con una duración documentada de aproximadamente 40 minutos.
entender el workload, construir el entorno, migrarlo, desplegarlo, operarlo y resolver los problemas que aparecen en un entorno real requiere conocimiento técnico sobre el cual se construye una operación cloud confiable y sostenible.
