Oracle Data Pump

Desde la versión 10gR1 de Oracle Database disponemos de una nueva herramienta para la carga/descarga de datos en formato nativo Oracle: Oracle Data Pump.

Es importante entender cómo funciona Oracle Data Pump, ya que ha sufrido grandes cambios si lo comparamos con el export/import tradicional, en concreto, ha pasado de ser una herramienta cliente a ser un trabajo en el servidor.

En esta entrada de blog intentaré aclarar en especial este punto, que creo, es el más difícil de entender al enfrentarse por primera vez a esta herramienta.

Al hablar de Data Pump en ningún caso digo “nueva herramienta”, ya que hace ocho años que la tenemos disponible (como ya he dicho desde la versión de BBDD 10gR1 en el 2003), pero para mi sorpresa mucha gente la sigue usando como si del export/import se tratara (cuando no usan directamente el export/import).

Otro punto a tener en cuenta es que el export/import está ya fuera de soporte. Esto implica que no deberíamos usar el export/import en nuestras BBDD 10g/11g, entre otras cosas porque no soportan (ni soportarán) los nuevos formatos de datos que han aparecido en estas versiones del gestor, y que tampoco podremos abrir casos de soporte para ellos en 10g/11g.

De todos modos, los binarios del export/import siguen estando presentes en las BBDD 10g y 11g para permitirnos migrar datos desde  BBDD de versiones inferiores (por ejemplo de una 9i a una 11g). Esto es así porque los ficheros generados por el export/import no son validos para Oracle Data Pump y los de Data Pump tampoco lo son para export/import.

La idea principal que debemos tener clara es que Oracle Data Pump se ejecuta en el servidor, digamos que es una tarea en el servidor. Anteriormente podíamos instalar los binarios de export/import en una máquina cualquiera (no necesariamente en el servidor , podía ser un PC cliente), estas herramientas se conectaban por Oracle Net a la BBDD y extraían/cargaban los datos. Actualmente con Data Pump lo que hacemos es programar una tarea en el servidor (sea por línea de comandos, sea con Enterprise Manager/Database Console o sea mediante PL/SQL), por tanto los ficheros de dump se generarán o leerán en el servidor de BBDD.

Esto implica que no podremos “escribir” o “leer” un fichero de dump que esté ubicado fuera del servidor (por ejemplo en nuestro PC cliente), ya que los procesos que intentarán “escribirlo” o “leerlo” no tendrán acceso a él. Lo que si podemos hacer, no obstante, es montar en el servidor de BBDD una unidad compartida y escribir/leer en ésta.

Para poder escribir o leer le deberemos indicar al proceso de Data Pump donde hacerlo. Para esto usaremos un objeto de tipo “DIRECTORY” de la BBDD, que deberemos tener creado previamente y en el que deberemos tener permisos de lectura/escritura. No deberemos usar, como se hacía con el export/import  el nombre físico del directorio.

Teniendo esto claro os introduzco un poco más en el “día a día” de la herramienta… y para el final una agradable sorpresa introducida en la 11gR2.

¿Por qué usar Oracle Data Pump?

Aparte de porque “toca”, pues porque mejora en mucho a sus predecesoras:

• Gestiona infinitamente mejor el tema del “mapeo” de esquemas y tablespaces (una de las pesadillas del antiguo export/import).
• Permite compresión de los datos “al vuelo”, ya no es necesario exportar y comprimir vía “pipe” o una vez exportado (sólo Enterprise Edition).
• Nos da un control extraordinario de que exportar y cómo hacerlo, podemos filtrar que objetos queremos y que objetos no (incluso a nivel de filas para tablas concretas).
• Si se detiene por problemas, en ciertos casos (por ejemplo si se ha quedado sin espacio en el tablespace) no aborta, se pone en pausa y permite solucionar el problema y continuar.
• Permite paralelizar y cambiar el paralelismo “al vuelo”, aumentando o disminuyendo el número de procesos de carga/extracción (solo Enterprise Edition).
• Permite cargar datos “al vuelo” de otra BBDD mediante DBLink, esto es, sin pasar por fichero en disco (incompatible con campos de tipo LONG y RAW).
• Permite exportar datos de un SCN o timestamp anterior al actual, lo que permite exportar la BBDD como estaba en un momento anterior del tiempo.
• Según Oracle es MUCHO más rápida que sus predecesoras, citando textualmente:

Data Pump Export and Import utilities are typically much faster than the original Export and Import Utilities. A single thread of Data Pump Export is about twice as fast as original Export, while Data Pump Import is 15-45 times fast than original Import.

No sé si llega a 45 veces más rápido, pero para volúmenes de datos grandes y en un a Enterprise Edition el límite lo pondrá el sistema de entrada salida de disco del servidor no la herramienta.

Y seguro que me dejo cosas…

Con todo esto, por qué creo que no se empezó a usar de manera generalizada?

• Por inercia, si ya tienes cantidad de scripts preparados para export/import y estas herramientas siguen estando ahí por qué cambiar?
• Por desconocimiento de la herramienta y sus posibilidades
• En las primeras versiones (especialmente en la 10gR1) existían gran cantidad de bugs relacionados con Oracle Data Pump, que han sido solucionados en versiones posteriores.
• Por ciertas limitaciones graves de las primeras versiones, por ejemplo:

Lanzando Data Pump desde línea de comandos no era posible definir que los datos fueran consistentes.

Si el fichero de datos ya existía en disco el proceso fallaba y no se disponía del parámetro que indicara a Data Pump que queríamos “sobre escribir” los datos

• Sólo es posible ejecutarlo en el mismo servidor de BBDD (todos los que acostumbraban a exportar/importar en máquinas cliente tenían que adaptar los scripts, crear recursos compartidos…)

La mayoría de estos problemas se han ido solucionando. Con el Data Pump de la 11gR2 podemos especificar que el export sea consistente, que se sobrescriba el fichero previo en caso de existir y… tiene un modo “legacy”.

El modo legacy hace que si llamamos a expdp o impdp con parámetros de las herramientas anteriores (export/import) los interprete y adapte a la nueva versión automáticamente.

De hecho al incluir cualquier parámetro “legacy” hace entrar a Data Pump en modo “legacy” por lo que define todos los parámetros “por defecto” para que coincidan con los que tenían las herramientas previas.

En resumen, todos los que no usan expdp/impdp a fecha de hoy ya no tienen excusa.


Fuente: http://blog.avanttic.com/2011/09/13/del-exportimport-a-oracle-data-pump/#more-4160