INFORME DE MIGRACION DE DATOS UTILIZANDO ORACLE RMAN CONVERT CON TRANSPORT TABLESPACE

Transcripción

1 INFORME DE MIGRACION DE DATOS UTILIZANDO ORACLE RMAN CONVERT CON TRANSPORT TABLESPACE 1

2 Índice Objetivo:... 3 Información:... 3 Caso de uso:... 3 Detalles de la implementación Verificación de Formatos Endian Identificación de tablespaces a migrar Verificación de Violaciones SELF CONTAINED Verificación de Restricciones de tipos de dato Relevamiento de cantidad de Segmentos y tamaño por tablespace Verificación de tablas externas o BFILES Comienzo de la migración Verificación de Instancia y Host Pasar los tablespaces a migrar a solo lectura Relevamiento de la cantidad de objetos x owner Export de los tablespaces utilizando TRANSPORT_TABLESPACE Utilización de RMAN Convert para el cambio de plataforma Copia SCP de los archivos generados Import de los tablespaces utilizando TRANSPORT_TABLESPACE + Datafiles Cambio de nombre a los datafiles Modificación de los tablespaces Cambio de los Tablespaces a accesibles y de lectura y escritura Verificación de los datafiles y Tablespaces en la base destino Comentarios y Conclusiones:

3 Objetivo: Documentar la utilización de la herramienta de Oracle RMAN Convert + Transport tablespace para realizar migraciones entre bases de datos en servidores de distintos formatos endians Información: Sabemos que no se puede migrar directamente una base de datos física mediante un backup cuando las 2 arquitecturas de Sistema Operativo son distintas ya que el código endian difiere según la plataforma. En nuestro caso tenemos en el servidor de la base de datos origen a migrar un endian code = Little (Linux x86/64) y en el servidor destino un endian code = Big (Solaris10 (SPARC)). Cuando tenemos este tipo de escenario, tenemos que utilizar para migrar datos el clásico método de Export / Import o a partir de 10g también el método mejorado de DATAPUMP. Si la base de datos a migrar o el esquema a migrar son muy grandes, el proceso de Export/Import o Exp DATAPUMP puede llegar a demandar mucho tiempo, para bajar dichos tiempos se puede utilizar la herramienta de Oracle RMAN con el método Convert y el método Transport Tablespaces.- El documento presenta a modo de prueba la Migraron de 2 tablespaces de una base de datos Oracle alojada en un sistema Operativo Linux Red-Hat 5.4 a una base de datos Oracle alojada en un Sistema Operativo Solaris 10 (SPARC). Caso de uso: Base de datos Origen: HANIF (Maqueta Oracle) Host: oratest1 Sistema Operativo: Red Hat Linux 5.7 IP: 1xxxxxxxxx Motor de base de datos: Oracle Tablespaces a Migrar: GNSIT_DATA, GNSIT_IDX Esquema: GNSIT Base de datos destino: HANIF (creada vacía sin esquemas custom) Host: neutrino Sistema Operativo: Solaris 10 (SPARC) IP: 1xxxxxxxxxxxx Motor de base de datos: Oracle Esquema: GNSIT 3

4 Detalles de la implementación 1. Verificación de Formatos Endian Conectados a la base de datos Origen, consultamos la información de los formatos ENDIAN soportados. INSTANCE_NAME HOST_NAME HANIF oratest1 SQL> select * from v$transportable_platform order by platform_id; PLATFORM_ID PLATFORM_NAME ENDIAN_FORMAT Solaris[tm] OE (32-bit) Big 2 Solaris[tm] OE (64-bit) Big 3 HP-UX (64-bit) Big 4 HP-UX IA (64-bit) Big 5 HP Tru64 UNIX Little 6 AIX-Based Systems (64-bit) Big 7 Microsoft Windows IA (32-bit) Little 8 Microsoft Windows IA (64-bit) Little 9 IBM zseries Based Linux Big 10 Linux IA (32-bit) Little 11 Linux IA (64-bit) Little PLATFORM_ID PLATFORM_NAME ENDIAN_FORMAT Microsoft Windows x86 64-bit Little 13 Linux x86 64-bit Little 15 HP Open VMS Little 16 Apple Mac OS Big 17 Solaris Operating System (x86) Little 18 IBM Power Based Linux Big 19 HP IA Open VMS Little 20 Solaris Operating System (x86-64) Little 21 Apple Mac OS (x86-64) Little 20 rows selected. Se puede observar en rojo los dos códigos endian utilizados por la base de datos Origen y la destino, ambos códigos son distintos por lo que no se puede llevar a cabo una migración de la base de datos física mediante un backup y restore. Por tal motivo se debe recurrir al método de Export / Import o Datapump, estos métodos dependiendo del tamaño de la base de datos o del esquema a Migrar, pueden insumir mucho tiempo, para bajar estos tiempos, podemos utilizar la herramienta de Oracle RMAN (Recovery Manager) con el método CONVERT.- 2. Identificación de tablespaces a migrar Identificamos los tablespaces a Migrar, en este caso como vamos a migrar el esquema GNSIT, se migraran todos los tablespaces de dicho esquema. SQL> SELECT TABLESPACE_NAME 2 FROM DBA_SEGMENTS 3 WHERE OWNER='GNSIT' 4 GROUP BY TABLESPACE_NAME 5 ORDER BY 1; TABLESPACE_NAME GNSIT_DATA GNSIT_IDX 4

