oracle ibÉrica, s · viable ya que no puede usarse un data guard de solaris operating system...

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

JUNTA DE ANDALUCÍA

INFORME

ESTUDIO OPCIONES DE MIGRACIÓN BASE

DE DATOS EN SOLARIS SPARC A LINUX

X86-64 EN VERSIÓN 11GR2 Y 12C.

SOLUTION SUPPORT CENTER

La información incluida en el presente informe es confidencial, siendo para el uso exclusivo del cliente indicado. 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 dicho informe.

Referencia documento: Infv5_JdA_Migracion_RDBMS_Solaris_Linux_v11.docx

Fecha: 12 de abril de 2019

Versión: <1.1>

Copyright(c) 2.019 ORACLE IBÉRICA

Todos los derechos reservados

Infv5_JdA_Migracion_RDBMS_Solaris_Linux_v11.docx, Ver. <1.1>

12 de abril de 2019

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

Registro de Cambios

Fecha Autor Versión Notas

28/07/17 I. Granados 1.0

12/04/19 I. Granados 1.1 Actualización

Revisiones

Nombre Role

Jose María Gómez Mera TAM

Distribución

Copia Nombre Empresa

1 Servicio de Informática JdA

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

3

4

5

6


12 de abril de 2019


Índice de Contenidos

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

Cross-Platform Data Transportation (No incremental) ................................................................... 8 Cross-platform Incremental Backup ................................................................................................. 9 Referencias y documentación recomendada .................................................................................... 11

CROSS-PLATFORM TRANSPORTABLE TABLESPACES EN VERSIÓN 12.1.0.2 ............................................ 12 Cross-Platform Data Transport usando Image Copies (No incremental) ....................................... 12 Cross-Platform Data Transport usando Backup Sets (No incremental) ......................................... 12 Cross-Platform Data Transport usando Inconsistent Backups (incremental) ................................ 13 Cross-Platform Data Transport desde versiones anteriores a 12.1.0.2 usando Backup Sets .......... 17 Referencias y documentación recomendada .................................................................................... 18

CROSS-PLATFORM TRANSPORTABLE TABLESPACES EN VERSIÓN 12.2.0.1 ............................................ 19 Cross-Platform Data Transport Data Files por red ........................................................................ 19 Referencias y documentación recomendada .................................................................................... 19


12 de abril de 2019


Introducción

Existen diversos métodos de migración de bases de datos desde plataforma Solaris SPARC a Linux x86-64. La nota de referencia Migration Of An Oracle Database Across OS Platforms (Generic Platform) (Doc ID 733205.1) indica todas las opciones disponibles dependiendo de la plataforma origen y destino. Algunas de las opciones no son viables en este caso ya que las plataforma 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” no es viable ya que no puede usarse un Data Guard de Solaris Operating System (SPARC) (64-bit) a Linux x86-64 (Sí se podría de Solaris (AMD64 o x86-64) a Linux x86-64). 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 Solaris SPARC 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, 12.1.0.2 y 12.2.0.1.

Todos los métodos disponibles de migración implican la creación previa de una bbdd en la plataforma destino y el movimiento de datos desde la base de datos origen a destino.


12 de abril de 2019


Resumen métodos de migración de Solaris SPARC a Linux x86-64

En este apartado se indican el listado de métodos disponibles en las versiones 11.2, 12.1.0.2 y 12.2.0.1:

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 otro, 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, se recomienda combinar cualquiera de las variantes indicadas con la guía del MAA paper Platform Migration Using Transportable Tablespaces: Oracle Database 11g.

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



12 de abril de 2019



3. Full Transportable Export/Import

Funcionalidad introducida en 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 que se tienen que hacer con el método 2. Al cambiar el endian format también requiere igualmente 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.

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

Los pasos están descritos en detalle en:

Database Administrator’s Guide 12.2 15.2 Transporting Databases

https://docs.oracle.com/en/database/oracle/oracle-database/12.2/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 Streams o Oracle GoldenGate

Oracle Streams permite la replicación de objetos y datos dentro de la misma base de datos o a otra base de datos y puede ser utilizada para la migración entre plataformas. Además de complejidad, tiene ciertas restricciones de tipos de datos y puede generar posibles problemas de rendimiento por lo que no se recomienda su uso para este fin. Además la tecnología está "deprecated" en la versión 12c y será descontinuada en próximas versiones.

Oracle recomienda como tecnología de replicación de datos Oracle GoldenGate que es mucho más potente en funcionalidad y rendimiento y donde se minimizan los problemas respecto al uso de Oracle Streams. Oracle GoldenGate permite minimizar el tiempo de parada así como la posible marcha atrás de una migración. Oracle GoldenGate requiere licenciamiento extra.

Estas alternativas no son cubiertas en este documento.

