Inicio > Database > Del export/import a Oracle Data Pump

Del export/import a 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 para 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.

Categorías:Database Etiquetas: , , , ,
  1. manuel
    febrero 2, 2012 en 18:58

    yo soy un de esos que no usan data pump por desconocimento

    para las DB 10g R2, como esta funcionando???

    y me podrias enviar algun ejemplo de como se debe ejecutar???

    • Rafael Planella
      febrero 19, 2012 en 13:27

      Hola,

      Básicamente los pasos para usar expdp serian los siguientes:

      Creamos desde la BBDD un directorio, que es asignar un nombre virtual a un directorio físico, de manera que si queremos cambiar de directorio destino/origen en el servidor no tengamos que modificar nuestro código de export/import.

      CONN / AS SYSDBA

      CREATE OR REPLACE DIRECTORY dir_salida AS ‘c:\directorio_export\’;
      GRANT READ, WRITE ON DIRECTORY dir_salida TO miusuario;

      Acto seguido ya podemos exportar, una tabla o tablas, un usuario o usuarios o toda la BBDD:


      expdp miusuario/mipassword@miconnectstring tables=TABLA1,TABLA2 directory=DIR_SALIDA dumpfile=tablas.dmp logfile=tablas.log

      expdp miusuario/mipassword@miconnectstring schemas=ESQUEMA1,ESQUEMA2 directory=DIR_SALIDA dumpfile=esquemas.dmp logfile=esquemas.log

      expdp system/system_password@miconnectstring full=Y directory=DIR_SALIDA dumpfile=exp_full.dmp logfile=exp_full.log

      Finalmente para cargar nuevamente estos datos en el gestor cambiamos el expdp por impdp


      impdp miusuario/mipassword@miconnectstring tables=TABLA1,TABLA2 directory=DIR_SALIDA dumpfile=tablas.dmp logfile=imp_tablas.log

      impdp miusuario/mipassword@miconnectstring schemas=ESQUEMA1,ESQUEMA2 directory=DIR_SALIDA dumpfile=esquemas.dmp logfile=imp_esquemas.log

      impdp system/system_password@miconnectstring full=Y directory=DIR_SALIDA dumpfile=exp_full.dmp logfile=imp_exp_full.log

      Nota: Podemos importar solo una parte (ciertos esquemas o tablas) de un fichero de expdp full sin problemas y recordar que los permisos de sistema (otorgados desde SYS) y las tablas de sistema (propiedad de SYS, SYSTEM) no se incluyen en los exports.

  2. agosto 31, 2012 en 17:35

    Hola que tal, yo soy nuevo en esto del mundo de los DBA\’s, recientemente tenia que importar mis esquemas de desarrollo a produccion para realizar prueba. La parte del expdp creo que ya la tengo algo clara pero estoy confundido con la parte del import, te explico mi problema haber si me pueden ayudar:

    En mi servidor de desarrollo tengo dos esquemas wmsdes y emsdes necesito exportar estos dos esquemas.

    En otro servidor tengo tambien dos esquemas wmsprd y emsprd, como se hace para cargar mi esquema de wmsdes en wmsprd y emsdes en emsprd?

    Ademas, los archivos que genere con el expdp los tengo que trasportar en disco al otro servidor y crear también en el otro servidor un directorio virtual? Ese proceso me confunde.

    Saludos y espero me puedan ayudar

    • Rafael Planella
      septiembre 2, 2012 en 11:25

      Hola Manuel,

      En respuesta a tus dudas:

      En la parte del expdp puedes exportar toda la BBDD o solo los esquemas que deseas llevarte ( wmsdes, emsdes ) esto lo puedes hacer mediante el parametro de linea de comandos SCHEMAS, por ejemplo:

      expdp miusuario/mipassword@orcl schemas=wmsdes,emsdes directory=midirectorio dumpfile=esquemas.dmp logfile=exp_esquemas.log

      En cuanto al import tienes que crear el directorio en la BBDD remota y trasladar el fichero de DMP generado durante el import tal como comentas, en cuanto a pasar los datos de wmsdes, emsdes a wmsprd, emsprd lo puedes haces mediante el comando REMAP_SCHEMA del impdp, por ejemplo:

      impdp miusuario/mipassword@orcl remap_schema=wmsdes:wmsprd,emsdes:emsprd directory=midirectorio dumpfile=esquemas.dmp logfile=imp_esquemas.log

      Finalmente un par de comentarios:

      En destino no es necesario que existan los usuarios emsprd y wmsprd, el impdp los creará en tu nombre siempre que el usuario usado para el impdp tenga permisos para ello (por ejemplo podria usar system para el usuario de conexión)

      Existe la posibilidad de importar sin pasar por fichero, directamente de una BBDD a otra mediante un dblink, no obstante te recomendaría familiarizarte un poco mas con Oracle, el expdp/impdp y los dblinks antes de usar ese sistema.

      Saludos,

      Rafael.

      • septiembre 3, 2012 en 15:15

        Muchas Gracias Rafael por tu respuesta, en verdad a sido de muchas ayuda, y si probare lo que tu me comentas en mi propia base de datos antes de hacerlo en la del trabajo.

        saludos,
        Manuel.

  3. septiembre 3, 2012 en 15:18

    Muchas gracias Rafael por tu respuesta, en verdad a sido de mucha ayuda para comprender un poco mas de este tema. Probaré lo que me comentas en otra base de datos para hacer pruebas y familiarizarme más como me comentas.

    Saludos,
    Manuel.

  4. Carlos Roberto
    octubre 3, 2012 en 23:22

    Primero excelente articulo Rafael muy claro y didáctico, tres interrogantes:
    Yo utilizo imp y exp presisamente por la cantidad de esquemas que exporto, tengo el script echo en un archivo que recibe como parametro el nombre de cada esquema a generar, en otro archivo tengo el listado de los esquemas con la invocación al script que hace el export, habría una opción pra hacerlo más simple con data dump y generar con un solo script todos mis esquemas indidualmente.
    La otra es con que parametro se comprime al vuelo.
    Una última al hacer el impdp sobre el mismo esquema se puede hacer que elimine primero los objetos ó los sobreescriba, actualmente con el imp primero vacío el esquema antes de importarlo.

    Salu2.
    Carlos Roberto.

    • Rafael Planella
      octubre 4, 2012 en 09:48

      Hola Carlos

      Para exportar múltiples esquemas en mutiles ficheros tendrás que usar el mismo sistema que actualmente, realizar múltiples llamadas a expdp, sea desde sistema operativo por línea de comandos sea mediante PL/SQL desde dentro de la BBDD.

      Si quieres tener todos los esquemas en un mismo fichero entonces con una sola llamada pasando la lista de esquemas es suficiente.

      SCHEMAS=esquema1,esquema2, esquema3

      Si esta lista de esquemas fuera muy larga puedes guardarla en un fichero y referenciar este fichero en la linea de comandos mediante el parámetro:

      PARFILE=

      Con este sistema puedes pasar algunos parámetros por línea de comandos y otros ponerlos en el fichero (un parámetro por línea).

      Para el tema de la compresión es el parámetro COMPRESSION que puede tener los valores

      ALL, DATA_ONLY, METADATA_ONLY, NONE

      Ojo que en versiones anteriores a la 11g solo se podía comprimir los metadatos no los datos y lo más importante diría que esta funcionalidad requiere tener BBDD Enterprise Edition y licenciada la opción de “Advanced Compression”.

      Finalmente existe otro parámetro que indica si al importar se “sobrescriben” los datos o no:

      TABLE_EXISTS_ACTION

      Los valores son: APPEND, REPLACE, SKIP y TRUNCATE.

      Saludos,

  5. Carlos Roberto
    octubre 5, 2012 en 21:43

    estoy probando las opciones y al hacer el compression=all, obtengo el siguiente error LRM-00121: ‘all;’ is not an allowable value for ‘compression’
    Si estoy trabajando con una 11g EE, que podría estar sucediendo, se debe activar algo adicional.
    Gracias Rafael

    • Rafael Planella
      octubre 7, 2012 en 15:29

      Hola,

      Si realmente la BBDD es 11.x lo único que se me ocurre es que tengas el parámetro “compatible” de la BBDD a un valor inferior a “11.0.0”.

      Este parámetro obliga a la BBDD a ignorar las funcionalidades de versiones superiores a la indicada y te permite realizar un “downgrade” si fuera necesario. En este caso estaría evitando que usaras la funcionalidad de comprimir datos (que aparece a partir de versión 11).

      En ocasiones se acostumbra a dejar el parámetro en el valor de la versión de BBDD anterior durante los upgrades (si pasas de 10.2 a 11.2 lo dejas en 10.2 durante unos días) para tener posibilidad de volver a 10.2 en caso de problemas graves. Si lo modificas ya no es posible volver atrás (puedes subirlo pero no bajarlo).

      Saludos,

      Rafael

  6. Sandra L
    enero 30, 2013 en 06:30

    Hola Rafael,

    me parece excelente tu artículo pero tengo un problema con el expdb, cuando trato de hacer el export se queda pasmado en la parte de export_schema/sequence/sequence y no envia ningun mensaje de error. En el log tampoco pone error simplemente se queda pasmado. Hay algun lugar donde pueda encontrar el error o alguna causa del porque se queda pasmado.

    Saludos

    • Rafael Planella
      enero 31, 2013 en 07:56

      Hola Sandra,

      Sin más datos es difícil intentar saber que está pasando, si me pasara a mí en primer lugar revisaría el fichero de trazas de oracle por si aparece algún tipo de error y en segundo intentaría ver que están haciendo los procesos de Data Pump una vez llegan al punto problemático.

      Esta segunda tarea se podría realizar conectando al la BBDD con SYS o SYSTEM y ejecutando esta select (al mismo tiempo que el datapump parece colgado).

      SELECT PROGRAM, MODULE, EVENT FROM V$SESSION WHERE MODULE LIKE ‘Data Pump%’;

      Saludos,

      Rafael

  7. david
    febrero 28, 2013 en 13:02

    Hola Rafael, Buenos Dias.
    Excelente artículo.

    Tengo una duda, he exportado desde desarrollo tres esquemas y los he cargado en un servidor local. Básicamente lo he hecho de la siguiente manera:
    expdp / schemas=esq1,esq2, esq3 directory=DATA_PUMP_DIR EXCLUDE=STATISTICS dumpfile=fichero.dmp logfile=ficherolog.log

    También he realizado la importación y se ha hecho correctamente, excepto por que para las tablas del esq1, no se me han cargado las claves primarias.

    He de aclarar que en desarrollo al crear una tabla, las claves primarias, se crean en tablespace (esqindex) diferente al de la tabla .
    ¿Debo incluir dicho esquema en el comando de exportación?.
    Al Hacer la exp del esq1, ¿Por que no se incluyeron las claves primarias?.

    Muchas Gracias de antemano.

    • Rafael Planella
      febrero 28, 2013 en 15:41

      Hola David,

      Sería interesante disponer del log del impdp, en el deberán aparecer los errores que nos ayudarían a aclarar que ha pasado.

      De todas maneras supongo que una posible razón por la que estas PK’s no se hayan creado es que los índices en que se basan se ubican en un tablespace que no existe en la BBDD destino.

      Si es este el caso tienes dos opciones, puedes crear ese tablespace en la BBDD destino o bien realizar un mapeo de tablespaces añadiendo el parámetro REMAP_TABLESAPACE al comando de impdp

      Ej:

      REMAP_TABLESPACE=source_tablespace:target_tablespace

      Notar que al remapear estas reubicando todos los objetos del export que se encuentren en el tablespace origen al destino, no solo los índices de PK’s

      Saludos,

      Rafael.

      • david
        marzo 1, 2013 en 11:53

        Gracias por responder, Rafael.

        Voy a comprobar lo del tablespace de los indices en la BD destino. Pero creo que ya existía, sin embargo de no se así lo creo y en la siguiente prueba, verifico si me carga las PK.

        Gracias por tu ayuda.

  8. Marlon
    abril 19, 2013 en 15:38

    Hola Rafael, muy bueno el artículo. Quisiera que por favor me ayudes con una duda. Tengo el export listo de mi base oracle 10g .dmp que se encontraba en windows server 2003 y voy a cambiarla a un nuevo servidor 2008R2 y oracle 11g. Pero no tengo muy clara la parte del import. Al momento de crear la nueva base en el servidor, debo crear todos los usuarios de mi base con las mismas claves primero? o hay alguna forma de realizar el import completo para obtener todos los usuarios y tablas sin inconvenientes.

    Saludos,

    Marlon

    • Rafael Planella
      abril 19, 2013 en 18:54

      Hola Marlon,

      Lo primero sería recomendarte usar el expdp/impdp (si no lo haces ya) para realizar el traspaso de datos, en la 10g ya dispones de estas nuevas herramientas y son mucho mejores que el exp/imp tradicional.

      Y ya respondiendo a tu pregunta:

      Si realizas un import de tipo full (parámetro FULL=Y) los usuarios si no existen se crearan durante el import. Tendrán los mismos permisos que en origen exceptuando los de sistema (que no se traspasan). Por tanto, puedes crear los usuarios antes del import con todos los permisos o dejas que los cree el import y les das los permisos de sistema posteriormente. Se pueden ver los permisos de sistema asignados a cada usuario en la tabla dba_sys_privs de la BBDD origen.

      En un import FULL, por defecto también se intentaran crear los tablespaces (los de datos, no los de sistema), si quieres los datafiles en diferentes ubicaciones físicas que las que tienen en el origen créalos antes de lanzar el import.

      Si quieres realizar algun tipo de mapeo (de un tablespace A en origen a un B en destino, de un usuario ABC a uno XYZ) puedes hacerlo pasando los mapeos como parámetros en el comando de import, en este caso es casi imprescindible usar expdp/impdp si te quieres ahorrar problemas.

      Saludos,

      Rafael.

  9. Mati
    abril 30, 2013 en 16:09

    Buenas, pregunta, se puede hacer un EXPDP desde oracle 10g y luego un IMP a oracle 9i?? Muchas gracias, estoy tratando pero me tira error..

    • Rafael Planella
      abril 30, 2013 en 16:42

      Hola Matías,

      El expdp y el imp exportan los datos en formatos diferentes y no son compatibles.

      Para pasar datos de una 10g a una 9i tendrías que exportar los datos conectando a la 10g con el comando exp de los binarios de la 9i (esto es importante, no funcionaría con el exp de los binarios de 10g) y importar con el imp también de la 9i.

      Saludos,

      Rafael

      • Matias
        mayo 2, 2013 en 17:14

        Antes que nada muchas gracias por tu respuesta Rafael. Entonces deberia instalar el cliente 9i en la maquina donde voy a hacer el export?? Existe algun portable o programa de tercero que lo simule? Ya que es una notebook de otra empresa y tienen instalado y configurado el 10g y es probable que no me permitan instalar otro cliente para no generar conflicto…
        Saludos.
        Matias

      • Matias
        mayo 2, 2013 en 17:32

        Otra alternativa podria ser migrar desde la base 10g externa a nuestra empresa, hacia una 11g que tenemos, y crear un dblink entre esta ultima y la 9i para pasar los datos.. y asi si hacerlo con expdp e impdp… pero tendriamos doble procesamiento… no se, no tengo demasiada experiencia en el tema como para saber cual es la mejor opcion.. que me recomendarias?
        Te cuento que son unas 20 tablas, de las cuales una contiene un campo con imagenes BLOB.. y de aca a una o dos semanas se estarian importando nuevos registros todos los dias, por un periodo de 2 meses al menos (por lo que tambien necesitariamos hacer un export selectivo, solo de los registros que no hayan sido exportados)…
        Espero haber sido claro.
        Gracias Rafael!
        Saludos
        Matias

      • Rafael Planella
        mayo 3, 2013 en 07:55

        Hola de nuevo Matias,

        Te recomendaría realizar el export desde la propia maquina “destino”, a diferencia del expdp el exp permite exportar los datos desde maquinas remotas. De manera que puedes conectar desde la maquina en la que tienes la BBDD 9i y realizar el export directamente desde esa.

        Si no es posible conectar ambas maquinas (no tienen visibilidad entre ellas) tendrías que instalar el cliente completo de 9i (o el software de servidor) en una tercera máquina, no hace falta que sea la origen (de hecho como comentas evitaria modificar la origen), con cualquieras de estas instalaciones ya dispondrás de los comandos exp/imp. Exportas los datos en esta tercera máquina y posteriormente desplazas el dmp a la máquina de BBDD 9i y cargas los datos (o importas directamente desde esta tercera maquina).

        Cuando lanzas el exp o el imp puedes conectar a BBDD en máquinas remotas usando el connect string correspondiente (el mismo que usarías en un sql*plus o en otras herramientas cliente), por ejemplo:

        exp userid=miusuario/mipassword@cadena_conexion_BBDD_remota file=fichero_dump.dmp log=fichero_log.log tables=tabla1,tabla2,tabla3

        Lo mismo para el import.

        Otro tema es como traspasar los datos “incrementales”, esto como ya he comentado en otra entrada es complicado, ya que tendrás que filtrar las filas a importar y tendrás que importar en el orden correcto para que no haya problemas de reglas de integridad. Solo a corte de ejemplo el comando exp tiene un parámetro QUERY que permite exportar solo las filas de las tablas que cumplan la condición (el valor del parámetro es la parte del WHERE de una select)

        Por ejemplo:

        exp userid=miusuario/mipassword@cadena_conexion_BBDD_remota file=fichero_dump.dmp log=fichero_log.log tables=tabla1,tabla2,tabla3 query="""where fecha_mod > '01/05/13'"""

        Saludos,

        Rafael

      • Mati
        mayo 3, 2013 en 15:34

        Muchisimas gracias rafael!!
        Voy a hablar con la gente de la empresa para tratar de implementar el esquema que me estas proponiendo… espero tener suerte.
        Saludos!

      • Mati
        mayo 21, 2013 en 13:11

        Hola Rafael como va?
        Antes que nada te cuento que, para evitar los problemas de importacion/exportacion, decidimos instalar en una maquina 2 placas de red, conectando cada una a una red diferente. Luego lo que planeamos hacer es crear un servidor de oracle local en esa pc, junto con un dblink para cada conexion, pasando asi los datos del servidor externo a la maquina local, y luego de esta al servidor propio. No encontramos una forma de hacer un “puente” o algo parecido para transferir la información de una base a otra directamente (ya que no se “ven” ambas redes)… si conoces algun truco para lograr esto te agradeceria que me lo comuniques ya que nos ahorrariamos una etapa del proceso, muchas gracias!

      • Rafael Planella
        mayo 23, 2013 en 06:02

        Hola Matías,

        No sé qué sistema operativo usáis en la maquina puente, pero una opción válida seria usar la maquina como enrutador (me consta que es posible hacerlo vía software tanto con Linux como con Windows Server) de esta manera tendréis visibilidad entre ambas BBDD.

        Otra opción es crear un DBLink de la BBDD “origen” a la BBDD en la maquina “puente” y en la BBDD de la maquina puente otro DBLink a la BBDD en la maquina “destino”. En la maquina “puente” creamos sinónimos que apunten a los objetos de “destino” con el DBLink ya creado. Desde la BBDD “origen” podremos llamar vía DBLink a los sinónimos en la BBDD “puente”, que realmente accederán a las tablas de la BBDD “destino”. Esta solución se me antoja más complicada y con más posibilidades de error.

        Saludos,

    • Mati
      mayo 23, 2013 en 12:44

      Perfecto gracias Rafael! Vamos a probar todas las variantes.. un saludo y gracias nuevamente!

  10. Adrian
    abril 30, 2013 en 18:55

    Excelente Articulo, Felicidades Rafael.

    Es cierto lo que comentas con respecto a este utilitario de respaldo y recuperación de tu base de datos de que muchos no lo conocen o utilizan incluyéndome. La verdad es que sigo utilizando el tradicional exp/imp. Quisiera empezar a utilizar el expdp/impdp en adelante. Actualmente tengo instalada la ver 10gR2 y acabo de instalar la misma versión en otro servidor para llevar un respaldo o hacer pruebas. Podrías aclararme estos puntos:
    1. El parámetro TABLE_EXISTS_ACTION como se utiliza si quisiera solamente mantener actualizada esta copia con registros nuevos de mi base de datos original. Por que mi primera intensión es hacer un impdp full, pero después quisiera mantenerla actualizada.
    2. Debo solo pasar el archivo .DMP al directorio virtual del otro servidor y simplemente ejecutar el impdp.
    3. La línea de comando del expdp/impdp pueden ir en un script y ser programadas para que la misma base de datos las ejecute en una tarea programada.

    Gracias, Agradeciendo por anticipado tus excelentes y valiosos comentarios.

    • Rafael Planella
      mayo 2, 2013 en 15:10

      Hola Adriano,

      Gracias por los comentarios.

      En respuesta a lo que comentas no es para nada simple pasar solo “cambios” mediante expdp/impdp.

      El parámetro que comentas TABLE_EXISTS_ACTION te permite decidir “que pasa” si impdp se encuentra con que la tabla ya existe en el esquema destino, las opciones son:

      SKIP: Se la salta y continua, dejando la tabla original intacta. Esta opción no te interesa ya que quieres “actualizar” la tabla.

      APPEND: Añade las filas a la tabla existente. Este parecería un buen sistema a primera vista pero adolece de varios problemas graves, el primero es que intentara cargar todas las filas que vienen en el fichero dmp, tanto las que ya tiene la tabla como las nuevas. Esto puede provocar errores de clave única o duplicar filas. Otro problema es que si tienes reglas de integridad referencial es muy posible que falle la inserción de las filas ya que las tablas no se cargaran en el orden correcto.

      TRUNCATE: En este caso se realiza un truncado de la tabla y se cargan nuevamente todas las filas. Esta parece, a priori, una de las mejores opciones pero tampoco está exenta de problemas, si la tabla tiene restricciones referenciales de integridad no será posible realizar el truncado y el impdp fallará.

      REPLACE: En este caso se realiza un “drop” de la tabla y se crea y cargan las filas nuevamente. Esto puede causar problemas, una vez más, si tenemos restricciones de integridad o permisos asignados a esta tabla ya que los perderíamos.

      Se tendría que revisar en detalle que tablas se tienen que sincronizar y sus relaciones, dependiendo del volumen y numero quizás sería más simple recargar todos los datos cada vez.

      En caso que esa opción no sea viable te plantearía usar algún otro sistema de sincronización (Oracle tiene el producto GoldenGate que realiza ese tipo de tareas).

      Y de manera rápida para las preguntas 2 y 3:

      Efectivamente tienes que pasar el fichero al directorio virtual del servidor remoto para realizar el impdp. Solo comentar que (con algunas restricciones de tipos de datos) también es posible realizar el impdp sin fichero dmp a través de un dblink que conecta destino a origen.

      El expdp lo puedes lanzar mediante línea de comandos y por tanto se puede programar (mediante crontab y un Shell script o programador de tareas y fichero cmd) o lanzarlo mediante el paquete PL/SQL DBMS_DATAPUMP desde la BBDD de modo que también se puede programar como job/schedule sin que tenga que llamar a ningún script de sistema operativo.

      Saludos,

      Rafael.

  11. Adrian
    mayo 2, 2013 en 21:20

    Muchas Gracias, Rafael.
    La verdad es que me ha quedado claro la utilización de este parámetro y sus diferentes alternativas. Agradezco igual tus consejos y sugerencias en todo lo demás.
    Suerte a todos, espero que sepan aprovechar al máximo y adecuadamente la herramienta.

  12. Thanny Lopez
    julio 7, 2013 en 11:31

    Rafael,
    Gracias por la information. En mi casi necesito recargar todos los datos de un schema. Que opción tengo que usar en el caso que las tablas existan?
    Gracias

    • Rafael Planella
      julio 8, 2013 en 07:43

      Hola Thanny,

      En caso que las tablas existan tendrías que usar la opción

      TABLE_EXISTS_ACTION

      Que corresponde a la acción que se debe realizar si el objeto ya existe. Las posibles opciones son: APPEND, REPLACE, SKIP y TRUNCATE (por defecto es SKIP).

      Personalmente intentaría usar la opción TRUNCATE habiendo desactivado previamente las constraints en las tablas (descarto la opción REPLACE ya que recrea las tablas y elimina las constrains que hacen referencia a ellas).

      Saludos,

  13. Alexander
    agosto 7, 2013 en 15:12

    Gracias Rafael por compartir tus conocimientos al grupo, también me han servido como instructivo sobre el tema. Que Dios te multiplique.

  14. Valeska
    octubre 15, 2013 en 03:23

    Hola Rafael, te contare que me enrredo un poco con los expdp e impdp. Resulta que tengo un respaldo hecho en el servidor con expdp de un X esquema y necesito importarlo en el mismo servidor pero a otro esquema. Cada esquema tiene su propio tablespace. En otras ocaciones cuando he importado los datos, estos quedan apuntando al tablespace origen pero yo quiero que apunten al tablespace destino, como debo colocar en el scrip para que la nueva importacion mencione al tablespace destino?.

    Espero me puedas ayudar y muchisimas gracias.

    Valeska.

    • Rafael Planella
      octubre 15, 2013 en 08:30

      Hola Valeska,

      Del mismo modo que para mapear de un esquema a otro usas el parámetro REMAP_SCHEMA, para los tablespaces puedes usar el REMAP_TABLESPACE (un parámetro por tablespace a mapear), por ejemplo:

      impdp test/test@orcl directory=IMPDP_DIR logfile=impdp.log remap_schema=USER:NEW_USER REMAP_TABLESPACE=DATA:NEW_DATA remap_tablespace=INDEX:NEW_INDEX REMAP_TABLESPACE=HIST:NEW_HIST

      En este caso pasamos los objetos que originalmente eran de “USER” al esquema “NEW_USER” y reubicamos los objetos que estaban en el tablespace DATA a NEW_DATA, INDEX a NEW_INDEX y HIST a NEW_HIST

      Saludos

      Rafael

  15. Liz Flores
    marzo 25, 2014 en 16:35

    Hola buenas tardes
    Llevo algo de tiempo usando el expdp e impdp y fue debido a que en una ocasion que saque un exp de una bd de 10g me percate que no exporto todos los objetos. De ahi en adelante empece a utilizar el expdp. Pero no he podido encontrar documentacion que me diga a que se debe esto. Ya lo he porbado varias veces y sigue el detalle: saco un exp y no trae todo los obejtos, sobre todo me ha pasado con los types. Saco un expdp y todo perfecto.
    Me podrias orientar por que pasa esto o donde puedo encontrar documentacion que me oriente?
    Muchas gracias.
    Saludos y bonito dia.

    • Rafael Planella
      marzo 25, 2014 en 18:12

      Hola Liz,

      El exp/imp han pasado a estar “deprecated” desde la versión 10g, esto implica que Oracle ha dejado de actualizar estas herramientas.

      Cualquier tipo de objeto de BBDD aparecido o actualizado a partir de la versión 10g es susceptible de no ser tratado correctamente (o ser ignorado como es tu caso) si lo intentamos exportar o importar con exp/imp.

      La solución pasa por usar las nuevas versiones de estas herramientas, expdp/impdp tal y como has hecho.

      Un saludo.

      Rafael

  16. Jorge
    marzo 27, 2014 en 23:28

    Hola Rafael, existe la posibilidad de Importar un backup de forma mas rápida sin que tenga que generar indices que es donde toma mas tiempo, solo importar data pero el detalle seria los constraint que tendria que desactivarlos y eso como seria?. Agradezco tu rspta de antemano.

    • Rafael Planella
      abril 15, 2014 en 21:44

      Hola,

      Es posible, usando impdp ignorar ciertos tipos de objetos, como índices o constraints. El parámetro parar evitar que se creen los índices es es EXCLUDE=INDEX si además quieres evitar que se importen constraints EXCLUDE=INDEX,CONSTRAINT,REF_CONSTRAINT

      Finalmente existen algunos índices que no vas a poder evitar, los relacionados con constrains NOT NULL por ejemplo o los de tablas de tipo IOT.

      Saludos,

      Rafael

  17. francisco
    noviembre 20, 2014 en 04:47

    tengo una bd en 11g trabajando en un IBM(AIX),tengo alrededor de un año que empece a utilizar la herramienta rman y vivi engañado todo este año dado que todos los dias se hacia el respaldo via rman(0 y 1), en estos dias quise migrar la bd a otro servidor que se acaba de adquir(ODA EN PLATAFORMA LINUX)y sorpresa que rman no funciona con plataformas diferentes, trate de utilizar la opcion de expdp pero tarda muchismo, en mi trabajo no puedo detener la produccion por mucho tiempo, pedi una venta de tiempo de 20 hras y no fue suficiente….recuerdo que utileria exp si dejaba sacar respaldos incrementales , pero la expdp no lo permite……alguna idea ??se los agradeceria….saludos

    • Rafael Planella
      noviembre 20, 2014 en 14:54

      Hola Francisco,

      RMAN te permite realizar backups de BBDD Oracle, por lo que si los backups eran correctos te han estado dando “respaldo a cinta/disco” de tu BBDD sobre AIX todo este tiempo, no ha sido trabajo en balde.

      En un principio los backpus de RMAN se tienen que recuperar en la misma plataforma en que se han hecho (son copias binarias de los ficheros), no obstante es posible un cierto margen.

      Si las dos plataformas (origen y destino) tienen el mismo “endianess” es posible trasladar la BBDD de una a otra usando la técnica del “Transportable Database” con RMAN, si no tienen el mismo “endianess” se tiene que hacer con la técnica de “Transportable Tablespace” ya que requiere tratar los ficheros para convertirlos previamente. Ambos sistemas son mas largos y laboriosos que una recuperación “típica” y tienen que ser probados antes de realizar la migración productiva (existen múltiples condicionantes/bugs/comprobaciones a revisar antes de dar por valido para una migración este tipo de procedimientos).

      En la vista V$TRANSPORTABLE_PLATFORM tenemos el endianess de las diferentes plataformas:

      SQL> select * from v$transportable_platform;

      PLATFORM_ID PLATFORM_NAME ENDIAN_FORMAT
      ———– —————————————————————————————————– ————–
      1 Solaris[tm] OE (32-bit) Big
      2 Solaris[tm] OE (64-bit) Big
      7 Microsoft Windows IA (32-bit) Little
      10 Linux IA (32-bit) Little
      6 AIX-Based Systems (64-bit) Big
      3 HP-UX (64-bit) Big
      5 HP Tru64 UNIX Little
      4 HP-UX IA (64-bit) Big
      11 Linux IA (64-bit) Little
      15 HP Open VMS Little
      8 Microsoft Windows IA (64-bit) Little
      9 IBM zSeries Based Linux Big
      13 Linux x86 64-bit Little
      16 Apple Mac OS Big
      12 Microsoft Windows x86 64-bit Little
      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.

      En tu caso el origen es un AIX y el destino Linux, de manera que cambias de endianess, lo que limita las opciones a Transportable Tablespaces si queremos usar RMAN.

      Por otra parte ni el exp ni el expdp permiten copias incrementales, lo que si permiten son copias “consistentes”, esto es, que se exporta una imagen estática (una foto como quien dice) de la BBDD aunque hayan operaciones en marcha durante el export.

      Si el traslado de la BBDD con RMAN mediante las citadas técnicas es demasiado costoso o complejo se podrían evaluar otras opciones (siempre que sean factibles):

      Trasladar primero las tablas de histórico mediante expdp y posteriormente solo las de online (durante el traslado de estas ultimas se haría la parada).
      Realizar el traslado mediante impdp con dblink (sin pasar por disco) si existe una buena comunicación entre ambas maquinas.
      Usar paralelismo tanto para el expdp como para el impdp (o para el impdp via dblink si es la opción escogida).
      Replicar las BBDD mediante GoldenGate (este permitiría un tiempo de parada prácticamente cero pero requiere mas preparación y adquisición de licencias).
      Inserts as select vía dblink en paralelo por partición para las tablas extremadamente grandes.

      O una combinación de las anteriores.

      Finalmente, te paso algunas notas que hacen referencia al procedimiento de RMAN entre diferentes plataformas:

      RMAN DUPLICATE/RESTORE/RECOVER Mixed Platform Support (Doc ID 1079563.1)
      Cross-Platform Database Migration (across same endian) using RMAN Transportable Database (Doc ID 1401921.1)
      How to Migrate to different Endian Platform Using Transportable Tablespaces With RMAN (Doc ID 371556.1)

      Saludos,

      Rafael

  18. francisco
    noviembre 20, 2014 en 16:40

    muchisimas gracias Rafael, ya estoy viendo una pequeña luz…..saludos.

  19. giovanni
    enero 16, 2015 en 20:47

    quiero exportar con expd en oracle 10g pero no me deja ayuda porfavor ya que luego lo quiero pasar a oracle 11g

    • Rafael Planella
      enero 18, 2015 en 23:29

      Hola Giovanni,

      Nos podrías indicar que comando usas para la exportación y cual es el error que aparece? Por otro lado comentar que el fichero expdp generado en una 10g es totalmente compatible con el impdp de 11g (no se tiene que realizar ninguna configuración especial al respecto).

      Saludos,

      Rafael

      • giovanni
        enero 19, 2015 en 15:16

        Hola rafael en todo caso me podrias explicar como hacer la exportacion con expdp desde cero paso paso, con todo lo que se tiene que tener y crear para realizar la exportacion porfavor

      • Rafael Planella
        enero 21, 2015 en 16:56

        Básicamente los pasos para usar expdp serían los siguientes:

        Creamos en la BBDD origen un objeto de tipo directorio, esto es asignar un nombre virtual (un alias) a un directorio real de la máquina. Notar que el directorio real que usemos tiene que están en el mismo servidor que la BBDD.

        Por ejemplo conecto con sqlplus y lanzo estos comandos:

        SQLPLUS /NOLOG
        CONN / AS SYSDBA

        CREATE OR REPLACE DIRECTORY dir_salida AS ‘c:\directorio_export\';
        GRANT READ, WRITE ON DIRECTORY dir_salida TO SYSTEM;

        Acto seguido ya podemos exportar la BBDD entera con el siguiente comando, nos debería dejar el fichero exp_full.dmp con los datos en el directorio de trabajo creado anteriormente.

        expdp system/system_password@miconnectstring full=Y directory=DIR_SALIDA dumpfile=exp_full.dmp logfile=exp_full.log flashback_time=systimestamp

        Nota: El ultimo parámetro (flashback_time) podemos no usarlo si tenemos la certeza de que nadie trabaja en la BBDD durante el export.

  20. William Henao
    mayo 21, 2015 en 14:47

    Hola Rafael, gracias por este foro la explicación esta muy bien pero, quisiera me ayudaras con algo ya que no soy muy experto en manejo de base de datos. Donde trabajo manejamos un sistema llamado JD Edwards y este esta configurado por ambiente, tenemos dos bases de datos la de pruebas y la de producción. Quiero replicar la informacion de produccion a pruebas por medio de un import, impdp sys/xxxxx@xxxx REMAP_SCHEMA=PRODDTA:CRPDTA directory=EXPORT_DIR dumpfile=JDE_DIA_20150203.dmp logfile=JDE_DIA_20150203.log. pero me genera errores al creacion de las tablas y no me ha funcionado.

    Quedo atento

    • Rafael Planella
      mayo 22, 2015 en 07:30

      Hola William

      Faltaría ver el error que aparece al intentar crear las tablas, que nos indicaria la causa concreta del problema, pero inicialmente podrías revisar los siguiente:

      Existen los tablespaces en que se tienen que crear las tablas en la BBDD de pruebas? En caso de existir los tablespaces, el usuario CRPDTA tiene permisos para crear objetos en ellos? Disponen de suficiente espacio libre?
      El esquema destino (CRPDTA) ya dispone de las tablas y quieres “refrescar” su contenido? Por defecto impdp no sobrescribe tablas ni los datos, puedes indicarle que si lo haga con el parámetro TABLE_EXISTS_ACTION = {SKIP | APPEND | TRUNCATE | REPLACE}, o eliminar las tablas del esquema previamente al import.

      Saludos,

      Rafael

      • William Henao
        mayo 22, 2015 en 13:18

        Hola Rafael, gracias por tu respuesta. El usuario CRPDTA tiene permisos para todo; este esquema ya tiene las tablas creadas y con información, generalmente el error que muestra es que no se puede crear la tabla y salta ese paso. Lo intente realizarlo con tablex_exists_action=replace pero no me reemplaza las tablas.

      • Rafael Planella
        mayo 22, 2015 en 21:06

        Hola William

        Sin ver los errores que aparecen es difícil imaginar que puede estar pasando, si nos adjuntas alguno de los erorres de carga de las tablas podriamos intentar deducir cual es el problema.

        El parámetro que usas en el import “TABLE_EXISTS_ACTION=REPLACE” elimina y crea nuevamente las tablas (siempre y cuando el fichero de export contenga los metadatos), esto es así incluso si la tabla tiene FK’s o es referenciada por FK’s.

        Saludos,

        Rafael

      • William Henao
        mayo 23, 2015 en 18:12

        Buenos dias Rafael, hice nuevament el proceso, primero borre todas las tablas y realicé el import y no me arrojó error. Pero cuando intento ingresar a la plataforma sale lo siguiente:

        Sign In Error: An unknown JAS sign in error occurred. Please contact the System Administrator.

        El import es asi: impdp system/**********@JDECRP REMAP_SCHEMA=PRODDTA:CRPDTA remap_tablespace=PRODDTAT:CRPDTAT,PRODDTAI:CRPDTAI directory=EXPORT_DIR dumpfile=JDE_DIARIO_20150523.dmp logfile=JDE_DIARIO_20150523.log

        El error que me salía cuando no borraba las tablas era que no podía crear.

        Failing sql is:
        CREATE TABLE “CRPDTA”.”F00021″ (“NLKCO” NCHAR(5), “NLDCT” NCHAR(2), “NLCTRY” NUMBER, “NLFY” NUMBER, “NLSMAS” NCHAR(2), “NLN001” NUMBER, “NLAUR” NUMBER, “NLIMB” NCHAR(1), “NLCK01” NCHAR(1), “NLSEQ” NUMBER) PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255 NOCOMPRESS LOGGING STORAGE(INITIAL 57344 NEXT 57344 MINEXTENTS 1 MAXEXTENTS 2147483645 PCTINCREA
        ORA-39083: Object type TABLE:”CRPDTA”.”F9000″ failed to create with error:

        Quedo atento,

        Muchas gracias

      • Rafael Planella
        mayo 29, 2015 en 07:32

        Hola William,

        En lo que se refiere al error del import si no borras las tablas tendríamos que ver que mensaje aparece justo después del que has incluido en tu respuesta, el ORA-39083 es un mensaje genérico que indica que algo no ha ido bien, el siguiente mensaje debería indica la causa del problema.

        Un saludo,

        Rafael

  21. Gustavo Gámez
    agosto 20, 2015 en 23:59

    Hola. Hay alguna forma de que el DIRECTORY no se encuentre en el mismo server de la BBDD?

    Saludos.

    • Rafael Planella
      agosto 24, 2015 en 08:12

      Hola Gustavo,

      Inicialmente la respuesta seria no, una de las novedades del expdp es que es un proceso “de servidor” (por lo que genera los ficheros en el propio servidor).

      No obstante si la unidad en la que realizas el dump es una unidad remota montada en el servidor (via NFS en Unix/Linux o share de Windows) el fichero quedará realmente ubicado en un servidor o NAS remoto.

      Notar que para usar expdp en una unidad montada remotamente requiere configuraciones especificas, en concreto que el NFS tenga unas opciones de montaje concretas para el caso del Unix/Linux o usar rutas UNC y un usuario de dominio con permisos para el servicio de la BBDD en Windows.

      Saludos,

      Rafael

      • Gustavo Gámez
        agosto 24, 2015 en 14:48

        Gracias Rafael. Mis situación es la siguiente: el server de Oracle es un Linux, y por motivos de espacio deseo hacer el dump en otro server, pero mis otros servers estan en Windows, asi que hice el intento montando el recurso compartifo de windows en el servidor de oracle como un file system CIFS, pero el expdp dio error. En otro blog me encontré que la BBDD no acepta CIFS. Conoces alguna otro manera de hacer el mount en Linux?
        Saludos

      • Rafael Planella
        agosto 24, 2015 en 15:09

        Hola,

        Lo que comentas es correcto, no esta soportado (ni funciona) un expdp desde Linux contra un recurso Windows remoto montado con CIFS. La única opción que podría funcionar con tu configuración actual seria habilitar los servicios NFS en el servidor Windows (los llamados Server for NFS) y intentar realizar el montaje del volumen con este protocolo en lugar de CIFS. No lo he probado nunca, pero si la implementación del protocolo NFS por parte de Windows es correcta debería funcionar.

        Un saludo,

        Rafael

      • Gustavo Gámez
        agosto 24, 2015 en 19:09

        Ok, voy a hacer el intento y te comento luego el resultado.
        Gracias.

      • Gustavo Gámez
        septiembre 1, 2015 en 21:26

        Finalmente te comento que si funciona al montar el recurso compartido de Windows con los servicios de NFS.

        Saludos.

      • Rafael Planella
        septiembre 2, 2015 en 09:02

        Me alegro que haya funcionado y gracias por hacérnoslo saber.

        Un saludo,

        Rafael

  1. septiembre 16, 2011 en 19:55
  2. enero 2, 2013 en 09:40
  3. enero 2, 2014 en 09:45

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: