Migrar base de producción a desarrollo con menos espacio (Export/Import) | ExpoDBA

Migrar base de producción a desarrollo con menos espacio (Export/Import)

Migrar base de producción a desarrollo con menos espacio (Export/Import)

Muchas veces es tarea del DBA migrar una base de datos productiva a un ambiente de desarrollo o testing.

Generalmente estos entornos de desarrollo y test no tienen o no requieren los mismos recursos que en producción, por lo que por lo general se solicita que estas ocupen menos espacio que en producción.

 

Para lograr esto, no basta con simplemente copiar menos datos,  ya que el espacio real que ocupa la base de datos está dada por los datafiles que la contienen, por lo tanto es vital definir previamente los tablespaces que ocuparan la base destino.

 

En este caso voy a explicar como hacer el paso a una base de datos en el nuevo ambiente (Ya instalada con la misma versión y mismos paramentros), pero donde las rutas de los File system son distintas.

 

Los primero que tenemos que hacer es sacar de la base de datos destino la estructura de los tablespaces.

Esto lo hacemos con el siguiente query:

 

set pagesize 0
set long 100000
SET LONGCHUNKSIZE 10000
SET LINESIZE 150
spool script_tablespaces.sql
select 
'select dbms_metadata.get_ddl(''TABLESPACE'','''||tablespace_name || ''') from dual;' 
from dba_tablespaces where tablespace_name <> 'SYSTEM';
spool crea_tablespaces.sql
@script_tablespaces.sql
spool off


 

Este script genera el script crea_tablespaces.sql el cual tiene los scripts de creación de todos los tablespaces de la base de datos origen con sus respectivos datafiles, incluyendo temporales y system.

 

Este archivo es el que debemos editar para poder crear los tablespaces en la base destino.

La modificación que tenemos que hacer es justamente en los datafiles de cada tablespaces, modificando lo siguiente:

  • La ruta de creación de los datafiles
  • el tamaño de los datafiles
  • y la cantidad de datafiles

 

Ejemplo:

Supongamos que el script generado sea:

CREATE TABLESPACE "TAB_1" DATAFILE
  '/oracle_origen/TAB_1_1.dbf' SIZE 4027600896 REUSE ,
  '/oracle_origen/TAB_1_2.dbf' SIZE 4027600896 REUSE ,
  '/oracle_origen/TAB_1_3.dbf' SIZE 4027600896 REUSE ,
  '/oracle_origen/TAB_1_4.dbf' SIZE 4027600896 REUSE ,
  '/oracle_origen/TAB_1_5.dbf' SIZE 4027600896 REUSE
  NOLOGGING ONLINE PERMANENT BLOCKSIZE 4096
  EXTENT MANAGEMENT LOCAL AUTOALLOCATE SEGMENT SPACE MANAGEMENT MANUAL

 

Nosotros queremos que en vez de 20GB este tablespace sea de solo 5GB y que se encentre en un File system que exista en la base destino:

 

CREATE TABLESPACE "TAB_1" DATAFILE
  '/oracle_destino/TAB_1_1.dbf' SIZE 5000M REUSE
  NOLOGGING ONLINE PERMANENT BLOCKSIZE 4096
  EXTENT MANAGEMENT LOCAL AUTOALLOCATE SEGMENT SPACE MANAGEMENT MANUAL

 

Así debemos modificar todos los tablespaces en el script para luego ejecutarlo en el destino.

 

Una vez terminado el script, lo ejecutamos en la base destino para que cree los tablespaces.

 

Hasta este punto tenemos las 2 bases de datos con exactamente los mismos tablespaces, pero con los del destino de menor tamaño que los de origen y con diferente ubicación.

 

Ahora lo que resta es realizar un export full de la base origen, sin filas, con solamente la estructura de tablas, usuarios, sequencias, procedures, etc....

 

exp userid=/ full=y file=full.dmp ROWS=N

 

Y este dump debemos importarlo en la base destino.

 

imp userid=/ full=Y file=full.dmp ignore=y log=log_import.sql

 

Este import intentará recrear todo el ambiente de la base origen en la base destino, pero como nosotros creamos en el paso anterior todos los tablespaces (con las ubicaciones y tamaños que nosotros especificamos), este import fallará, por lo que especificamos la clausula IGNORE=Y, para que cuando genere el error de tablespace, los ignore y continúe con el resto de la base.

Las tablas e indices serán generados en los tablespaces correspondientes.

 

Una vez que termina, debemos verificar el log para asegurarnos que todo salió bien (en el caso de que falle algo por falta de espacio o lo que sea, investigar la causa del fallo, resolverla y volver a importar solo los objetos que fallaron.), comparar los esquemas, y luego dedicarnos a cargar nuestro nueva base con datos, ya sea porciones sacadas de producción o datos de prueba que ya tenga lista el área de desarrollo.