ESTUDIO OPCIONES DE MIGRACIÓN BASE DE DATOS 11.2 EN HPUX …

ORACLE IBÉRICA, S.R.L. ADVANCED CUSTOMER SERVICES

JUNTA DE ANDALUCÍA

INFORME

ESTUDIO OPCIONES DE MIGRACIÓN BASE DE DATOS 11.2 EN HPUX

ITANIUM A LINUX X86-64 VERSIÓN 19C

Referencia documento: Infv5_JdAMigracion_RDBMS_HPUX_Linux_v10.docx

Fecha: 14 de mayo de 2021

Versión: 1.0

Copyright(c) 2.021 ORACLE IBÉRICA

Todos los derechos reservados

La información incluida en el presente informe es confidencial, siendo para el uso exclusivo de Junta de Andalucía. Si usted no es el destinatario del informe le informamos que está totalmente prohibida cualquier divulgación, distribución o reproducción del contenido de este informe.

Infv5_JdAMigracion_RDBMS_HPUX_Linux_v10.docx Ver. 1.0

Certificado ISO-9002 Pág. 2 / 19 Nº: 20845/G

Registro de Cambios

Fecha Autor Versión Notas

14/05/2021 Isidro Granados 1.0 Documento inicial

Revisiones

Nombre Role

Agustin Calvo Support Manager

Distribución

Copia Nombre Empresa

1 Servicio de Informática JdA

2 Jose María Gómez Mera Oracle Ibérica

3 Agustin Calvo Oracle Ibérica

4

5



Índice de Contenidos

INTRODUCCIÓN ...................................................................................................................................... 4 RESUMEN MÉTODOS DE MIGRACIÓN DE HP-UX ITANIUM A LINUX X86-64 ........................................... 5 CROSS-PLATFORM TRANSPORTABLE TABLESPACES EN VERSIÓN 11.2.0.4 .............................................. 8

Cross-Platform Data Transportation (No incremental). RMAN CONVERT Transportable Tablespace with

Data Pump. ....................................................................................................................................... 8 Cross-platform transportable tablespaces Incremental Backup ....................................................... 9 Cross-Platform Data Transport usando Backup Sets ..................................................................... 11 Referencias y documentación recomendada ................................................................................... 12

CROSS-PLATFORM TRANSPORTABLE TABLESPACES EN VERSIÓN 19C ................................................... 13 Cross-Platform Data Transport usando Image Copies (No incremental) ...................................... 13 Cross-Platform Data Transport usando Backup Sets (No incremental) ......................................... 13 Cross-Platform Data Transport usando Inconsistent Backups (incremental) ................................ 14 Cross-Platform Data Transport Data Files por red ....................................................................... 18 Referencias y documentación recomendada ................................................................................... 19



Introducción

Existen diversos métodos de migración de bases de datos entre plataformas, listados en la nota de referencia Migration Of An Oracle Database Across OS Platforms (Generic Platform) (Doc ID 733205.1). Algunas de las opciones no son viables en desde plataforma HPUX Itanium a Linux x86-64 ya que las plataformas origen y destino tienen distinto “endian format” lo que esto limita las opciones. Por ejemplo el uso de Dataguard físico que sería opción recomendable en el caso de mismo “endian format”. Tampoco es viable la opción “Cross-Platform Database Transport” que permite transportar la base de datos completa.

Este informe se recoge un listado de los métodos viables migración de bases de datos desde plataforma HPUX Itanium a Linux x86-64 indicando los más adecuados en cada caso mostrando el detalle de las alternativas por versión que ofrece el método de tablespace transportables para versiones 11.2.0.4 y 19c. Todos los métodos disponibles de migración implican la creación previa de una base de datos en la plataforma destino y el movimiento de datos desde la base de datos origen a destino.



Resumen métodos de migración de HP-UX Itanium a Linux x86-64

En este apartado se indican el listado de métodos disponibles en las versiones 11.2 y 19c:

1. Export / Import con Datapump

Es la opción más simple y recomendada cuando el volumen de datos no es grande y el tiempo de parada de servicio es suficiente para la operativa.