5 3. Verificación de Violaciones SELF CONTAINED Ejecución de package de Oracle para identificar si existen violaciones Self Contained antes de la migración.- SQL>BEGIN SYS.dbms_tts.transport_set_check ('GNSIT.GNSIT_DATA,GNSIT.GNSIT_IDX', incl_constraints=>true, full_check=>false); END; / PL/SQL procedure successfully completed. Una vez ejecutada la package, podemos consultar a la vista TRANSPORT_SET_VIOLATIONS para ver si existe alguna violación: SQL> select * from sys.transport_set_violations; no rows selected 4. Verificación de Restricciones de tipos de dato DataPump no puede realizar una migración con tipos de dato XML y el export tradicional no puede realizar una migración con tipos de dato BINARY_FLOAT y BINARY_DOUBLE. Para verificar si existen este tipo de datos ejecutamos la siguiente consulta: SELECT tc.data_type, t.table_name,count(*) FROM dba_tables t, dba_tab_columns tc WHERE t.owner = 'GNSIT' AND tc.owner = t.owner AND tc.table_name = t.table_name GROUP BY tc.data_type,t.table_name ORDER BY 1; DATA_TYPE TABLE_NAME COUNT(*) BLOB GNSIT_IMAGENES 1 NUMBER GNSIT_TIPOPAR 1 NUMBER GNSIT_PROYXEST 2 NUMBER GNSIT_SO 1 NUMBER GNSIT_SECTORES 1 NUMBER GNSIT_ESTADO 1 NUMBER GNSIT_ITEMSPROY 1 NUMBER GNSIT_SERVICIOS 1 NUMBER GNSIT_CINTAS 3 NUMBER GNSIT_PARAMETROS 2 NUMBER PRUEBA 2 NUMBER GNSIT_EVENTOS 8 NUMBER GNSIT_PROY 12 NUMBER GNSIT_OBSPROY 3 NUMBER GNSIT_TIPOCLI 1 NUMBER GNSIT_USUARIOS 1 NUMBER GNSIT_ETAPASPROY 1 NUMBER GNSIT_SYSUSERS 4 NUMBER GNSIT_CLIENTES 2 NUMBER GNSIT_LOG 2 NUMBER GNSIT_TIPOINV 1 5

6 DATA_TYPE TABLE_NAME COUNT(*) NUMBER GNSIT_CRONBACKUP 3 NUMBER GNSIT_TIPOPROY 1 NUMBER MICROSOFTDTPROPERTIES 3 NUMBER GNSIT_PRIORIDAD 1 NUMBER GNSIT_IMAGENES 1 NUMBER GNSIT_INVENTARIO 7 NUMBER GNSIT_CLASESTEC 1 NUMBER GNSIT_LOG_HIST 2 NUMBER GNSIT_DOCUMENTOS 1 VARCHAR2 GNSIT_LOG_HIST 2 VARCHAR2 GNSIT_PRIORIDAD 1 VARCHAR2 GNSIT_ESTADO 1 VARCHAR2 GNSIT_CLASESTEC 1 VARCHAR2 GNSIT_TIPOPROY 1 VARCHAR2 GNSIT_PROY 13 VARCHAR2 GNSIT_USUARIOS 5 VARCHAR2 GNSIT_TIPOINV 1 VARCHAR2 GNSIT_SERVICIOS 1 VARCHAR2 GNSIT_TIPOCLI 1 VARCHAR2 GNSIT_LOG 2 VARCHAR2 GNSIT_DOCUMENTOS 2 VARCHAR2 GNSIT_SO 1 VARCHAR2 GNSIT_PARAMETROS 1 VARCHAR2 GNSIT_EVENTOS 6 VARCHAR2 GNSIT_SYSUSERS 5 VARCHAR2 PRUEBA 1 VARCHAR2 GNSIT_ITEMSPROY 1 VARCHAR2 MICROSOFTDTPROPERTIES 3 VARCHAR2 GNSIT_SECTORES 1 VARCHAR2 GNSIT_OBSPROY 1 VARCHAR2 GNSIT_CLIENTES 3 VARCHAR2 GNSIT_ETAPASPROY 1 VARCHAR2 GNSIT_TIPOPAR 1 VARCHAR2 GNSIT_INVENTARIO 9 VARCHAR2 GNSIT_CINTAS 6 VARCHAR2 GNSIT_CRONBACKUP 2 No existen problemas con el tipo de datos en las tablas, ahora verificamos lo mismo a nivel tablespace: SELECT xt.owner, at.table_name FROM dba_xml_tables xt, all_all_tables at WHERE at.owner = xt.owner AND at.table_name = xt.table_name AND at.tablespace_name IN('GNSIT_DATA','GNSIT_IDX') no rows selected. Vemos tampoco tenemos problemas de tipo de dato en los tablespaces 6

