IMPDP con tablas particionadas

Hoy vamos a una entrada muy sencilla y corta, pero que puede salvarnos de algún que otro desastre.

¿Es posible truncar/reemplazar una única particion en una tabla durante un proceso de IMPDP?

La respuesta es rápida y clara . No
La documentacion de oracle indica claramente:
If you attempt to use Data Pump parameter table_exists_action=truncate, or even the replace option
be aware that the complete table will be truncated, not just the partition being imported!

Más información en la nota a a Single Partition be Truncated during Data Pump Import? (Doc ID 877792.1)

Sintaxis del EXDP desde comando vs parfile

Volvemos a una entrada de ayuda para dummies.
Muchas veces perdemos un montón de tiempo haciendo prueba y error con las comillas en los scripts de expdp e impdp
En esta entrada cortita, vamos a poner el mismo script de import en parfile y linea de comandos

Parfile

$ORACLE_HOME/bin/expdp system/blabla parfile  fichero_opciones.par 

Donde el parfile es :

DIRECTORY=DATA_PUMP_DIR
DUMPFILE=fichero_expdp.dmp
LOGFILE=expdp.log
FULL=Y
EXCLUDE=TABLE:"IN ('NOMINAS', 'CHISTES' , 'GAZAPOS')"
EXCLUDE=SCHEMA:"IN ('BLOG','PORRA')"

Línea de comandos
En línea de comandos, simplemente escaparemos las comillas simples y dobles (especialmente si vamos a incluirlo en algún script)

$ORACLE_HOME/bin/expdp system/blabla DIRECTORY=DATA_PUMP_DIR DUMPFILE=fichero_expdp.dmp LOGFILE=expdp.log FULL=Y EXCLUDE=TABLE:\"IN (\'NOMINAS\', \'CHISTES\' , \'GAZAPOS\')\"  EXCLUDE=SCHEMA:\"IN (\'BLOG\',\'PORRA\')\"

El equivalente a CONSISTENT=Y con expdp

Hoy vamos a ver otra de esas entradas sumamente sencillas que nos ahorrarán un montón de tiempo.

Si intentamos hacer un exdp de una base de datos grande que hace un uso muy intensivo de secuencias, podemos encontrarnos problemas a la hora de la importación con las claves ajenas, esto es debido a que el export que hemos llevado a cabo no es consistente.

En la versión antigua del export (exp) teníamos una opción llamda CONSISTENT=Y que nos permitía congelar la base de datos en el momento del export de manera que, la exportacion de nuestra base de datos era totalmente consistente. Sin embargo, la nueva funcionalidad expdp no lo tiene ¿hemos dado un paso atrás?

Afortunadamente, la respuesta es no, lo único que pasa, es que (como siempre) Oracle nos ha puesto algo mas dificil acertar con el nombre.

Lo que haremos con el expdp será el hacer un expdp con la opción FLASHBACK_TIME ó FLASHBACK_SCN

La nueva sintaxsis será :

  • Para hacer un export en el momento 15-05-2014 a las 21:00
    expdp user/pass ... FLASHBACK_TIME="TO_TIMESTAMP('15-05-2014 21:00:00', 'DD-MM-YYYY HH24:MI:SS')" ...
    
  • Para hacer un export en el momento que lo lanzas
    expdp user/pass ... FLASHBACK_TIME=systimestamp  ...
    
  • O bien, para lanzar un export en un determinado SCN
    expdp user/pass ... FLASHBACK_SCN=7782903
    

Hay que tener en cuenta dos cosas cuando lanzamos un expdp con FLASHBACK

  • Las dos opciones TIME y SCN son excluyentes: No se pueden poner las dos claúsulas en el mismo script de export
  • Es necesario contar con un UNDO suficiente para albergar los datos durante todo el export: Lo que estamos haciendo con esto, es mantener la base de datos congelada en ese punto, si el export dura 7 horas, deberemos de contar con un UNDO capaz de mantener todos los datos que se llevan a cabo durante estas 7 horas, de lo contrario ,el export fallará con el error típico de UNDO insuficiente

Como siempre, la información completa en la Documentación de oracle

Tabla noexp$ en oracle

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)»

RMAN por entorno de red de windows (ORA-27040 )

Hoy veremos un error bastante comun cuando intentamos hacer un rman remoto en un entorno windows

Supongamos tenemos un servidor windows A y queremos hacer un backup de RMAN depositado en otro servidor windows B

rman target / nocatalog cmdfile rman_windows.cmd

Donde el fichero rman_windows.cmd es

run {
  allocate channel c1 type disk format '\\B\BCKORACLE\rman_pruebas%U';
  backup database;
}

En función de los permisos que tengamos en el servidor B, obtendremos un error:

canal c1: iniciando parte 1 en 18/08/13
canal liberado: c1
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03009: fallo del comando backup en el canal c1 en 08/18/2013 09:12:55
ORA-19504: fallo al crear el archivo "\\B\BCKORACLE\rman_pruebas08OH_1"
ORA-27040: error de creacion de archivo, no se ha podido crear
OSD-04002: no se ha podido abrir el archivo
O/S-Error: (OS 5) Acceso denegado.
Recovery Manager terminado.

Como podemos ver en el error, leyendo siempre de abajo a arriba es un error de acceso de sistema operativo, tal y como indica la nota (Doc ID 145843.1) How to Configure RMAN to Write to Shared Drives on Windows NT/2000/2003 , Oracle necesita tener permisos de SYSTEM sobre el punto de red en el que va a escribir, por tanto tendremos que dar full control al usuario con el que se este ejecutando la base de datos ( o el script de lanzamiento) sobre el recurso remoto.

Un consejo para los windows 2003 en adelante es el no utilizar nombres locales de redes mapeadas, sino que es mas conveniente el uso de nombres de red genérico.

NOTA: En caso de ser una carpeta compartida por entorno de red de windows habrá que dar control total a el system de la máquina donde se ejecuta el Oracle, esto se puede haer con permisos a MI_DOMINIO\A$ donde MI_DOMINIO es el dominio y A el nombre del servidor