Este método se puede paralelamente utilizar para realizar operativas de mantenimiento de la base de datos para salvar espacio y mejorar rendimiento (bajar HWM, eliminar chained/migrated rows, reconstruir índices con más leaf blocks o alto level, mover objetos a otros tablespaces en datafiles en discos más rápidos, etc).

2. Cross-platform transportable tablespaces (XTTS)

Este método permite mover datafiles entre plataformas de diferente “endian format”.

XTTS es una mejora de la funcionalidad de transportable tablespaces (TTS). TTS fue originalmente introducida como un método para mover datos de una base de datos a otra, por ejemplo para mover ciertas partes de un OLTP a un data warehouse en la misma plataforma. Con XTTS esto puede realizarse entre plataformas distintas.

Con esta funcionalidad los datafiles de un tablespace no-system pueden ser asignados a otra base de datos convirtiéndolos a su correcto endian format e importando los metadatos necesarios en la base de datos destino.

Esta será la opción más indicada cuando el volumen de datos es muy grande.

Existen varias variantes de esta opción, depende de la versión y del tiempo máximo de parada permitido. El informe hará un estudio de todas las variantes por versión.

Los objetos de base de datos que se transportarán entre base de datos serán los que físicamente estén localizados en los tablespaces que se indiquen en cada caso. Si se necesitan transportar otros objetos que estén localizados en otros tablespaces (por ejemplo, objetos pl/sql, secuencias, etc que están localizadas en el tablepace SYSTEM), el método de XTTS se tendrán que complementar con Data pump para copiar estos objetos a la base de datos destino.

En el caso de que la migración sea de la base de datos completa y el destino sea versión 11.2.0.4 o superior se recomienda combinar cualquiera de las variantes indicadas con la guía del MAA paper Platform Migration Using

http://www.oracle.com/technetwork/database/features/availability/maa-wp-11g-platformmigrationtts-129269.pdf



Transportable Tablespaces: Oracle Database 11g. http://www.oracle.com/technetwork/database/features/availability/maa-wp-11g-platformmigrationtts-129269.pdf

En el caso de que la migración sea de la base de datos completa y el destino sea una versión 12c o superior se recomienda complementar el método XTTS con el método Full Tablespace Export/Import indicado en el siguiente apartado para la exportación e importación de los metadatos.

3. Full Transportable Export/Import (También llamada Data Pump Full Transportable)

Funcionalidad introducida desde versión 12c. Mezcla el uso de datapump y transportable tablespaces para facilitar el proceso de mover el metadata de toda la bbdd sin tener que hacer todos los pasos adicionales comentados en el punto 2 anterior. Si hay un cambio de endian format entre plataformas también requerirá el convert con RMAN o usar DBMS_FILE_TRANSFER para convertir los datafiles de una plataforma a otra.

Este método permite hacer el export en versión 11.2.0.3 o superior aunque el import requiere que la bbdd sea superior a 12.1.0.2 o superior.

Cualquiera de los métodos cross-platform transportable tablespaces descritos en los siguientes apartados del informe cuando el destino sea la versión 19c permite integrar este método para la importación de los metadatos en una migración la base de datos completa.

Esta funcionalidad hace que la migración a versión 19c sea más rápida, fácil y eficiente.

Los pasos están descritos en detalle en:

Database Administrator’s Guide 19c 15.2 Transporting Databases

https://docs.oracle.com/en/database/oracle/oracle-database/19/admin/transporting-data.html#GUID-AA3C177A-EBD8-459B-9F25-19F13C304EEE

https://www.oracle.com/assets/full-transportable-wp-12c-1973971.pdf

4. Replicación con Oracle GoldenGate

Oracle GoldenGate es la tecnología de replicación de datos recomendada por Oracle que permite la replicación, filtro y transformación de datos entre bases de datos y puede ser utilizada para la migración entre plataformas.

Oracle GoldenGate permite minimizar el tiempo de parada así como la posible marcha atrás de una migración. Oracle GoldenGate requiere licenciamiento extra.