7 5. Relevamiento de cantidad de Segmentos y tamaño por tablespace SELECT tablespace_name, segment_type, COUNT(*), SUM (bytes) / 1024 mb FROM dba_segments WHERE owner = 'GNSIT' GROUP BY tablespace_name, segment_type ORDER BY 1, 2 DESC; TABLESPACE_NAME SEGMENT_TYPE COUNT(*) MB GNSIT_DATA TABLE GNSIT_DATA LOBSEGMENT 1 64 GNSIT_DATA LOBINDEX 1 64 GNSIT_DATA INDEX GNSIT_IDX INDEX Cantidad de Segmentos x owner SELECT owner, COUNT(*) FROM dba_segments WHERE tablespace_name IN ('GNSIT_DATA', 'GNSIT_IDX') GROUP BY owner; OWNER GNSIT 58 COUNT(*) 6. Verificación de tablas externas o BFILES Para utilizar transport tablespace(o database) es necesario verificar si existen tablas externas, directorios o BFILES, en este caso una vez verificado y en caso de existir este tipo de objetos, se deben migrar manualmente. 7. Comienzo de la migración 7.1. Verificación de Instancia y Host Mediante la siguiente consulta identificamos el nombre de la instancia: SQL> SELECT INSTANCE_NAME FROM V$INSTANCE; INSTANCE_NAME HOST_NAME HANIF oratest1 SQL> 7.2. Pasar los tablespaces a migrar a solo lectura SQL> ALTER TABLESPACE GNSIT_DATA READ ONLY; SQL>ALTER TABLESPACE GNSIT_IDX READ ONLY; 7.3. Relevamiento de la cantidad de objetos x owner Esto se utiliza para es para validar que luego de la migración se hayan importado todos los objetos: SELECT COUNT(OBJECT_NAME) FROM DBA_OBJECTS WHERE OWNER='GNSIT'; Count(object_name) 110 7

8 SELECT COUNT(OBJECT_TYPE),OBJECT_TYPE FROM DBA_OBJECTS WHERE OWNER='GNSIT' GROUP BY OBJECT_TYPE ORDER BY OBJECT_TYPE; Count(Object_type) Object_type 28 INDEX 1 LOB 1 PACKAGE 39 PROCEDURE 29 TABLE 12 VIEW 7.4. Export de los tablespaces utilizando TRANSPORT_TABLESPACE Se debe realizar con el privilegio SYSDBA oracle@oratest1:~/exports>exp file=exp_schema_gnsit.dmp log=exp_schema_gnsit.log transport_tablespace=y tablespaces=gnsit_data,gnsit_idx STATISTICS=NONE Export: Release Production on Fri Mar 15 13:41: Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved. Username: sys as sysdba Password: Connected to: Oracle Database 11g Enterprise Edition Release bit Production With the Partitioning, OLAP, Data Mining and Real Application Testing options Export done in US7ASCII character set and AL16UTF16 NCHAR character set server uses WE8MSWIN1252 character set (possible charset conversion) Note: table data (rows) will not be exported About to export transportable tablespace metadata... For tablespace GNSIT_DATA.... exporting cluster definitions. exporting table definitions.. exporting table GNSIT_CINTAS.. exporting table GNSIT_CLASESTEC.. exporting table GNSIT_CRONBACKUP.. exporting table GNSIT_DOCUMENTOS.. exporting table GNSIT_ESTADO.. exporting table GNSIT_EVENTOS.. exporting table GNSIT_INVENTARIO.. exporting table GNSIT_LOG.. exporting table GNSIT_PARAMETROS.. exporting table GNSIT_PRIORIDAD.. exporting table GNSIT_SECTORES.. exporting table GNSIT_SERVICIOS.. exporting table GNSIT_SYSUSERS.. exporting table GNSIT_TIPOINV.. exporting table GNSIT_TIPOPAR.. exporting table GNSIT_USUARIOS.. exporting table GNSIT_SO.. exporting table GNSIT_PROY.. exporting table GNSIT_ETAPASPROY.. exporting table GNSIT_CLIENTES.. exporting table GNSIT_TIPOCLI.. exporting table MICROSOFTDTPROPERTIES.. exporting table GNSIT_TIPOPROY.. exporting table GNSIT_PROYXEST.. exporting table GNSIT_OBSPROY.. exporting table GNSIT_ITEMSPROY.. exporting table GNSIT_LOG_HIST.. exporting table PRUEBA.. exporting table GNSIT_IMAGENES For tablespace GNSIT_IDX.... exporting cluster definitions. exporting table definitions 8