Referencia al uso de Streams y Oracle GoldenGate para migraciones:

http://docs.oracle.com/cd/E11882_01/server.112/e17069/ap_strmnt.htm#STRMS165

http://docs.oracle.com/goldengate/c1221/gg-winux/GWUAD/GUID-8CFB0335-2F51-4B50-9830-AC5822DB7C82.htm#GWUAD110






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






12 de abril de 2019


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.


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.



12 de abril de 2019


Cross-platform transportable tablespaces en versión 11.2.0.4

Este método permite mover datafiles entre plataformas de diferente “endian format” y ser asignados a bbdd en versión 11.0.2.4.

A continuación se indicarán todas las alternativas en versión 11.2.0.4 al método 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)

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


12 de abril de 2019


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 Incremental Backup

Permite migrar tablespaces entre plataformas de distinto endian format de forma incremental minimizando el tiempo de parada.

Con el uso un 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.



12 de abril de 2019



2. Chequeo prerrequisitos

3. Ejecución fases nota 11G - Reduce Transportable Tablespace Downtime using Cross Platform Incremental Backup (Doc ID 1389592.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, la nota 11G - Reduce Transportable Tablespace Downtime using Cross Platform Incremental Backup (Doc ID 1389592.1) indica paso a paso las tareas a ejecutar 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


12 de abril de 2019


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 automatizados, 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.

- Los backup copy generados en el convert 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), a no ser que se utilice la opción DBMS_FILE_TRANSFER que hará la copia por red y la conversión automáticamente.

- El método podría usarse para directamente migrar tablespaces de versiones 10.2.0.x y superiores a versión 11.2.0.4 en otra plataforma.

- Para Linux x86-64 el destino se podría usar 11.2.0.3 y 11.2.0.2, pero habría que utilizar un ORACLE_HOME y una instancia auxiliar en 11.2.0.4. En este caso no se podría usar la alternativa dbms_file_transfer.

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)







12 de abril de 2019



Este método permite mover datafiles entre plataformas de diferente “endian format” y ser asignados a bbdd en versión 12.1.0.2.

A continuación se indicarán todas las alternativas en versión 12.1.0.2 al método 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:


12 de abril de 2019


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

6. En destino hacer el restore e 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.

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

Cross-Platform Data Transport usando Inconsistent Backups (incremental)

En 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 datafiles 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


12 de abril de 2019


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 12C - Reduce Transportable Tablespace Downtime using Cross Platform Incremental Backup (Doc ID 2005729.1)

Alternativa 1: Sin usar scripts




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 'Solaris[tm] OE (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


12 de abril de 2019


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


12 de abril de 2019


Alternativa 2: Usando scripts de la nota 12C - Reduce Transportable Tablespace Downtime using Cross Platform Incremental Backup (Doc ID 2005729.1)

A alto nivel las tareas que hay que ejecutar son seguir las fases indicadas en la nota 12C - Reduce Transportable Tablespace Downtime using Cross Platform Incremental Backup (Doc ID 2005729.1). En estas fases se realizan estas tareas:

1. Phase 1 - Initial Setup

Crear una nueva bbdd destino y esquemas.

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, esa 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

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).


12 de abril de 2019



- 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.

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

- En versión 12c 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 desde versiones anteriores a 12.1.0.2 usando Backup Sets

Aunque las alternativas anteriores requieren origen/destino versión 12.1. El procedimiento de uso de backupset también se puede extender a versiones anteriores:

De la guía de 12.1:

“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. Además sería viable el uso de backups incrementales para minimizar el tiempo de parada.

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.


12 de abril de 2019




28 Transporting Data Across Platforms: http://docs.oracle.com/database/121/BRADV/rcmxplat.htm#BRADV05432

- 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)

http://docs.oracle.com/database/121/BRADV/rcmxplat.htm#BRADV05432





12 de abril de 2019



Aplican todas las opciones indicadas en la sección de versión 12.1.0.2 añadiendo la opción siguiente:

Cross-Platform Data Transport Data Files por red

En 12.2 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. (The COMPATIBLE initialization parameter of the source and destination databases must be set to 12.2)



28 Transporting Data Across Platforms: http://docs.oracle.com/database/122/BRADV/rman-transporting-data-across-platforms.htm#GUID-65AADCB6-CC9A-4229-9AB8-805C37E4471F

http://docs.oracle.com/database/122/BRADV/rman-transporting-data-across-platforms.htm#GUID-65AADCB6-CC9A-4229-9AB8-805C37E4471F

http://docs.oracle.com/database/122/BRADV/rman-transporting-data-across-platforms.htm#GUID-65AADCB6-CC9A-4229-9AB8-805C37E4471F

oracle ibÉrica, s · viable ya que no puede usarse un data guard de solaris operating system...

Documents