Esta alternativa no es cubierta en este documento.











NOTA: La técnica de replicación Oracle Streams está desoportada en versión 19c.

5. Otras alternativas para movimiento de datos

Si el volumen de datos y número de objetos es pequeño se podrían valorar utilizar otras alternativas de movimiento de datos como Create Table As Select (CTAS), sqlloader, sqlplus.

Estas alternativas no son cubiertas en este documento.

6. O2O y Triple-O

O2O (Oracle to Oracle) es una herramienta desarrollada por Oracle ACS para realizar servicios extra de migraciones por parte de Oracle ACS.

La herramienta permite el movimiento de datos de bbdd Oracle a bbdd Oracle entre versiones y plataformas. Utiliza métodos standard de Oracle (Create Table as Select, Export/Import, etc) de forma paralela logrando tiempos de migración muy óptimos, entorno a una capacidad de 250-750GB/hr (aunque esto depende de los recursos hardware).

Triple-O es un complemento a O2O con Oracle GoldenGate para permitir una migración online sin pérdida de servicio.

Estas alternativas no son cubiertas en este documento.



Cross-platform transportable tablespaces en versión 11.2.0.4

Este método permite mover datafiles entre bases de datos Oracle con plataformas de diferente “endian format”.

A continuación se indicarán todas las alternativas cuando la versión en el origen es 11.2.0.4 indicando consideraciones y la documentación recomendada a seguir en caso de necesitar ser aplicado. También se indicará cuando los métodos pueden utilizarse para transportar tablespaces de versiones anteriores.

Cross-Platform Data Transportation (No incremental). RMAN CONVERT Transportable Tablespace with Data Pump.

El método permite migrar tablespaces entre plataformas de distinto endian format.

A alto nivel las tareas que hay que ejecutar son:

1. Crear una nueva bbdd destino y esquemas.

2. Chequear requisitos previos

3. Poner en read-only los tablespaces en origen

4. Hacer un export de los “transportable metadata” en origen

5. Copiar los datafiles de los tablespaces entre las máquinas origen y destino.

6. Usar RMAN CONVERT para convertir los datafiles al nuevo endian format en el destino.

7. Importar en destino los “transportable metadata” de los tablespaces indicados.

8. Importar otros objetos de base de datos que no se hayan movido en la operación de "transport" (Código plsql, secuencias, etc).

Este método permite a su vez varias alternativas:

- Los pasos 5 y 6 pueden intercambiarse, esto, para convertir con RMAN los datafiles y copiar los datafiles entre una máquina y otra habrá dos opciones:

a) Lanzar el convert en el origen (CONVERT TABLESPACE... TO PLATFORM) que creará un backupcopy de cada datafile convertido que habrá que mover al destino.

b) Copiar los datafiles a la nueva máquina y posteriormente lanzar el convert con rman en la target. (CONVERT DATAFILE ... FROM PLATFORM)



- A partir de 11.2.0.4 se puede sustituir el uso de RMAN CONVERT y la copia por el uso de DBMS_FILE_TRANSFER para copiar y convertir los datafiles entre plataformas. La conversión del endian format se realizada de forma automática por el package DBMS_FILE_TRANSFER. De esta forma se utiliza para la copia un Databaes Link y se evitaría tener que tener un espacio físico intermedio para copiar la bbdd previo al CONVERT.

Si se quiere seguir este método, la nota How to Migrate to different Endian Platform Using Transportable Tablespaces With RMAN (Doc ID 371556.1) indica paso a paso las tareas a ejecutar y los requisitos previos y limitaciones del método.

Notas y consideraciones sobre el método

- Requiere una parada del servicio durante casi todo el proceso ya que los tablespaces se ponen en “read only” durante las fases de copia y conversión.

- La cantidad de tiempo requerido será directamente proporcional al tamaño de los datos a mover. También influirán en el tiempo de una migración los recursos hardware (red, disco, etc) y la paralelización de las tareas.

Un ejemplo real de migraciones usando este método:

Tamaño aprox. de BBDD: 4 TB