9 . exporting referential integrity constraints EXP-00091: Exporting questionable statistics.. exporting triggers. end transportable tablespace metadata export Export terminated successfully without warnings. Se puede observar que solo exporta la metadata y no los registros que poseen cada una de las tablas 7.5. Utilización de RMAN Convert para el cambio de plataforma RMAN> CONVERT TABLESPACE GNSIT_DATA,GNSIT_IDX 2> TO PLATFORM 'Solaris[tm] OE (64-bit)' 3> format = '/home/oracle/exports/hanif/%u'; Starting conversion at source at 15-MAR-13 using channel ORA_DISK_1 channel ORA_DISK_1: starting datafile conversion input datafile file number=00006 name=/u02/oradata/hanif/gnsit_data01.dbf converted datafile=/home/oracle/exports/hanif/data_d-hanif_i _ts-gnsit_data_fno- 6_08o4jkak channel ORA_DISK_1: datafile conversion complete, elapsed time: 00:00:46 channel ORA_DISK_1: starting datafile conversion input datafile file number=00007 name=/u02/oradata/hanif/gnsit_idx01.dbf converted datafile=/home/oracle/exports/hanif/data_d-hanif_i _ts-gnsit_idx_fno- 7_09o4jkc3 channel ORA_DISK_1: datafile conversion complete, elapsed time: 00:00:15 Finished conversion at source at 15-MAR-1 Una vez realizados los converts de los tablespaces los datafiles se generaran en el directorio utilizado por el comando format(se puede utilizar db_file_name_convert adjunto tambien un ejemplo), en este caso se generaron los archivos: /home/oracle/exports/hanif/data_d-hanif_i _ts-gnsit_data_fno-6_08o4jkak /home/oracle/exports/hanif/data_d-hanif_i _ts-gnsit_idx_fno-7_09o4jkc3 Ejemplo de RMAN Convert utilizando db_file_name_convert: RMAN> convert tablespace EXAMPLE to platform 'Solaris[tm] OE (64-bit)' 2> DB_FILE_NAME_CONVERT ('/u02/oradata/hanif','/home/oracle/exports/hanif'); Starting conversion at source at 21-MAR-13 using target database control file instead of recovery catalog allocated channel: ORA_DISK_1 channel ORA_DISK_1: SID=20 device type=disk channel ORA_DISK_1: starting datafile conversion input datafile file number=00005 name=/u02/oradata/hanif/example01.dbf converted datafile=/home/oracle/exports/hanif/example01.dbf channel ORA_DISK_1: datafile conversion complete, elapsed time: 00:00:15 Finished conversion at source at 21-MAR-13 En este caso se generó el archivo: /home/oracle/exports/hanif/example01.dbf 9

