Archivo de la etiqueta: impdp

Tabla noexp$ en oracle

Posted on por

Hoy vamos ha hacer una de esas entradas «para guardar», su merito es totalmente de un compañero de trabajo, que me ha contado esta mañana la existencia de esta tabla.
Oracle tiene una tabla llamada noexp$ donde puedes ubicar los objetos de los que no quieras que se hagan exports.

Esta tabla tiene 3 campos, el OWNER del objeto, el OWNER del objeto y el tipo de objeto que es.

SQL> desc NOEXP$
Name Null? Type
--------------------- -------- ------------
 OWNER                 NOT NULL VARCHAR2(30)
NAME                  NOT NULL VARCHAR2(30)
OBJ_TYPE              NOT NULL NUMBER

Si queremos exportar la tabla PASS del esquema FOTOS, ejecutaremos el comando :

[oracle@test] [$expdp system/***** tables=FOTOS.PASS file=nada.dmp directory=backup
Export: Release 11.2.0.2.0 - Production on Lun Abr 14 16:38:48 2014
Copyright (c) 1982, 2009, Oracle and/or its affiliates.  All rights reserved.
Connected to: Oracle Database 11g Express Edition Release 11.2.0.2.0 - 64bit Production
Legacy Mode Active due to the following parameters:
Legacy Mode Parameter: "file=nada.dmp" Location: Command Line, Replaced with: "dumpfile=nada.dmp"
Legacy Mode has set reuse_dumpfiles=true parameter.
Starting "SYSTEM"."SYS_EXPORT_TABLE_01":  system/******** tables=FOTOS.PASS dumpfile=nada.dmp directory=backup reuse_dumpfiles=true
Estimate in progress using BLOCKS method...
Processing object type TABLE_EXPORT/TABLE/TABLE_DATA
Total estimation using BLOCKS method: 1024 KB
Processing object type TABLE_EXPORT/TABLE/TABLE
Processing object type TABLE_EXPORT/TABLE/INDEX/INDEX
Processing object type TABLE_EXPORT/TABLE/CONSTRAINT/CONSTRAINT
Processing object type TABLE_EXPORT/TABLE/INDEX/STATISTICS/INDEX_STATISTICS
Processing object type TABLE_EXPORT/TABLE/CONSTRAINT/REF_CONSTRAINT
Processing object type TABLE_EXPORT/TABLE/STATISTICS/TABLE_STATISTICS
. . exported "FOTOS"."PASS"                              6.796 KB      27 rows
Master table "SYSTEM"."SYS_EXPORT_TABLE_01" successfully loaded/unloaded
******************************************************************************
Dump file set for SYSTEM.SYS_EXPORT_TABLE_01 is:
  /vgbackup/backup/oracle/nada.dmp
Job "SYSTEM"."SYS_EXPORT_TABLE_01" successfully completed at 21:39:07

Ha funcionado correctamente, pero , y si no queremos que se pueda exportar esta tabla?

Lo primero que tendremos que hacer es ver el tipo de objeto que es esa tabla. Para ello ejecutaremos la consulta 

SQL> select name,type# from obj$ where name = 'PASS';
NAME                                TYPE#
------------------------------ ----------
PASS                                    2

Una vez sabemos que es de tipo «2», la introduciremos en la tabla «noexp$» (como sys) 

insert into NOEXP$ values ('FOTOS','PASS','2');

Que ocurre si intentas hacer un export de esa tabla??

[oracle@test [$expdp system/**** tables=FOTOS.PASS file=nada.dmp directory=backup
Export: Release 11.2.0.2.0 - Production on Lun Abr 14 16:42:03 2014
Copyright (c) 1982, 2009, Oracle and/or its affiliates.  All rights reserved.
Connected to: Oracle Database 11g Express Edition Release 11.2.0.2.0 - 64bit Production
Legacy Mode Active due to the following parameters:
Legacy Mode Parameter: "file=nada.dmp" Location: Command Line, Replaced with: "dumpfile=nada.dmp"
Legacy Mode has set reuse_dumpfiles=true parameter.
Starting "SYSTEM"."SYS_EXPORT_TABLE_01":  system/******** tables=FOTOS.PASS dumpfile=nada.dmp directory=backup reuse_dumpfiles=true
Estimate in progress using BLOCKS method...
Processing object type TABLE_EXPORT/TABLE/TABLE_DATA
Total estimation using BLOCKS method: 0 KB
ORA-39166: Object FOTOS.PASS was not found.
ORA-31655: no data or metadata objects selected for job
Job "SYSTEM"."SYS_EXPORT_TABLE_01" completed with 2 error(s) at 16:42:07

Como vemos, el export (expdp) no encuentra la tabla, con lo que no puede llevar a cabo la exportación.
Hay que tener mucho cuidado ya que, lo que no está exportando es la tabla, no los contenidos, con lo que , en nuestro caso, un export full de la base de datos haría que la aplicación no funcionase ya que ,no existe la tabla de passwords ( ni la estructura ni los datos)

Más información, como siempre en metalink en la nota «OERR: EXP 55 %s.%s is marked not exportable (Doc ID 47991.1)»

ORA-00959: el tablespace ‘_$deleted$82$0’ no existe durante un impdp

Posted on por

Nos hemos mudado a bloger!
El contenido actualizado de esta entrada lo tienes en:

    http://dba.pamplona.name/2013/08/ora-00959-el-tablespace-no-existe.html

    Hoy vamos a ver como solucionar los problemas ORA-00959 cuando van asociados a un tablespace borrado.
    Este error es bastante común y es un bug identificado de oracle que es facil que te encuentres cuando se usan tablas particionadas, y se elimina o se mueve el tablespace original de la tabla. Es muy habitual el rehacer los objetos indicando los tablespaces por defecto de las particiones, pero no cambiando el de la tabla original
    Esto hace que, cuando vayas a importar la tabla, el tablespace original de la tabla no exsista, recibiendo el error del enunciado.

    ¿Como lo solucionamos?

    Hay 2 maneras:

    1- Solucion en origen
    Esta es la solución correcta, y lo que hacemos es buscar que tablas tienen la sintaxsis de creacion en un tablespace inexistente y modificarlas.

    select distinct 'ALTER INDEX '||index_owner||'.'||index_name||' MODIFY DEFAULT ATTRIBUTES TABLESPACE '||tablespace_name||';' cmd from dba_ind_partitions where tablespace_name not in ('SYSTEM','SYSAUX') order by 1;

 select distinct 'ALTER INDEX '||index_owner||'.'||index_name||' MODIFY DEFAULT ATTRIBUTES FOR PARTITION '||partition_name||' TABLESPACE '||tablespace_name||';' cmd from dba_ind_subpartitions where tablespace_name not in ('SYSTEM','SYSAUX') order by 1;

 select distinct 'ALTER TABLE '||table_owner||'.'||table_name||' MODIFY DEFAULT ATTRIBUTES TABLESPACE '||tablespace_name||';' cmd from dba_tab_partitions where tablespace_name not in ('SYSTEM','SYSAUX') order by 1;

 select distinct 'ALTER TABLE '||table_owner||'.'||table_name||' MODIFY DEFAULT ATTRIBUTES FOR PARTITION '||partition_name||' TABLESPACE '||tablespace_name||';' cmd from dba_tab_subpartitions where tablespace_name not in ('SYSTEM','SYSAUX') order by 1;

 select 'alter user '||username||' default tablespace '||default_tablespace||' temporary tablespace '||temporary_tablespace||';' cmd from dba_users order by default_tablespace;

    Y ejecutamos la salida de estas consultas

    2- Solucion en destino

    Creamos a mano las tablas que dan el error e importamos con la opcion «truncate»

    NOTA:
    Indpendientemente de estas chapucillas, lo mejor será contactar con soporte oracle para identificar el bug que nos afecta y parchear la base de datos

Exportar roles entre bases de datos

Posted on por

Hoy vamos a ver como transportar roles de bases de datos.

Los roles de bases de datos son una solución cómoda y rápida para la asignación de grupos de permisos entre usuarios, el principal problema de los mismos, es que los permisos que asignas a los roles no están en las especificaciones de los usuarios que los poseen, sino que están dentro del esquema SYS dela base de datos, lo que provoca que cuando intentas importar algún esquema de usuario que posee un rol falle si no está el rol previamente definido.

Otra de las incomodidades de los roles es que , no hay una consulta sencilla que puedas hacer a la base de datos que te muestre la sintaxsis SQL del rol, con lo que su uso se convierte en algo engorroso en operaciones de movimiento de datos entre entornos.

Así pues, si queremos trabajar con roles tendremos que tener algún tipo de mecanismo para obtener los comandos de creacion de los roles.
Para esto, oracle tiene el paquete dbms_metadata que con la llamada get_ddl es capaz de obtener el código SQL para un determinado objeto.

Ahora bien,¿como llamamos a este paquete?

Para cada uno de nuestros roles tendremos que obtener las DDL de :

  • creacion del rol
  • Grants del rol
  • Grants de system
  • Grants de objetos

Así pues, para obtener los datos del rol «MIROL» haríamos:

set linesize 200
set head off
set pages 0
set long 9999999
exec dbms_metadata.set_transform_param(dbms_metadata.session_transform, 'SQLTERMINATOR', true);
SELECT 'create role MIROL' from dual;
exec dbms_metadata.set_transform_param(dbms_metadata.session_transform, 'SQLTERMINATOR', true);
SELECT dbms_metadata.get_granted_ddl('ROLE_GRANT',  'MIROL') FROM dual;
exec dbms_metadata.set_transform_param(dbms_metadata.session_transform, 'SQLTERMINATOR', true);
SELECT dbms_metadata.get_granted_ddl('SYSTEM_GRANT','MIROL') FROM dual;
exec dbms_metadata.set_transform_param(dbms_metadata.session_transform, 'SQLTERMINATOR', true);
SELECT dbms_metadata.get_granted_ddl('OBJECT_GRANT','MIROL') FROM dual;

Hay que tener en cuenta que, la consulta de los SYSTEM_GRANT es muy pesada, especialmente en sistemas con un alto número de objetos.
Por otra parte,tampoco estamos hablando de una operacion que no hemos de hacer muy amenudo y que, probablemente podamos guardar de una vez a otra

Como limpiar datapump fallidos ORA-31633

Posted on por

Hoy vamos a ver como solucionar el problema de relanzar algunos datapumps fallidos cuando nos devuelven el error ORA-31633

Una de las principales diferencias entre el export tradicional y el nuevo expdp es que el expdp crea un job en la base de datos que es quien se encarga de la labor de sacar los datos.

Cuando detenemos esta exportación de manera no controlada, puede ser que la definición del trabajo creada por el export quede dentro de la base de datos, con lo que, al volver a lanzar el trabajo del export recibamos un error «ORA-31633: unable to create master table XXX»

ORA-31626: job does not exist
ORA-31633: unable to create master table "SYSTEM.EXPORT_DIAR"
ORA-06512: at "SYS.DBMS_SYS_ERROR", line 95
ORA-06512: at "SYS.KUPV$FT", line 863
ORA-01031: insufficient privileges

Para solucionar este problema, lo primero que tenemos que hacer es comprobar que trabajos no se encuentran en estado RUNNING 


SET lines 200
SELECT owner_name, job_name, operation, job_mode,
state, attached_sessions
FROM dba_datapump_jobs
ORDER BY 1,2;

Esta consulta nos devuelve la informacion de los trabajos de datapump que hay en la base de datos, el resultado es una tabla del tipo 

OWNER_NAME JOB_NAME            OPERATION JOB_MODE  STATE       ATTACHED
———- ——————- ——— ——— ———– ——–
SCOTT      EXPORT_TABLA_1 EXPORT    TABLE     NOT RUNNING        0
SYSTEM     EXPORT_DIARIA  EXPORT    FULL      NOT RUNNING        0

Aquí podemos ver como tenemos dos trabajos, uno del usuario SCOTT y otro de SYSTEM que están en estado NOT RUNNING, con lo que podemos eliminarlos.

Ahora buscaremos cual es la «master table» del job con la consulta

SELECT o.status, o.object_id, o.object_type,
       o.owner||’.'||object_name “OWNER.OBJECT”
  FROM dba_objects o, dba_datapump_jobs j
 WHERE o.owner=j.owner_name AND o.object_name=j.job_name
   AND j.job_name NOT LIKE ‘BIN$%’ ORDER BY 4,2;

STATUS   OBJECT_ID OBJECT_TYPE  OWNER.OBJECT
——- ———- ———— ————————-
VALID        15223 TABLE        SCOTT. EXPORT_TABLA_1
VALID        15293 TABLE        SYSTEM.EXPORT_DIARIA

Ahora podemos eliminar las tablas de los trabajos con la consulta.

SQL> DROP TABLE SCOTT. EXPORT_TABLA_1;
SQL> DROP TABLE SYSTEM.EXPORT_DIARIA;

Con esto habremos limpiado la tabla de los jobs del datapump, con lo que podremos volver a lanzar nuestro script sin problemas