Total: 37h.

Tiempos principales de la migración entre plataformas usando XTTS:

Export de metadatos: -- Tiempo: 2h 10m

Convert con RMAN en paralelo: Tiempo: 15 horas

Copia en paralelo entre máquinas: -- Tiempo: 18 horas

Import metadata: -- Tiempo: 30m

- Los backup copy generados en el convert con RMAN tienen que ser a disco, no pueden utilizarse un canal de cinta para esto.

- El método anterior (excepto el uso del DBMS_FILE_TRANSFER sin CONVERT) podría usarse para directamente migrar tablespaces de versiones anteriores a versión 11.2.0.4 en otra plataforma. Ver “Compatibility Considerations for Transportable Tablespaces” en Transportable Tablespace (TTS) Restrictions and Limitations: Details, Reference, and Version Where Applicable (Doc ID 1454872.1)

Cross-platform transportable tablespaces Incremental Backup

Permite migrar tablespaces entre plataformas de distinto endian format de forma incremental minimizando el tiempo de parada, esto es, con el uso de backups



incrementales, la parada de servicio (momento en el que se ponen los tablespaces en read only en origen) se reduce y será proporcional al ratio de cambios de bloques en el sistema origen así como a la cantidad de metadatos a importar.

Para la ejecución de este método se utilizan scripts automatizados soportados por Oracle disponibles en la nota V4 Reduce Transportable Tablespace Downtime using Cross Platform Incremental Backup (Doc ID 2471245.1)



2. Chequeo prerrequisitos

3. Ejecución fases nota V4 Reduce Transportable Tablespace Downtime using Cross Platform Incremental Backup (Doc ID 2471245.1). En estas fases se realizan estas tareas:

a) Prepare phase: (La bbdd origen permanece online, tablespaces read write). En esta fase:

Se hace un backup copy de los datafiles indicados

Se transfieren las copias (datafile copies) al sistema destino

Se convierten en destino al nuevo endian format los datafile copies.

b) Roll Forward phase. (La bbdd origen permanece online, tablespaces read write, esta fase se repetirá tantas veces como sea necesario para mantener la bbdd origen y destino lo más sincronizadas posible)

En esta fase:

Se crea un incremental backup en el origen

Se transfiere el incremental backup al destino

Se convierte el incremental backup al nuevo endian format y se aplica en destino a los datafile copies

c) Transport phase (En la bbdd origen los tablespaces se ponen en READ ONLY)

En esta fase:

Se ponen los tablespaces en origen en READ ONLY

Se repite la última vez la fase "Roll Forward phase"

Se realiza un export de los transportable metadata en origen

Se importan en destino los transportable metadata de los tablespaces indicados

Se ponen los tablespaces READ WRITE en destino

4. Importar otros objetos de base de datos que no se hayan movido en las fases anteriores (Código plsql, secuencias, etc).



Si se quiere seguir este método, las notas V4 Reduce Transportable Tablespace Downtime using Cross Platform Incremental Backup (Doc ID 2471245.1) y 11G - Reduce Transportable Tablespace Downtime using Cross Platform Incremental Backup (Doc ID 1389592.1) indican paso a paso las tareas a ejecutar en cada versión y los requisitos previos y limitaciones del método.


- Respecto a la reducción de la parada de servicio por el uso del método cross-platform incremental backup, el tiempo de mejora no afecta a las operaciones de export e import del metadata. Esto es, si una bbdd tiene gran cantidad de metadata (DDL) y no tantos datos la mejora tendrá un beneficio más limitado.

- Este método es más complejo y las etapas son realizadas con unos scripts automatizados soportados por Oracle disponibles en la nota referida anteriormente. Al utilizar estos scripts la resolución de errores es más difícil si algún paso falla. Si el tiempo de parada con el método Cross-Platform Data Transportation no incremental es aceptable se recomienda su uso en lugar de este método Cross-platform Incremental Backup.

- Se recomienda la ejecución de los scripts en modo debug para poder diagnosticar mejor en caso de problemas el error.