10 7.6. Copia SCP de los archivos generados Los archivos generados en el punto anterior se copian al servidor de la base de datos destino mediante scp total rw-r oracle oinstall mar 15 16:02 data_d-hanif_i _ts- GNSIT_DATA_FNO-6_08o4jkak -rw-r oracle oinstall mar 15 16:02 data_d-hanif_i _ts- GNSIT_IDX_FNO-7_09o4jkc3 oracle@oratest1:~/exports/hanif>scp * oracle@ :/test/oradata/hanif Password: data_d-hanif_i _ts-gnsit_data_fno-6_08o4jkak 100% 500MB 10.6MB/s 00:47 data_d-hanif_i _ts-gnsit_idx_fno-7_09o4jkc3 100% 100MB 11.1MB/s 00:09 oracle@oratest1:~/exports/hanif>scp exp_schema_gnsit.dmp oracle@ :/test/oradata/hanif exp_schema_gnsit.dmp 100% 100MB 11.1MB/s 00: Import de los tablespaces utilizando TRANSPORT_TABLESPACE + Datafiles Antes de realizar el import, si se utiliza el método tradicional, se debe realizar previamente la creación del usuario en la base de datos destino, si se utiliza datapump, no es necesario este paso. En este caso, se utilizó el import tradicional por lo que previamente se creo el usuario GNSIT en la base de datos destino Se realiza el import de la metadata incluyendo los datafiles migrados: oracle@neutrino:/test/oradata/hanif>imp file=exp_schema_gnsit.dmp log=imp_schema_gnsit.log transport_tablespace=y datafiles=/test/oradata/hanif/data_d-hanif_i _ts- GNSIT_DATA_FNO-6_08o4jkak,/test/oradata/HANIF/data_D-HANIF_I _TS-GNSIT_IDX_FNO- 7_09o4jkc3 Import: Release Production on Thu Mar 21 12:31: Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved. Username: sys as sysdba Password: Connected to: Oracle Database 11g Enterprise Edition Release bit Production With the Partitioning, OLAP, Data Mining and Real Application Testing options Export file created by EXPORT:V via conventional path About to import transportable tablespace(s) metadata... import done in AL32UTF8 character set and AL16UTF16 NCHAR character set import server uses WE8MSWIN1252 character set (possible charset conversion) export client uses US7ASCII character set (possible charset conversion). importing GNSIT's objects into GNSIT.. importing table GNSIT_CINTAS.. importing table GNSIT_CLASESTEC.. importing table GNSIT_CRONBACKUP.. importing table GNSIT_DOCUMENTOS.. importing table GNSIT_ESTADO.. importing table GNSIT_EVENTOS.. importing table GNSIT_INVENTARIO.. importing table GNSIT_LOG.. importing table GNSIT_PARAMETROS.. importing table GNSIT_PRIORIDAD.. importing table GNSIT_SECTORES.. importing table GNSIT_SERVICIOS.. importing table GNSIT_SYSUSERS.. importing table GNSIT_TIPOINV 10

11 .. importing table GNSIT_TIPOPAR.. importing table GNSIT_USUARIOS.. importing table GNSIT_SO.. importing table GNSIT_PROY.. importing table GNSIT_ETAPASPROY.. importing table GNSIT_CLIENTES.. importing table GNSIT_TIPOCLI.. importing table MICROSOFTDTPROPERTIES.. importing table GNSIT_TIPOPROY.. importing table GNSIT_PROYXEST.. importing table GNSIT_OBSPROY.. importing table GNSIT_ITEMSPROY.. importing table GNSIT_LOG_HIST.. importing table PRUEBA.. importing table GNSIT_IMAGENES Import terminated successfully without warnings Cambio de nombre a los datafiles Una vez finalizado el import, por una cuestión de orden, vamos a cambiar el nombre de los datafiles correspondientes a los tablespaces migrados ya que el nombre generado por el convert (recordar que para evitar esto se puede utilizar db_file_name_convert) no corresponde con la nomenclatura utilizada por nosotros para las bases de datos: Pasamos los tablespaces a modo offline: SQL>alter tablespace gnsit_data offline SQL> alter tablespace gnsit_idx offline Desde el sistema operativo: oracle@neutrino:/test/oradata/hanif> mv /test/oradata/hanif/data_d-hanif_i _ts- GNSIT_DATA_FNO-6_08o4jkak /test/oradata/test/gnsit_data01.dbf oracle@neutrino:/test/oradata/hanif> mv /test/oradata/hanif/data_d-hanif_i _ts- GNSIT_IDX_FNO-7_09o4jkc3/test/oradata/TEST/gnsit_idx01.dbf 7.9. Modificación de los tablespaces Para reflejar en la base de datos el cambio realizado en el punto anterior: En la base de datos: SQL>alter tablespace GNSIT_DATA rename datafile '/test/oradata/hanif/data_d-hanif_i _TS-GNSIT_DATA_FNO-6_08o4jkak' to '/test/oradata/hanif/gnsit_data01.dbf' SQL> alter tablespace GNSIT_IDX rename datafile '/test/oradata/hanif/data_d-hanif_i _TS-GNSIT_IDX_FNO-7_09o4jkc3' to '/test/oradata/hanif/gnsit_idx01.dbf' 11

