Cuando se requiere migrar una base hacia una plataforma con distinto endian (ej: desde Solaris SPARC a Linux X64) la única alternativa es usar XTTS (Transportable Tablespaces con conversión). Para realizar dicho procedimiento se necesita tener los tablespaces en modo read only durante la transferencia de los datafiles al nuevo servidor. Esto provoca una indisponibilidad parcial, ya que se pueden realizar consultas pero no cambios sobre los tablespaces involucrados. El tiempo de indisponibilidad será directamente proporcional al volumen a copiar y este tiempo en muchos casos es inviable para el negocio.
A partir de 11.2.0.4 y en adelante se puede usar backups incrementales con conversión de endian para reducir el tiempo de indisponibilidad al mínimo posible. El procedimiento es un tanto mas complejo que el tradicional pero Oracle provee los scripts para realizarlo en forma mas sencilla.
Es importante aclarar que este procedimiento es recomendable solo para migraciones hacia distinto endian, y en general se da cuando se quiere pasar a Linux desde AIX, Solaris y HP-UX. Es el método elegido para migrar a Exadata. Cuando no se requiere conversión en la migración el método sugerido es DATA GUARD.
Fase de Roll-Forward (repetir los pasos de esta fase tantas veces sea necesario para mantener los datafiles actualizados respecto a los originales)
Fase de Transporte
Ahora voy a mostrar un ejemplo paso a paso de como realizar la migración. En los procesos tomo en cuenta que puedan existir datafiles con el mismo nombre (con distinto path) y por lo tanto agrego algunos pasos extra (creación de links simbolicos, cambio temporal de nombres de datafiles para hacerlos únicos, etc)
A partir de 11.2.0.4 y en adelante se puede usar backups incrementales con conversión de endian para reducir el tiempo de indisponibilidad al mínimo posible. El procedimiento es un tanto mas complejo que el tradicional pero Oracle provee los scripts para realizarlo en forma mas sencilla.
Es importante aclarar que este procedimiento es recomendable solo para migraciones hacia distinto endian, y en general se da cuando se quiere pasar a Linux desde AIX, Solaris y HP-UX. Es el método elegido para migrar a Exadata. Cuando no se requiere conversión en la migración el método sugerido es DATA GUARD.
Pasos para migrar usando el método Tradicional
Los pasos son en general los siguientes:
- Setear los tablespaces en origen en READ ONLY
- Transferir los datafiles de los tablespaces puesto en RO al nuevo servidor
- Convertir los datafiles en destino al nuevo endian (también puede convertir a nivel tablespace en origen).
- Exportar la metadata de los tablespaces en la base de datos origen (expdp)
- Importar la metadata de los tablespaces en la base destino (impdp)
- Setear los tablespaces en origen en READ WRITE
Pasos para migrar usando XTTS con backups incrementales
Fase de Preparación- Transferir los datafiles a destino
- Convertir los datafiles al endian del servidor destino
Fase de Roll-Forward (repetir los pasos de esta fase tantas veces sea necesario para mantener los datafiles actualizados respecto a los originales)
- Crear backup incrementales en origen
- Transferir los backups incrementales a destino
- Convertir los backups incrementales al endian de destino y aplicar el backup los datafiles en destino
Fase de Transporte
- Setear los tablespaces en orgen como READ ONLY
- Repetir la fase de Roll-Forward por ultima vez.
- Exportar la metadata de los tablespaces en la base de datos origen (expdp)
- Importar la metadata de los tablespaces en la base destino (impdp)
- Setear los tablespaces en origen en READ WRITE
Ahora voy a mostrar un ejemplo paso a paso de como realizar la migración. En los procesos tomo en cuenta que puedan existir datafiles con el mismo nombre (con distinto path) y por lo tanto agrego algunos pasos extra (creación de links simbolicos, cambio temporal de nombres de datafiles para hacerlos únicos, etc)
Descripción del Paso a Paso
Etapa 1: Preparación
1 .1 Generar Script para Crear los link simbólicos temporales
Genera el script que deberá ejecutarse como etapa de preparación para poder realizar la aplicación de cambios incrementales. Es necesario dado que el script perl que realiza la generación y aplicación de backup incrementales solo puede definir un solo directorio.
El script generado es: crear_links.sh que deberá ejecutarse desde shell en el sitio origen para que se creen los links de soporte a la migración
1.2 Verificar que los tablespaces a transferir estén autocontenidos
Ejecutar el siguiente sp:
Chequear si hubieron inconsistencias o invalidaciones:
1.3 Configuración de objetos DIRECTORY y database link
En base origen
En base destino
En base destino crear un dblink
1.4 Descomprimir en $ORACLE_HOME/xtt el archivo rman-xttconvert.zip en origen y destino
1.5 Crear directorios de almacenamiento temporal en origen y destino
1.6 Configurar el archivo de propiedades en el sitio origen y destino
Editar el archivo de propiedades xtt.properties en el sitio origen y cambiar las siguientes lineas:
El archivo xtt.properties, luego de editarlo y adecuar los valores para ROP es: xtt.properties
Copiar el archivo de propiedades al sitio destino
1.7 Crear los directorios que deberán contener los backups incrementales intermedios en origen (stage_orig) y destino (stage_dest)
Etapa 2: Pasaje de Datos Inicial
2.1 Verificación y Preparación en base origen
En este paso se verifica que los tablespaces a transportar (indicados en el archivo de propiedades) estén en modo READ WRITE y que no tengan datafiles offline.
La salida para transportar los tablespaces debe ser similar a la siguiente:
Una vez finalizado el comando se generan los siguientes archivos en el directorio definido por la variable de entorno TMPDIR
- xttnewdatafiles.txt
- getfile.sql
- xttplan.txt
- xttprepare.cmd
2.2 Copiar los archivos xttnewdatafiles.txt y getfile.sql creados en la etapa anterior
2.3 Adecuar los archivo xttnewdatafiles.txt y getfile.sql para que funcione con un solo directorio origen y destino
Copiar en /home/oracle/xtt y ejecutar en sqlplus en base origen el siguiente .sql: gen_replace_df_lnk_getfile.sql cuyo código se muestra a continuación:
Hacer lo mismo para el archivo xttnewdatafiles.txt usando el sql: replace_df_lnks_xttnewdf.sh
La ejecución del .sql anterior en origen permite adecuar la copia inicial de datafiles a destino permitiendo usar los links simbolicos. El resultado es spooleado en el archivo: replace_df_lnks.sh
Copiar a destino el shell generado en el paso anterior. Dicho .sh adecuará el getfile.sql (original) copiado
Por ultimo ejecutar el shell para que realice el reemplazo para que agregue el sufijo de directorio a los archivos que se alojaran temporalmente en /ROP/lnks del sitio destino
La ejecución anterior dejará un getfile,sql (adecuado) que se usará para el próximo paso.
2.4 Transferir y Convertir los datafiles
Una vez ejecutado el comando anterior deberían estar pasados y convertidos los datafiles en el directorio temporal /ROP/lnks.
Si se requiere reprocesar, los datafiles no deben existir en destino, de lo contrario el comando fallará. También podría ser necesario eliminar el siguiente archivo /home/oracle/xtt/tmp/TESTFAILED.
2.5 Verificar que se haya realizado la transferencia de todos los datafiles
Verificar que no exista el archivo que se genera cuando hay errores
Chequear que se haya pasado todos los datafiles
Las dos salidas deben retornar el mismo número (326).
FASE 3: Aplicación Incremental de Cambios
3.1 Crear el backup incremental de los tablespaces transportados
El comando crea los siguientes archivos, con información de lo que se tiene que aplicar
- tsbkupmap.txt
- incrbackups.txt
3.2 Transferir el backup incremental a destino
Se copian los archivos de backup incremental generado con RMAN al ejecutar el comando de 3.1
3.3 Convertir los backup incrementales y aplicar los cambios a los datafiles copiados en el sitio destino
La salida esperada del comando debería ser similar a la siguiente:
3.4 Determinar el nuevo SCN para usar en FROM_SCN registrado en el archivo xttplan.txt
En el sitio origen obtener el próximo SCN para saber desde donde aplicar los nuevos cambios
3.5 Repetir la Fase 3 o pasar directamente a la Fase 4
Si se quiere mantener los datafiles copiados en destino lo mas cercano a los datafiles originales se pueden repetir los pasos anteriores (desde 3.1 en adelante), de lo contrario se puede pasar a la ultima etapa (Fase 4)
FASE 4: Fase de Transporte
4.1 Setear en solo lectura (READ ONLY) los tablespaces a migrar
4.2 Crear el backup incremental final, transferir, convertir y aplicar en destino
4.3 Importar la metadata en la base destino
En el sitio destino conectado con oracle ejecutar:
El comando genera el archivo xttplugin.txt con el comando para importar los datos desde origen usando el dblink creado en al Fase 1 (ttslink) usando el modo network_link de Oracle Data Pump
Luego ejecutar copiar el siguiente sh en el destino (ROPHOST2) en la carpeta /home/oracle/xtts/tmp/ rename_final_dest.sh . El mismo realiza el renombrado de los datafiles a su ruta final y también adecua el archivo xttplugin.txt .
Luego de esto ejecutar el import dentro del archivo xttplugin.txt
excelente …. cual seria la diferencia sino utilizaramos un dblink?
ResponderEliminarHola. Migramos una BD Oracle 11g de HP- UX a Linux. Se convirtió la BD y los objetos. Se hicieron pruebas. Una vez finalizadas, se actualizó la BD. Ahora hay una query, dentro de un package que no tiene la misma performance que en origen Alguna pista de que puede ser . Gracias
ResponderEliminar