- Los backups generados con RMAN tienen que ser a disco, no pueden utilizarse un canal de cinta para esto.

- Se necesitará un tamaño similar auxiliar para la copia en origen y destino de los datafiles correspondientes (también se puede usar NFS para compartir este espacio auxiliar desde ambos). También existe la opción DBMS_FILE_TRANSFER que hará la copia por red y la conversión automáticamente, en tal caso hay que utilizar la versión 3 de los scripts.

- El método indicado en la nota podría usarse para migrar directamente tablespaces de versiones 11.2.0.4 a versión 19c en otra plataforma, sin necesidad de realizar un upgrade de base de datos. Sin embargo una vez migrado, no se podría utilizar el mismo método en caso de vuelta atrás ya que requiere que el destino sea versión igual o superior al origen.

- Existe una versión previa (versión 3) de los scripts indicada en la nota 11G - Reduce Transportable Tablespace Downtime using Cross Platform Incremental Backup (Doc ID 1389592.1), que también es posible ser usada para migración desde versión 11.2.0.4 entre plataformas a 11.2.0.4 o superiores. Este método incluye la posibilidad de utilizar la opción de DBMS_FILE_TRANSFER pero Oracle recomienda el uso de la versión 4.

Cross-Platform Data Transport usando Backup Sets



En versión 12c se introdujo la funcionalidad en RMAN de poder transportar y convertir backupset entre plataformas con diferente endian format. Esto también se amplió a que el origen de los backups set fueran versiones anteriores a 12c, si el destino es versión 12c o superiores, esto es:

De la guía de 19c de RMAN:

“Although the TO PLATFORM and FOR TRANSPORT clauses are not supported in Oracle Database 10g Release 2 (10.2) or Oracle Database 11g, you can transport data from these versions of the database to Oracle Database 12c Release 1 (12.1). On the source database, you first create backup sets of the tablespaces to be transported and then create the Data Pump export dump file by using the expdp command. To restore these backups on the destination database, you perform a restore operation using the RESTORE command and then use the impdp command to import the Data Pump export dump file.”

Esto es, se pueden usar backup sets de backups de tablespaces en versiones anteriores y ser transportados y convertidos al nuevo endian format en una bbdd 12c o superiores.

En la siguiente nota se puede ver un ejemplo de uso:

How to restore a pre-12c backup to a cross-platform, cross-endian 12c database (Doc ID 1644693.1)

NOTA: Se puede usar el procedimiento con backups a disco o a cinta.

Referencias y documentación recomendada

- Database Backup and Recovery User's Guide 11.2

27 Transporting Data Across Platforms

http://docs.oracle.com/cd/E11882_01/backup.112/e10642/rcmxplat.htm#CHDFHBFI

- MAA Paper:

Platform Migration Using Transportable Tablespaces: Oracle Database 11g. http://www.oracle.com/technetwork/database/features/availability/maa-wp-11g-platformmigrationtts-129269.pdf

- Notas MOS:

How to Migrate to different Endian Platform Using Transportable Tablespaces With RMAN (Doc ID 371556.1)

11G - Reduce Transportable Tablespace Downtime using Cross Platform Incremental Backup (Doc ID 1389592.1)

Best Practices for Using Transportable Tablespaces (TTS) (Doc ID 1457876.1)

https://docs.oracle.com/en/database/oracle/oracle-database/19/bradv/rman-transporting-data-across-platforms.html#GUID-4644069A-7849-49F2-A1BF-2193EBAFFDBD








Cross-platform transportable tablespaces en versión 19c

A continuación se indicarán todas las alternativas cuando la versión en el origen es 19c indicando consideraciones y la documentación recomendada a seguir en caso de necesitar ser aplicado. NOTA: Queda fuera del alcance de este documento las opciones de Cross-Platform Transport en PDBs de entornos multitenant.

Cross-Platform Data Transport usando Image Copies (No incremental)

Similar al indicado en versión 11.2. Ver apartado Cross-Platform Data Transportation.

Cross-Platform Data Transport usando Backup Sets (No incremental)