12 7.10. Cambio de los Tablespaces a accesibles y de lectura y escritura Ya tenemos los datafiles modificados, ahora debemos poner los tablespaces accesibles por lo que ejecutamos los siguientes SQL s: SQL>alter tablespace gnsit_data online SQL> alter tablespace gnsit_idx online SQL> alter tablespace gnsit_data read write; SQL> alter tablespace gnsit_idx read write; Verificación de los datafiles y Tablespaces en la base destino Por ultimo verificamos los datafiles y los tablespaces en la nueva base de datos: SQL> select instance_name, host_name from v$instance; INSTANCE_NAME HOST_NAME HANIF neutrino SQL> select file_name from dba_data_files; FILE_NAME /test/oradata/hanif/users01.dbf /test/oradata/hanif/undotbs01.dbf /test/oradata/hanif/sysaux01.dbf /test/oradata/hanif/system01.dbf /test/oradata/hanif/gnsit_data01.dbf /test/oradata/hanif/gnsit_idx01.dbf /test/oradata/hanif/example01.dbf SQL> select tablespace_name,status 2 from dba_tablespaces; TABLESPACE_NAME STATUS SYSTEM ONLINE SYSAUX ONLINE UNDOTBS1 ONLINE TEMP ONLINE USERS ONLINE GNSIT_DATA ONLINE GNSIT_IDX ONLINE 12

13 Podemos también consultar alguna tabla del esquema GNSIT: SQL> SELECT * FROM GNSIT.GNSIT_SECTORES; COD_SECTOR SECTOR ADMINISTRACION 2 SOPORTE TECNICO 3 TICKET 4 TARJETA 5 DESARROLLO 6 TECNOLOGIA 7 CALL CENTER 8 MULTIPAGOS 9 ATM 10 COMERCIAL 11 CANJE COD_SECTOR SECTOR COMPUTOS 13 EMBOZADORA 14 GERENCIA OPERACIONES 15 GUARDIA 16 MULTADM 17 RRHH 18 SEGTARJETA 19 COMPLEMENTACIONES 20 CONTADURIA 21 SEGURIDAD FISICA 22 GERENCIA SISTEMAS 22 rows selected. Ya tenemos migrados los datos desde un servidor con base de datos con format endian Little (HANIF en oratest1) a un servidor con base de datos con formato endian big(hanif en neutrino) utilizando RMAN Convert + Transport Tablespace 8. Comentarios y Conclusiones: Ventaja: Tiempo Si bien en esta prueba no se pueden tomar como parámetros los tiempos utilizados ya que el esquema de prueba migrado es muy chico, obteniendo información de casos de uso reales, se baja aproximadamente un 40% en los tiempos insumidos utilizando RMAN Convert + Transport Tablespace. Adjunto tabla de un caso de uso real: Export/Import Export time 37 min 2 min File transfer time 8 min 13 min File conversion time n/a 14 min Import time 42 min 2 min Approximate total time 87 min 31 min Export file size 4100 Mb 640 Kb Target database extra TEMP tablespace requirement 1200 Mb n/a Tablespace Transport 13

14 Desventajas: Como desventaja, en nuestro universo de base de datos (la mayoría de aplicaciones PeopleSoft), nos encontramos que las mismas poseen una gran cantidad de Tablespaces y datafiles, por lo que este tipo de proceso requerirá de sumo cuidado y orden dada la cantidad de parámetros que hay que utilizar para realizar las operaciones tanto de export/import(transport tablespace) como de RMAN Convert Recomendaciones: Se recomienda utilizar primero este método de migración en un entorno de testing para luego si realizarlo en producción.- Los únicos tiempos reales insumidos en el proceso de Transport Tablespace son los dados por RMAN Convert + la copia de los archivos al servidor o directorio destino.- El tiempo requerido para dichos procesos es directamente proporcional al tamaño de cada archivo, por eso es recomendable realizar un resize o shrink de los datafiles luego de pasar el tablespace a modo solo lectura para minimizar los tiempos de copia y RMAN Convert. Se debe tener en cuenta que esta prueba se realizó entre 2 bases de datos con el mismo motor Oracle Parche habría que investigar qué ocurre si se necesita realizar una migración entre 2 bases de datos con distinto motor Oracle.- 14