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.
# Detalles de las opciones de migración
En las siguientes secciones se proporcionan detalles de las opciones que corresponden al diagrama de la sección anterior.
## 1. Copia de seguridad y restauración sin conexión
La copia de seguridad nativa de Db2 hace copias de seguridad de toda la base de datos. Se puede utilizar para volver a crear (restaurar) la base de datos en cualquier host.
+ La copia de seguridad y la restauración sin conexión son la forma más básica de migrar una base de datos de las instalaciones a AWS.
+ La base de datos en las instalaciones Db2 debe estar en la plataforma little-endian.
+ Se necesita un tiempo de inactividad para realizar una copia de seguridad sin conexión, transferir la imagen de la copia de seguridad a Amazon S3 y restaurar la base de datos a partir de la copia de seguridad.
## 2. Conmutación por error de HADR
Db2 HADR (recuperación ante desastres de alta disponibilidad) proporciona una solución de alta disponibilidad al replicar los cambios de datos de una base de datos de origen, denominada base de datos principal, a las bases de datos de destino, denominadas bases de datos en espera. HADR admite hasta tres servidores remotos en espera.
+ La conmutación por error de HADR es la mejor opción para una instancia que no sea DPF y que se ejecute en la plataforma little-endian.
+ Se deben registrar todas las transacciones de la base de datos de origen.
+ HADR permite replicar los cambios de datos de la base de datos de origen (base de datos principal) a la base de datos de destino (base de datos en espera) mediante la transmisión de registros. El HADR se utiliza TCP/IP para la comunicación entre las bases de datos principal y en espera.
+ Tras la validación completa de la empresa, la HADR se puede eliminar sin interrupciones y la base de datos Db2 en las instalaciones se puede retirar del servicio.
## 3. Copia de seguridad y restauración en línea con envío de registros de transacciones
A diferencia de la copia de seguridad y la restauración sin conexión (opción 1), la copia de seguridad en línea no necesita tiempo de inactividad para la base de datos de origen. Utiliza los registros de transacciones de la base de datos para aplicar los cambios a la base de datos de destino una vez finalizada la copia de seguridad en la base de datos de origen.
+ El uso de copias de seguridad y de la restauración junto con el envío de los registros de transacciones es la mejor opción para una instancia Db2 DPF que esté en la plataforma little-endian. Como el tamaño de una base de datos Db2 DPF suele ser grande, el tiempo de interrupción para realizar copias de seguridad y restauraciones periódicas (opción 1) puede superar las 12 horas. Las bases de datos Db2 DPF no admiten la HADR.
+ Se deben registrar todas las transacciones de la base de datos de origen.
+ Puede utilizar la copia de seguridad y la restauración con el envío de registros de transacciones para minimizar el periodo de interrupción.
+ La copia de seguridad y la restauración con envío de registros también se pueden utilizar para las instancias que no son DPF. Sin embargo, la opción de HADR con conmutación por error es más fácil de implementar para las instancias que no son DPF.
+ A diferencia de la conmutación por error de HADR (opción 2), la sincronización inversa no es automática. Configúrelo manualmente.
+ Una vez completada la validación de la empresa, se puede retirar la base de datos Db2 en las instalaciones.
## 4. Q Replication
Q Replication es una solución de replicación de alto volumen y baja latencia que utiliza las colas de mensajes de IBM MQ para transmitir transacciones entre las bases de datos de origen y destino.
En el siguiente diagrama se muestra la configuración más habitual.
IBM MQ se ejecuta en el mismo servidor que Db2. Hay dos instancias de IBM MQ, una en el servidor en las instalaciones y otra en Amazon EC2. El programa Capture se ejecuta en la base de datos de origen. Lee los registros de transacciones y envía los cambios confirmados (inserción, actualización o eliminación) a la instancia de IBM MQ en las instalaciones. La instancia de IBM MQ en las instalaciones envía los mensajes a través de AWS Site-to-Site VPN a IBM MQ en Amazon EC2. El programa Apply se ejecuta en la instancia de EC2 con la base de datos de destino. En primer lugar, realiza una carga completa en las tablas. A continuación, lee los mensajes de datos de cambios de IBM MQ en Amazon EC2 y los aplica a las tablas de destino.
+ El origen es Db2 en las instalaciones y Db2 en Amazon EC2 es el destino. Ambas bases de datos están en línea.
+ La base de datos Db2 en las instalaciones puede estar en cualquier familia de plataformas.
+ Se deben registrar todas las transacciones de la base de datos de origen.
+ IBM MQ ofrece alto rendimiento, alta disponibilidad y entrega de mensajes garantizada.
+ Los mensajes se eliminan de IBM MQ después de que se hayan realizado cambios en la base de datos de destino.
+ Two-way la replicación es una opción alternativa. Sin embargo, se necesita una configuración adicional.
+ Se necesita una migración de esquemas. Para obtener más información, consulte la sección [Migración de esquemas](#schema-migration).
+ Q Replication requiere una [licencia adicional a partir de la versión 11.5](https://www.ibm.com/support/pages/ibm-db2-11-changes-data-replication).
+ Tras una transición exitosa, detenga la replicación y retire las instancias de IBM MQ. Si lo desea, también puede retirar la base de datos en las instalaciones.
## 5. SQL Replication
SQL Replication consta de los siguientes componentes principales: Capture, Apply, interfaz de GUI y CLI y Alert monitor.
El programa Capture se ejecuta en la base de datos de origen. Lee los registros de transacciones y guarda los cambios confirmados (inserción, actualización o eliminación) en las tablas de datos modificados (CD). Hay una tabla de CD para cada tabla de origen.
Los puntos de confirmación de Db2 para las unidades de trabajo se almacenan en la tabla de unidades de trabajo (UOW). En el momento especificado por el usuario, el programa Capture elimina los datos que ya no se necesitan de las tablas de CD y UOW. Esto se llama poda.
El programa Apply se ejecuta en la base de datos de destino. Se conecta a la base de datos de origen, recupera los datos almacenados en las tablas de CD, almacena las filas recuperadas en uno o más archivos secundarios y, a continuación, los aplica a la base de datos de destino.
+ La base de datos Db2 en las instalaciones puede estar en cualquier familia de plataformas.
+ Se deben registrar todas las transacciones de la base de datos de origen.
+ La sobrecarga de la base de datos de origen se considera alta porque cada escritura se debe ejecutar varias veces (en la tabla base, la tabla de CD y la tabla de UOW). En general, recomendamos SQL Replication para los sistemas con poco tráfico de escritura.
+ Two-way la replicación es una opción alternativa. Sin embargo, se necesita una configuración adicional.
+ Se necesita una migración de esquemas. Para obtener más información, consulte la sección [Migración de esquemas](#schema-migration) para ver más detalles.
+ A diferencia de Q Replication, SQL Replication se incluye en todas las ediciones de Db2. No requiere una licencia adicional.
+ Una vez completada correctamente la transición, detenga la replicación y, si lo desea, elimine la base de datos en las instalaciones.
## 6. AWS DMS
[AWS Database Migration Service (AWS DMS)](https://docs.aws.amazon.com/dms/latest/userguide/Welcome.html) es un servicio gestionado de migración y replicación que ayuda a trasladar sus cargas de trabajo de bases de datos y análisis a un entorno AWS seguro, con un tiempo de inactividad mínimo y sin pérdida de datos.
+ Una instancia de AWS DMS replicación realiza la migración de la base de datos.
+ AWS DMS Los puntos finales de origen y destino permiten a la AWS DMS instancia conectar la base de datos de origen y destino para la migración.
+ Una AWS DMS tarea se conecta al punto final de origen y replica los datos al punto final de destino.
+ Puede activar la validación de datos para verificar que los datos se migren con precisión del origen al destino.
+ Puedes habilitar el registro a través de Amazon CloudWatch.
## 7. Third-party herramientas de replicación
Third-party las herramientas de replicación, como [Infosphere CDC,](https://www.ibm.com/docs/da/iis/11.7?topic=sources-infosphere-change-data-capture) [Qlik Replicate](https://help.qlik.com/en-US/replicate/May2025/Content/Replicate/Main/Introduction/replicat_concepts.htm), [Precially real-time CDC](https://www.precisely.com/solution/real-time-cdc-and-etl-solutions) y [Oracle](https://www.oracle.com/integration/goldengate/), permiten GoldenGate migrar datos a Db2 para LUW como destino.
En el caso de Qlik Replicate, Db2 para LUW debe configurarse como un destino de Open Database Connectivity (ODBC).
## 8. InfoSphere Descarga y carga Optim High Performance
InfoSphere Optim High Performance Unload evita el motor Db2 y descarga los datos directamente de los archivos físicos.
+ Por lo general, Optim High Performance Unload puede descargar datos de Db2 varias veces más rápido que el comando `EXPORT` de Db2. Puede omitir el administrador de bases de datos de Db2 al leer los archivos de datos directamente del disco. También evita examinar la tabla de Db2 varias veces al especificar varias instrucciones `SELECT` o varios formatos de archivo en un archivo de control.
+ Optim High Performance Unload también puede descargar datos de Db2 de la copia de seguridad. Esto significa que puede ejecutar Optim High Performance Unload en otro equipo para reducir el impacto en el rendimiento del servidor de bases de datos de origen. Esto resulta muy útil para tablas históricas o particiones de tablas de gran tamaño.
+ Los archivos de la salida de datos se pueden transferir a Amazon S3, al que puede acceder el servidor de EC2 para Db2.
+ La carga de Db2 admite el acceso directo a Amazon S3. Por ejemplo, puede usar el comando siguiente:
```
db2 load from DB2REMOTE:///// replace into mytable
```
+ Se necesita una migración de esquemas. Para obtener más información, consulte la sección [Migración de esquemas](#schema-migration).
+ InfoSphere Optim High Performance Unload requiere una licencia adicional.
## 9. LOAD FROM CURSOR
LOAD FROM CURSOR es una opción de la utilidad de carga de Db2 que utiliza una tabla del destino como origen, sin descargar los datos en un archivo.
+ Se tiene que crear un enlace federado en la base de datos de destino y vincularlo a la base de datos de origen.
+ Para cada tabla, se crea un apodo que enlaza con la tabla de origen en las instalaciones. Si hay varias tablas, le recomendamos que utilice un script de automatización para generar los apodos y las instrucciones de carga.
+ LOAD FROM CURSOR omite las pruebas de almacenamiento provisional y las tablas se pueden separar en diferentes flujos para que se ejecuten en paralelo. Recomendamos que supervise la congestión de la red durante las cargas de gran tamaño.
+ Al manipular la instrucción `SELECT` de la definición del cursor, puede seleccionar la tabla completa, omitir los datos que no desee cargar o dividir una tabla de particiones basada en intervalos en varias instrucciones de carga (por ejemplo, trimestrales y mensuales).
+ Se necesita una migración de esquemas. Para obtener más información, consulte la sección [Migración de esquemas](#schema-migration).
## 10. db2move
El comando `db2move`, cuando se utiliza en los modos `EXPORT`, `IMPORT` o `LOAD`, facilita el movimiento de un gran número de tablas entre bases de datos de Db2.
+ Se necesita una migración de esquemas. Para obtener más información, consulte la sección [Migración de esquemas](#schema-migration).
+ Puede usar el comando `db2move` para descargar los datos de las tablas en archivos y cargar los datos en tablas de Db2. Esto es útil porque la utilidad db2move puede descargar todas las tablas de la base de datos de origen y cargarlas en la base de datos de destino con unos pocos comandos.
1. Para exportar todas las tablas de la base de datos de origen con LOB a``, ejecute el siguiente comando:
```
db2move export -l //
```
1. Transfiera los archivos a Amazon S3, donde los podrá recuperar el servidor de EC2 para Db2.
1. Para cargar todas las tablas en la base de datos de destino, ejecute el siguiente comando:
```
db2move load -l //
```
## Migración de esquemas
Para la copia de seguridad y la restauración, la conmutación por error de HADR y la copia de seguridad y restauración con envío de registros (opciones 1 a 3), la migración de esquemas está incluida en la migración de datos. No se necesita ningún paso adicional.
Para la replicación lógica y la migración de big-endian (opciones 4 a 10), debe crear manualmente la base de datos y el esquema en el destino. Recomendamos evitar cambios de esquema en el origen durante la migración. La migración puede tardar varios días, aunque el tiempo de interrupción real es mucho más corto.
En el servidor de origen:
1. Extraiga el lenguaje de definición de datos (DDL) con la utilidad db2look y guarde la salida en `db2look.ddl`.
1. Transfiera `db2look.ddl` a Amazon S3.
En el servidor de destino:
1. Obtenga `db2look.ddl` de Amazon S3.
1. Elimine la restricción de clave externa, la restricción de verificación y las instrucciones `CREATE TRIGGER`. Guárdelas en archivos separados. Este proceso no es difícil porque la salida de db2look agrupa estas instrucciones.
1. Cree una base de datos y un esquema sin la clave externa, la restricción de verificación y el disparador.
1. Convierta tablas con columnas de identidad que tengan `GENERATED ALWAYS` en `GENERATED BY DEFAULT`.
1. Para las opciones de replicación lógica 4, 5, 6 y 7, inicie la replicación. Puede volver a crear las claves externas y restricciones de verificación una vez completada la carga completa. Sin embargo, debe volver a crear los disparadores antes de la transición.
1. Para las opciones 8, 9 y 10, una vez finalizada la carga de datos, vuelva a crear las claves externas, las restricciones de verificación y los disparadores.
1. Revierta las tablas con las columnas de identidad que modificó en el paso 4 a `GENERATED ALWAYS`.
1. Vuelva a sembrar las columnas y secuencias de identidad antes de la transición.