Desde versión 12.1 se puede usar RMAN para transportar databases, data files, y tablespaces entre plataformas usando backup sets.

Utilizando este método permite usar el block compression automático de rman para reducir el tamaño de los backups. Esto mejora el rendimiento del backup y reduce el tiempo en transportar por red los backups.




3. Poner en read-only los tablespaces en origen

4. En origen hacer backup BACKUP TO PLATFORM o FOR TRANSPORT.

Ejemplo:

RMAN > BACKUP

TO PLATFORM 'Linux x86 64-bit'

FORMAT '/tmp/xplat_backups/trans_ts.bck'

DATAPUMP FORMAT '/tmp/xplat_backups/trans_ts_dmp.bck'

TABLESPACE projects, tasks;

NOTA:

Si se usa TO PLATFORM la conversión del endiant format es realizado en el origen, esto es el backupset generado ya está convertido.



Si se usa FOR PLATFORM la conversión del endiant format se hará en destino.

Opcionalmente se puede usar la cláusula DATAPUMP para indicar que se cree un export datapump con su propio backup piece con los metadatos.

5. En destino hacer el restore e import de los metadatos.

Ejemplo:

RMAN> RESTORE

FOREIGN TABLESPACE projects, tasks TO NEW

FROM BACKUPSET '/tmp/xplat_restores/trans_ts.bck'

DUMP FILE FROM BACKUPSET

'/tmp/xplat_restores/trans_ts_dmp.bck';

NOTA: Al usar la cláusula dump file hará automáticamente el import de los metadatos

Si se quiere seguir este método, la nota 12c How Perform Cross-Platform Database Transport to different Endian Platform with RMAN Backup Sets (Doc ID 2013271.1) indica paso a paso las tareas a ejecutar y los requisitos previos y limitaciones del método.


- Comparando con el uso de images copies (método de 11.2) reducirá principalmente el tamaño del backup y el tiempo en ser transportado, reduciendo el tiempo en el que los tablespaces tienen que estar en read only.

- La bbdd origen y destino tienen que ser 12c o superior.

- Los backups sets generados en origen pueden ser a disco o cinta

Cross-Platform Data Transport usando Inconsistent Backups (incremental)

Desde 12.1 junto con el uso de backupsets, RMAN también permite el transporte de “inconsistent tablespace backups” entre plataformas. Un “inconsistent tablespace backup” es un backup de uno o más tablespaces que son creados cuando los tablespaces están en modo read/write.

Los ficheros generados durante una operación de cross-platform inconsistent backup no pueden asignarse directamente a una base de destino. Para que sean consistentes y puedan asignarse a la bbdd destino hay que ir generando backup incrementales en origen y aplicarlos en destino haciendo el último backup incremental con los tablespaces en read only. Este último backup también puede incluir un export dump file con el metadata requerido para poder asignar el tablespace a la bbdd destino.



Con el uso un backups incrementales, la parada de servicio (momento en que se ponen los tablespaces en read only), se reduce y será proporcional al ratio de cambios de bloques en el sistema origen.

Para ejecutar esta opción se pueden seguir los comandos indicados en la documentación o los scripts proporcionados por la nota V4 Reduce Transportable Tablespace Downtime using Cross Platform Incremental Backup (Doc ID 2471245.1)

Alternativa 1: Sin usar scripts

Oracle 19c Backup and Recovery User's Guide

https://docs.oracle.com/en/database/oracle/oracle-database/19/bradv/rman-transporting-data-across-platforms.html#GUID-F497679C-9413-4AB9-85AD-F364021FA704




3. En origen con tablespaces en read-write, crear un cross-platform level 0 inconsistent backup de los tablespaces con las clausulas ALLOW INCONSISTENT and INCREMENTAL LEVEL 0.

Ejemplo:

BACKUP

FOR TRANSPORT

ALLOW INCONSISTENT

INCREMENTAL LEVEL 0

TABLESPACE my_tbs FORMAT

'/tmp/xplat_backups/my_tbs_incon.bck';

