Antes de Empezar
Antes de empezar a migrar recursos y aplicaciones, tenga en cuenta las opciones de migración y aprovisione y migre las bases de datos de aplicaciones necesarias.
Puede provisionar bases de datos de aplicaciones como bases de datos independientes o como bases de datos de conexión (PDB) dentro de la base de datos de contenedor (CDB) de un solo sistema de base de datos.
Se admite tanto Oracle Grid Infrastructure (que admite bases de datos de varios nodos) como Logical Volume Manager.
Nota:
Para utilizar herramientas de migración de base de datos como Migración sin Tiempo de Inactividad (ZDM), la contraseña SYS de la base de datos destino debe ser la misma que la contraseña SYS de la base de datos origen que se va a migrar.Hay una serie de estrategias de migración que puede utilizar, en función de la complejidad de la carga de trabajo y de los requisitos de tiempo de inactividad.
Para obtener más información sobre el provisionamiento de una base de datos, consulte Provisión de una Base de Datos de Máquina Virtual Anteriormente en este documento.
Acerca de la Migración de Cargas de Trabajo
En esta sección se presenta una serie de escenarios comunes de migración.
Un juego de opciones migra las cargas de trabajo locales a un dominio recién creado en Oracle Cloud Infrastructure:
- Migre manualmente las cargas de trabajo mediante la consola del administrador de WebLogic para desplegar recursos y uno de los métodos siguientes para desplegar aplicaciones:
- Consola del Administrador de WebLogic
- Herramientas de despliegue de JDeveloper
- Migrar cargas de trabajo mediante el despliegue de herramientas de WebLogic (WLDT).
- Migrar cargas de trabajo mediante WebLogic Scripting Tool dirigida a archivos de comandos de despliegue de aplicaciones existentes al nuevo dominio.
Otra opción es actualizar la herramienta del servidor de WebLogic que utiliza para desplegar dominios locales (como los scripts de WebLogic o los archivos del modelo de despliegue de herramientas de WebLogic) y dirigirlos a Oracle Cloud Infrastructure para crear un nuevo dominio y volver a desplegar aplicaciones.
Migración de Bases de Datos Oracle a Oracle Cloud Infrastructure
Antes de migrar bases de datos Oracle o noOracle desde un centro de datos local a Oracle Cloud Infrastructure, revise las siguientes consideraciones, requisitos y procesos de evaluación.
Consideraciones
Esta sección se aplica a la migración de bases de datos Oracle locales a Oracle Cloud Infrastructure, que incluye las plataformas de bases de datos que se muestran en la sección anterior. Antes de empezar cualquier esfuerzo de migración, comprenda la carga de trabajo, las restricciones y cualquier dependencia de la base de datos individual.
- ¿Cuál es la versión actual de esta base de datos?
- ¿Cuántas bases de datos de esta versión se van a migrar?
- ¿Cuántas bases de datos están vinculadas a una línea de negocio específica (LOB)?
- ¿Hay bases de datos en plataformas que no son Linux? , es decir, habrá una migración cruzada de orden?
- ¿Hay bases de datos dependientes que necesiten migrar de forma conjunta?
- ¿Hay bases de datos de terceros (noOracle) para migrar y qué versiones (por ejemplo, SQL Server 2016)?
- Para la base de datos de prueba y desarrollo, se migrarán todas las copias o sólo la copia maestra.
- ¿Cuánto más grandes son el espacio total en disco y el espacio para los datos en GB/TB?
- ¿Utilizará FastConnect o VPN para la conectividad de red a Oracle Cloud? El ancho de banda y el tamaño de la base de datos controlarán principalmente la solución de migración.
Opciones de Migración
Existen muchos métodos para migrar bases de datos Oracle de locales a Oracle Cloud Infrastructure. Cada método depende del objetivo de punto de recuperación de negocio (RPO), el objetivo de tiempo de recuperación (RTO) y el acuerdo global de nivel de servicio de disponibilidad (SLA). Los administradores de migración deben evaluar y asignar estos acuerdos de negocio con los métodos adecuados.
Oracle Maximum Availability Architecture (MAA) abarca específicamente estas opciones y métodos. En la siguiente tabla se tratan brevemente.
| Solución | Complejidad | Granularidad de migración | Tipo de Migración (Física o Lógica) | Esfuerzo de despliegue general | Modelo de Migración | Casos de uso de la migración de claves |
|---|---|---|---|---|---|---|
| Importación y Exportación Convencional de Pump de Datos | Bajo | Media | Lógicas | Alta | En Línea/Punto en el Tiempo |
|
| Pump de Datos: Transportable Completo | Media | Bajo | Física | Media | En línea/continua
Necesita que el origen sea de sólo lectura durante la exportación |
Base de datos completa con el mismo orden endianness (requiere Oracle Database versión 11.2.0.3 de origen) |
| Tablespace Transportable de Pump de Datos | Media | Bajo | Física | Media | En línea/continua | Juego de tablespaces de esquema (necesita Oracle Database versión 11.2.0.3) de origen |
| SQL*Loader | Bajo | Alta | Lógicas | Alta | Fuera de Línea | Migrar tablas o esquemas específicos |
| GoldenGate | Alta | Alta | Lógicas | Alta | Fuera de línea/continua |
|
| Copia de Seguridad y Restauración de RMAN | Bajo | Bajo | Física | Bajo | Fuera de línea/continua | Base de datos completa o juego de tablespaces |
| Data Guard | Bajo | Bajo | Física | Bajo | En línea/continua | Base de datos completa sin tiempo de inactividad o cerca de cero |
|
Clonación Remota de PDB Clonación Remota Reubicación de PDB Migración de PDB |
Bajo | Bajo | Física | Bajo | En línea/continua |
|
Nota:
Muchas de las soluciones se pueden combinar para crear la estrategia de migración más eficaz. Es posible que algunas aplicaciones empaquetadas tengan restricciones en las herramientas admitidas para la migración.Planificación de tamaño y despliegue
Nota:
El esfuerzo de tamaño de capacidad para la base de datos y la VM es el mismo que en las instalaciones locales.- Requisitos de rendimiento de la carga de trabajo
- Transacciones por Segundo
- Número de conexiones de usuario
- Se esperaban futuros cambios de carga de trabajo
- Requisitos de capacidad
- vCPUs
- Memoria
- Capacidad de E/S y almacenamiento
- Crecimiento futuro
- Requisitos de Gestión
- Servicios nativos de Oracle Cloud Infrastructure y accesibilidad
- Herramientas de supervisión
- Soluciones de copia de seguridad
- Capacidades de escalabilidad
- Escala de Base de Datos
- Escala de VM
- Escala de Cluster
- Requisitos de Disponibilidad
- Soluciones de alta disponibilidad de Oracle
- vMotion, DRS
- Requisitos de la aplicación
- Dependencias entre componentes locales
- Flujo de red entre aplicaciones y servicios de Oracle Cloud Infrastructure
Racionalización, Estandarización y Consolidación
Como parte del esfuerzo de migración, se recomienda que el equipo de migración utilice esta oportunidad para estandarizar la versión de la base de datos y consolidar los sistemas de base de datos cuando corresponda. Oracle Database 19c debe ser la versión mínima de la base de datos estandarizada porque proporciona la versión de soporte a largo plazo.
La consolidación es una de las principales estrategias que las organizaciones buscan una mayor eficacia en sus operaciones. La consolidación permite a las organizaciones aumentar el uso de los recursos de TI, lo que reduce los costos porque se necesitan menos recursos para lograr el mismo resultado. Los costos operativos también se reducen porque se deben controlar, gestionar y mantener menos componentes y objetos.
Los DBA y los administradores deben buscar la mejor oportunidad para consolidar tantas bases de datos como sea posible. Con Oracle 19c, tiene la oportunidad de utilizar la opción Oracle multi-inquilino con un máximo de tres bases de datos de conexión (PDB). De esta forma, se consiguen mayores economías de escala y una mayor densidad de consolidación con la modernización de la aplicación y la base de datos. Por lo tanto, debe determinar qué bases de datos caberían en el modelo de despliegue de la base de datos de contenedor (CDB).
Junto con la consolidación, considere la gestión de aislamiento. Los requisitos de aislamiento pueden influir en el método o el grado de consolidación posible. El nivel de aislamiento que exige el sistema determina si se consolidan varias PDB en una sola base de datos, alojan varias bases de datos en una sola plataforma o utilizan una combinación de ambos enfoques. El aislamiento se puede clasificar en cuatro áreas: fallo, recurso, seguridad y operativo. Cada modelo de nube gestiona el aislamiento de manera ligeramente diferente, mediante las capacidades incorporadas del sistema operativo o la base de datos, comúnmente combinadas con las funciones avanzadas o los productos para proporcionar una solución completa, a la vez que se asemeja el riesgo.