Utilidades export/import (I): exp e imp, las clásicas

Todo el que haya heredado una base de datos Oracle con cierta historia tiene una carpeta llena de ficheros .dmp de procedencia dudosa. La mayoría fueron creados con exp, la utilidad de exportación que Oracle mantuvo desde la versión 6 hasta su retirada formal en 12c, donde solo quedó su prima moderna Data Pump para crearlos. imp, su pareja, todavía sabe leerlos en versiones actuales. Este artículo es el manual de arqueología: cómo se usaban, qué significan sus parámetros y cómo rescatar esos ficheros hoy.

El concepto: un formato propio, fila a fila

exp volcaba tablas, esquemas o la base de datos completa a un fichero binario propio con dos virtudes: servía para mover datos entre servidores y versiones distintas, y para extraer el DDL (sentencias de creación). Su limitación estructural: era una herramienta de cliente, fila a fila y en un solo hilo, lenta para volúmenes grandes y sin redes de seguridad durante la ejecución.

# exportacion de dos tablas de un esquema
exp ventas/clave@PROD file=clientes_2026.dmp log=exp_clientes.log     tables=(clientes, facturas) rows=y indexes=y

# exportacion completa del esquema, con estadisticas
exp ventas/clave@PROD file=ventas_full.dmp owner=ventas     statistics=estimate direct=y

El parámetro direct=y merece mención: saltaba la capa SQL de evaluación de filas y leía los bloques directamente, multiplicando la velocidad a costa de usar un juego de caracteres de exportación fijo. En su día fue el truco que hacía soportables los cierres de mes.

Los parámetros que se usaban de verdad

• tables=(...) / owner=... / full=y: los tres niveles de alcance (tablas, esquema, todo).
• rows=n: solo estructura, sin datos —la manera rápida de clonar un esquema vacío en desarrollo.
• query="WHERE fecha >= DATE '2026-01-01'": exportar un subconjunto de filas, el antepasado del filtro de Data Pump.
• file y filesize con comodín %U: trocear el volcado en varios ficheros cuando el sistema de archivos tenía límites de 2 GB.
• compress=y: generaba el DDL con un tamaño inicial igual al ocupado —útil, o desastre en tablespaces compartidos, según el día.

Importar: fromuser/touser y los transportes de esquema

# volcar el esquema ventas como ventas2 (tipico al clonar entornos)
imp sistema/clave@DEV file=ventas_full.dmp     fromuser=ventas touser=ventas2 ignore=y

# solo la estructura de una tabla
imp ventas2/clave@DEV file=clientes_2026.dmp     tables=clientes rows=n ignore=y

fromuser/touser fue el mecanismo de renombrado de esquemas más usado del mundo Oracle durante dos décadas. ignore=y sigue confundiendo a los recién llegados: significa «ignora los errores de objeto existente y sigue», no «ignora las filas duplicadas». Un import con datos repetidos sobre la misma tabla sin constraint única duplica filas sin quejarse.

Leer un .dmp antiguo hoy

La cadena de compatibilidad es lo primero: imp lee ficheros creados por versiones anteriores o iguales a la suya. Un fichero exp de 9i se importa contra 11g sin drama; contra 19c ya puede exigir pasar por un eslabón intermedio. Dos órdenes de arqueólogo:

# que contiene el fichero sin importar nada
imp ventas2/clave@DEV file=clientes_2026.dmp     show=y log=contenido.log full=y

strings clientes_2026.dmp | grep -i "CREATE TABLE" | head

show=y vuelca el DDL completo al log sin tocar la base de datos: es la herramienta forense para descubrir qué escondía aquel CD del 2009. Y sí, strings sobre un .dmp revela bastante —otra buena razón para que esos ficheros nunca salgan de la red interna.

De exp a expdp: la jubilación

Data Pump (11g lo consolidó) mejora todo lo que exp hacía: hilos paralelos, reanudación, remapeos, red de trabajo en la base de datos. La única dirección de migración es crear de nuevo el fichero con expdp desde la base de datos origen; no existe conversión de formato. La segunda parte cubre expdp e impdp con ejemplos completos. La regla de archivo: exp se mantiene únicamente para leer el pasado.

Un .dmp sin log de exportación ni fecha es un mensaje en una botella: probablemente contiene algo, y casi seguro que no lo que necesitas.

Las piezas relacionadas: Data Pump, la segunda parte, la estrategia de particionado que reduce lo que hay que exportar, y el PURGE para limpiar lo que el export deja en la papelera.