4. Copiar los ficheros generados al destino y hacer restore en destino del backupset 0.

Ejemplo:

RESTORE

FROM PLATFORM 'HP-UX IA (64-bit)'

FOREIGN DATAFILE 6

FORMAT '/tmp/aux/mytbs_6.df',

7


20


10

FORMAT '/tmp/aux/mytbs_10.df'

FROM BACKUPSET '/tmp/xplat_restores/my_tbs_incon.bck';





5. En origen hacer un cross-platform incremental backup level 1 cada cierto tiempo.

Ejemplo:

BACKUP

FOR TRANSPORT

ALLOW INCONSISTENT

INCREMENTAL LEVEL 1

TABLESPACE my_tbs FORMAT

'/tmp/xplat_backups/my_tbs_incon1.bck';

6. Copiar a destino los backupset generados y en destino ir recuperando estos incrementales:

Ejemplo:

RECOVER


FOREIGN DATAFILECOPY

'/tmp/aux/mytbs_6.df','/tmp/aux/mytbs_7.df','/tmp/aux/mytb

s_20.df','/tmp/aux/mytbs_10.df'

FROM BACKUPSET '/tmp/xplat_restores/my_tbs_incon1.bck';

7. Poner en readonly los tablespaces y hacer un cross-platform level 1 final añadiendo la cláusula export dump file.

Ejemplo:

ALTER TABLESPACE my_tbs READ ONLY;

BACKUP

FOR TRANSPORT

INCREMENTAL LEVEL 1

TABLESPACE my_tbs

FORMAT '/tmp/xplat_backups/my_tbs_incr.bck'

DATAPUMP FORMAT '/tmp/xplat_backups/my_tbs_incr_dp.bck';

8. Copiar todos los ficheros generados al destino y hacer el último recover y restore del datapump generado:

Ejemplo:

RECOVER



'/tmp/aux/mytbs_6.df','/tmp/aux/mytbs_7.df','/tmp/aux/mytb

s_20.df','/tmp/aux/mytbs_10.df'

FROM BACKUPSET '/tmp/xplat_restores/my_tbs_incr.bck';

RESTORE


DUMP FILE 'my_tbs_restore_md.dmp'

DATAPUMP DESTINATION '/tmp/dump'

FROM BACKUPSET '/tmp/xplat_restores/my_tbs_incr_dp.bck';

9. Hacer import del metadata en destino:



impdp directory=dp_dir dumpfile=backup_tts_RDBMS_13462.dmp

transport_datafiles='/tmp/aux/mytbs_6.df','/tmp/aux/mytbs_

7.df','/tmp/aux/mytbs_20.df','/tmp/aux/mytbs_10.df'

nologfile=Y

10. Poner en destino los tablespaces en READ WRITE

Alternativa 2: Usando scripts de la nota V4 Reduce Transportable Tablespace Downtime using Cross Platform Incremental Backup (Doc ID 2471245.1)

A alto nivel las tareas que hay que ejecutar son seguir las fases indicadas en la nota 2471245.1. En estas fases se realizan estas tareas:

1. Phase 1 - Initial Setup

Crear una nueva bbdd destino e identificar tablespaces.

Chequeo prerrequisitos

Copiar y configurar scripts

2. Phase 2 - Prepare phase: (La bbdd origen permanece online, tablespaces read write). En esta fase:

Se hace un backup de los datafiles indicados

Se transfieren los backupset al sistema destino

Se restauran al nuevo endian format los backupset copiados.

3. Phase 3 - Roll Forward phase. (La bbdd origen permanece online, tablespaces read write, esta fase se repetirá tantas veces como sea necesario para mantener la bbdd origen y destino lo más sincronizadas posible)

En esta fase:

Se crea un incremental backup en el origen

Se transfiere el incremental backup al destino

Se convierte el incremental backup al nuevo endian format y se aplica en destino a los datafile copies

4. Phase 4 - Final Incremental Backup (En la bbdd origen los tablespaces se ponen en READ ONLY)

En esta fase:

Se ponen los tablespaces en origen en READ ONLY

