Utilidades export/import (II): Data Pump, expdp e impdp

Si las utilidades clásicas exp e imp eran herramientas de cliente, Data Pump , expdp e impdp, disponibles desde 10g, vive dentro de la base de datos. Los procesos de trabajo se ejecutan en el servidor, hablan con la instancia por API directa en lugar de por SQL fila a fila, y pueden repartirse en hilos paralelos. El resultado práctico: exportaciones que tardan minutos donde antes había horas, reanudables y con filtros declarativos. Esta entrega es el manual de uso moderno.

El directory: el cambio de mentalidad

La primera diferencia con exp es obligatoria: Data Pump no escribe donde quiere el cliente, sino en un directorio de la base de datos, un objeto que apunta a una ruta del servidor:

-- una vez, con privilegios suficientes
CREATE OR REPLACE DIRECTORY exp_dir AS '/backup/datapump';
GRANT READ, WRITE ON DIRECTORY exp_dir TO ventas;

Eso significa que el fichero resulta visible en el servidor (y trasladable por los medios del servidor), no descargable directamente por el cliente. Para traerlo a tu máquina, scp, o bien el paquete DBMS_FILE_TRANSFER.

expdp: el export que sí usa la máquina

expdp ventas/clave@PROD directory=exp_dir       dumpfile=ventas_%U.dmp logfile=exp_ventas.log       schemas=VENTAS parallel=4       compression=all       exclude=statistics

# solo dos tablas con un filtro de filas
expdp ventas/clave@PROD directory=exp_dir       dumpfile=parcial.dmp tables=clientes,facturas       query=clientes:"WHERE region = 'NORTE'"

Tres detalles que valen su peso: %U en el dumpfile genera ficheros troceados que los hilos paralelos llenan a la vez (parallel=4 con un solo fichero no paraleliza nada); compression=all comprime datos y metadatos desde 11g sin licencia extra; y exclude/include aceptan listas de objetos: excluir estadísticas y recogerlas tras el import es más rápido que transportarlas.

impdp: remapeos, el superpoder

impdp ventas2/clave@DEV directory=exp_dir       dumpfile=ventas_%U.dmp logfile=imp_ventas.log       remap_schema=VENTAS:VENTAS2       remap_tablespace=TS_VENTAS:TS_DEV       parallel=4       transform=disable_archive_logging:y

# importar solo una tabla, renombrandola
impdp ventas/clave@DEV directory=exp_dir       dumpfile=ventas_%U.dmp       tables=VENTAS.clientes       remap_table=clientes:clientes_bk

Donde imp tenía el binomio fromuser/touser, impdp ofrece remapeos de esquema, tablespace, tabla, fichero de datos e incluso función de transformación de datos. El transform=disable_archive_logging:y evita generar archivelogs durante cargas masivas en desarrollo: en producción, esa decisión es del DBA y con razón.

Los dos trucos de velocidad

• Paralelismo real: tantos ficheros de dump como valor de parallel, y estructura de tabla con muchos segmentos (las tablas particionadas se exportan en paralelo por particiones).
• Data only con APPEND: content=data_only más table_exists_action=append convierte el import en una carga directa, sin evaluar DDL.

network_link: mover entre bases sin ficheros

El parámetro que cambia la logística entera: network_link conecta un import directamente con otra base de datos mediante un dblink, y los datos cruzan sin generar un solo fichero de dump:

-- crear el enlace una vez
CREATE DATABASE LINK prod_link
  CONNECT TO ventas IDENTIFIED BY clave
  USING 'PROD';

-- importar en vivo desde produccion a desarrollo
impdp ventas2/clave@DEV directory=exp_dir       network_link=prod_link       remap_schema=VENTAS:VENTAS2       tables=clientes,facturas

Es la herramienta ideal para refrescar un esquema de desarrollo desde producción sin ocupar espacio en disco ni pedir ventanas: el trabajo consume recursos en el destino y viaja por la red de la base. El orden de los factores importa: el impdp se ejecuta en la base destino y el enlace apunta al origen. Y para refrescos periódicos, combinado con TABLE_EXISTS_ACTION=REPLACE en un trabajo programado, sustituye a años de scripts caseros de sincronización.

Vigilar mientras trabaja

A diferencia de exp, Data Pump es un trabajo de base de datos y se puede interrogar en vivo:

SELECT owner_name, job_name, operation, state,
       degree_of_parallelism
FROM   dba_datapump_jobs;

-- dentro de la sesion expdp/impdp:
> status
> stop_job
> start_job

La tabla DBA_DATAPUMP_JOBS lista los trabajos activos, y la consola interactiva acepta stop_job y start_job: un trabajo interrumpido se reanuda donde estaba. Ese ciclo interrumpir-reanudar ha salvado más ventanas de mantenimiento que cualquier planificación perfecta.

Data Pump no es una versión más rápida de exp: es un cambio de sitio. El movimiento de datos ocurre en el servidor, y eso cambia la logística completa.

En la misma línea de operaciones: el análisis del ORA-12516 cuando el sistema se queda sin procesos, y las consultas al diccionario para dimensionar lo exportado antes de lanzar el trabajo.