Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
# Fase 1: preparación
Durante la fase de preparación, evalúe su base de datos existente e identifique sus dependencias. En las siguientes secciones se describen los elementos principales que se deben evaluar antes de planificar la migración.
## Análisis de dependencias
Al prepararse para la migración a Oracle, identifique las interdependencias y su impacto en las aplicaciones de interfaz. Responda a las siguientes preguntas iniciales:
+ **Verificación de dependencias**: identifique las aplicaciones que se conectan directamente a la base de datos. Para evitar problemas de latencia, le recomendamos que migre las aplicaciones junto con la base de datos. En el caso de las aplicaciones que acceden a los datos de forma indirecta a través de una API, identifique el impacto en el rendimiento y el tiempo de inactividad necesario para la migración.
+ **Acceso a otras bases de datos**: Oracle Database proporciona un mecanismo para acceder a los datos de otra base de datos a través de una red mediante un [enlace de base de datos](https://docs.oracle.com/en/database/oracle/oracle-database/19/sqlrf/CREATE-DATABASE-LINK.html). El enlace a la base de datos le ayuda a leer y escribir en las tablas de una base de datos remota. Por ejemplo, una aplicación de informes puede obtener datos de una base de datos centralizada que utiliza enlaces de bases de datos para obtener datos de otras bases de datos de la misma unidad de negocio. Es importante identificar todas estas conexiones y volver a crear los enlaces de la base de datos tras la migración.
+ **Trabajos externos**: a veces, los trabajos de la base de datos se programan y controlan fuera de la base de datos. Para evitar cualquier impacto posterior, asegúrese de que esos trabajos sigan ejecutándose durante la migración de la base de datos.
+ **Dependencias del centro de datos**: durante la migración, es posible que, en ocasiones, algunos de sus sistemas estén en la nube mientras que otros sistemas sigan en el centro de datos local. La latencia de la red es un factor importante en estas configuraciones. Decida si quiere migrar juntas las aplicaciones y bases de datos sensibles a la latencia o si quiere trasladar la funcionalidad a la base de datos de migración. En cualquier caso, le recomendamos que migre las aplicaciones a la misma zona de disponibilidad que la base de datos migrada para evitar la latencia de la red.
+ **Acceso al host**: algunas aplicaciones crean informes que se almacenan en un sistema de archivos de un servidor de base de datos. Al migrar la base de datos, también puede decidir modernizar la generación de informes guardándolos en un almacenamiento nativo de la nube. En función de lo complejo que pueda resultar cambiar la generación de informes, puede decidir utilizar [Amazon EC2, Amazon](https://aws.amazon.com/ec2/) RDS o [Amazon RDS](https://aws.amazon.com/rds/) [Custom](https://aws.amazon.com/rds/custom/) como destino para la base de datos de Oracle.
+ **Opciones, funciones y requisitos de parches específicos de la base** de datos: revise las funciones de la base de datos Oracle que utiliza y sus requisitos tras la migración. El uso de las funciones y las necesidades posteriores a la migración ayudan a determinar la configuración de la base de datos en la nube. Los parches únicos de la base de datos Oracle de origen pueden requerir la migración de la base de datos a Amazon RDS Custom o a una EC2 instancia.
## Requisitos de disponibilidad
Según las necesidades empresariales, algunas bases de datos deben estar operativas todo el día, todos los días. Otras bases de datos pueden permitirse tiempos de inactividad fuera del horario laboral o durante los fines de semana. En la fase de preparación de la planificación de la migración, es importante comprender el impacto empresarial del tiempo de inactividad de las bases de datos y elegir la estrategia de migración adecuada. Por ejemplo, la migración en línea tiene un tiempo de inactividad mínimo, mientras que la migración fuera de línea implica un período de inactividad más prolongado.
## Análisis de carga de trabajo
Comprender la naturaleza de la carga de trabajo de la base de datos le ayuda a determinar la estrategia de migración de la base de datos. El plazo de migración y cualquier tiempo de inactividad necesario dependen de la carga de trabajo. Las cargas de trabajo pueden variar desde ser altamente transaccionales hasta consistir principalmente en trabajos por lotes e informes. Para ayudarte con la planificación y la estrategia de migración, identifica en qué parte de este espectro se encuentra tu carga de trabajo.
Hay herramientas disponibles para ayudarlo a calificar la carga de trabajo de su base de datos. Las herramientas que puede utilizar dependen de su licencia de Oracle Database e incluyen las siguientes:
+ Las métricas del host, como [la CPU, la](https://docs.oracle.com/en/enterprise-manager/cloud-control/enterprise-manager-cloud-control/13.4/emadm/overview-performance-and-resource-metrics.html#GUID-9212FAF0-BFE1-4DB4-A346-F7039DE69113) E/S y la memoria, le ayudan a decidir los requisitos de instancia y almacenamiento de sus bases de datos en la nube.
+ Los informes de Oracle, como [Automatic Workload Repository (AWR)](https://www.oracle.com/technetwork/database/manageability/diag-pack-ow09-133950.pdf) para Oracle Database Enterprise Edition o [Statspack](https://www.oracle.com/technetwork/database/performance/statspack-129989.pdf) para Standard Edition, le ayudan a determinar la naturaleza de las transacciones que se producen en su base de datos.
+ La [generación de registros de rehacer y archivar](https://support.oracle.com/epmos/faces/DocumentDisplay?_afrLoop=427729352629787&parent=EXTERNAL_SEARCH&sourceId=HOWTO&id=2373477.1&_afrWindowMode=0&_adf.ctrl-state=e285gjpp6_4) le ayuda a determinar la tasa de cambio que se produce en la base de datos.