Se crea un final incremental backup

Se realiza un export de los transportable metadata en origen

5. Phase 5 - Transport Phase. Import Object Metadata into Destination Database



En esta fase:

Se importan en destino los transportable metadata de los tablespaces indicados

Se ponen los tablespaces READ WRITE en destino

6. Importar otros objetos de base de datos que no se hayan movido en las fases anteriores (Código plsql, secuencias, etc). Este punto puede omitirse si se usa sustituirse con el uso de Data Pump Full Transportable.


- Respecto a la reducción de la parada de servicio por el uso del método Cross-Platform Data Transport usando Inconsistent Backups respecto del uso Cross-Platform Data Transport usando Backup Sets (No incremental), el tiempo de mejora no afecta a las operaciones de export e import del metadata. Esto es, si una bbdd tiene gran cantidad de metadata (DDL) y no tantos datos la mejora tendrá un beneficio más limitado.

- Las bbdd origen y destino tienen que ser versión 12c o superiores.

- Los backups set generados en origen pueden ser a disco o cinta pero el procedimiento de la nota 2471245.1 usando scripts sólo soporta actualmente la opción de backupset a disco.

- En versión 19c también puede aplicarse la opción de DBMS_FILE_TRANSFER indicada en la nota 11G - Reduce Transportable Tablespace Downtime using Cross Platform Incremental Backup (Doc ID 1389592.1), este método puede ser el más rápido para transferir los datafiles a destino en el caso de gran número de datafiles.

Cross-Platform Data Transport Data Files por red

A partir de 12.2.0.1 RMAN permite realizar cross-platform transport de datafiles a través de red.

Basta establecer comunicación entre la base de datos origen y destino añadiendo entradas en el tnsnames.ora y listener.ora. De esta forma RMAN puede conectar a la base de datos origen, crear los backups de los datafiles requeridos en formato backupset, transferirlos al destino y restaurar los backups en el destino.

Los pasos serían:

1. Entrar en RMAN en destino como SYSDBA o SYSBACKUP

2. Restaurar los datafiles requeridos.

En el siguiente ejemplo se restauran los datafiles 21 y 22:



RESTORE

FOREIGN DATAFILE 21,22 TO NEW

FROM SERVICE 'source_db';

3. Recuperar los “foreign data files” restaurados:

RECOVER


'/u01/oracle/oradata/db1_tbs21.dbf','/u01/oracle/orad

ata/db1_tbs22.dbf'

FROM SERVICE 'source_db';

NOTA: Las bases de datos origen y destino tienen que ser 12.2 o superiores

Referencias y documentación recomendada

- Database Backup and Recovery User's Guide 19c

28 Transporting Data Across Platforms: https://docs.oracle.com/en/database/oracle/oracle-database/19/bradv/rman-transporting-data-across-platforms.html#GUID-65AADCB6-CC9A-4229-9AB8-805C37E4471F

- Oracle MAA Paper:

Platform Migration Using Transportable Tablespaces: Oracle Database 11g. http://www.oracle.com/technetwork/database/features/availability/maa-wp-11g-platformmigrationtts-129269.pdf

- Notas MOS:

12C - Reduce Transportable Tablespace Downtime using Cross Platform Incremental Backup (Doc ID 2005729.1)

12c How Perform Cross-Platform Database Transport to different Endian Platform with RMAN Backup Sets (Doc ID 2013271.1)

Best Practices for Using Transportable Tablespaces (TTS) (Doc ID 1457876.1)

How to restore a pre-12c backup to a cross-platform, cross-endian 12c database (Doc ID 1644693.1)

https://docs.oracle.com/en/database/oracle/oracle-database/19/bradv/rman-transporting-data-across-platforms.html#GUID-65AADCB6-CC9A-4229-9AB8-805C37E4471F






ESTUDIO OPCIONES DE MIGRACIÓN BASE DE DATOS 11.2 EN HPUX …

Documents

Transcript of ESTUDIO OPCIONES DE MIGRACIÓN BASE DE DATOS 11.2 EN HPUX …