Archivo de la categoría: 11g

Para un job de impdp de manera correcta

Posted on por

Hoy vamos a ver otra de esas entradas útiles del día a día.

En la entrada eliminar datapumps fallidos vimos como borrar los trabajos de impdp/expdp que estaban en entado fallido. Pero ¿que ocurre si queremos detener un trabajo en ejecución ?

Lo primero que haremos es volver a usar la consulta para ver el estado de los trabajos.

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

Y vemos que tenemos un JOB en modo de ejecucion

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

Si lo que queremos es detener ese trabajo EXPORT_TABLA_1 de manera correcta, ejecutaremos:

SET serveroutput on
SET lines 100
DECLARE
   h1 NUMBER;
BEGIN
  -- Format: DBMS_DATAPUMP.ATTACH('[job_name]','[owner_name]');
   h1 := DBMS_DATAPUMP.ATTACH('SEXPORT_TABLA_1','SCOTT');
   DBMS_DATAPUMP.STOP_JOB (h1,1,0);
END;
/

Ejecutando la consulta que muestra los jobs de exports vemos que tenemos trabajos NOT RUNNING residuales, siempre podemos limpiar la tabla con el resultado de :

SELECT 'DROP TABLE '|| owner_name||'.'|| job_name ||';'
FROM dba_datapump_jobs
where STATE='NOT RUNNING';

Restaurar el fichero de registro del cluster/GRID

Posted on por

Hoy vamos a ver una entada bastante sencilla que nos puede librar de algun susto que otro.

Uno de los componentes que pueden darnos problemas a la hora de arrancar un GRID es el fichero de configuración del cluster.
En el caso de un GRID control donde no hay mas miembros del cluster, esta información solamente está en el nodo de la base de datos, y , si esta información se daña o se pierde no podremos arrancar el ASM y la Base de datos
El fichero de configuración local del cluster/grid puede ubicar mirando en el fichero /etc/oracle/ocr.loc

  bash-3.2# cat /etc/oracle/ocr.loc
ocrconfig_loc=/opt/app/oracle/product/11.2.0/grid/cdata/localhost/local.ocr
local_only=TRUE

El GRID control tiene dos ficheros de configuración que deben de estar disponibles, el Oracle Cluster Registry configuration y el Oracle Local Registry configuration
Podemos ver su ubicación con el comando ocrconfig

root@gridalone:$ $GRID_HOME/bin/ocrcheck -config
Oracle Cluster Registry configuration is :
 Device/File Name: /opt/app/oracle/product/11.2.0/grid/cdata/localhost/local.ocr

root@gridalone:$ $GRID_HOME/bin/ocrcheck -local -config
Oracle Local Registry configuration is :
 Device/File Name: /opt/app/oracle/product/11.2.0/grid/cdata/localhost/sidora.olr

Estos dos ficheros no son ficheros de texto, con lo que no podremos salvaguardarlos ni restaurarlos de manera normal mediante los softwares de backup convencionales.
Para poder restaurarlos, deberemos de hacerlo mediante la opcion ocrconfig -restore

La sintaxsis para restaurarlos es :

Oracle Cluster Registry configuration

$GRID_HOME/bin/ocrconfig  -restore /opt/app/oracle/product/11.2.0/grid/cdata/localhost/backup_XXXXX.ocr

Oracle Local Registry configuration 

$GRID_HOME/bin/ocrconfig -local -restore /opt/app/oracle/product/11.2.0/grid/cdata/localhost/backup_XXXXX.olr

Algunas notas importantes sobre el comando ocrconfig son :

  • No se le indica en ningún sitio donde ha de restaurarlos, esto lo coge de la configuración del cluster
  • Los ficheros que se indican son los ficheros DE BACKUP
  • Necesita que el fichero destino exista, en caso de no existir habría que crearlos con un touch

Hemos de tener en cuenta que, tal y como decíamos en la entrada Oracle cluster registry OCR (componentes del grid) en la version 11gR2 se guardan automáticamene, pero no debemos de confiarnos y es recomendable el comprobar si exsisten backups con la opcion ocrconfig -showbackup para activarlos en caso de que no estén activos

Como siempre, mas información en la web de oracle http://docs.oracle.com/cd/E11882_01/rac.112/e16794/ocrsyntax.htm#CWADD92022

IMPDP con tablas particionadas

Posted on por

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)

Uso de mayúsculas/minúsculas en ASM

Posted on por

Vamos a ver una entrada muy cortita sobre el uso del ASM.

¿Son los ficheros/directorios del ASM sensibles a las mayúsculas y minúsculas?

Si miramos la documentación del ASM de Oracle nos dice una frase algo enigmática
«Only the forward slash (/) is supported by ASMCMD. Filenames are not case sensitive, but are case retentive. If you type a path name as lowercase, ASMCMD retains the lowercase. «

Lo que quiere decir es que, los nombres de los ficheros (y directorios) de ASM no son case sensitive, pero, las cadenas de texto con la que nos lo muestra si.

Vamos a verlo con un ejemplo:

Supongamos tenemos ASM con una base de datos llamada SID.
He creado dos tablespaces con datafiles en SID y siD y no me ha dado error en ninguno de los dos

create tablespace prueba1 datafile '+DATA/SID/prueba1.dbf' size 3m;
create tablespace prueba2 datafile '+DATA/siD/prueba2.dbf' size 3m;

Sin embargo, si intento crear 

create tablespace prueba3 datafile '+DATA/SID/prueba2.dbf' size 3m;

Me da error por que ya existe el mismo fichero con el directorio siD

Conclusión: ASM no es «case sensitive», pero hemos de ser muy cuidadosos a la hora de elegir una política para la notación de los ficheros ya que el uso indiscriminado de unos y otros puede provocarnos errrores.

Obtener el código de un objeto con DBMS_METADATA.GET_DDL

Posted on por

En alguna otra entrada hemos visto el uso de la llamada DBMS_METADATA.
Hoy vamos a ver las pequeñas peculiaridades que rodean a la variable para poder extraer el código de varias tablas.

La primera de las cosas a tener en cuenta es el formateo de la salida.
Hemos de prever el tamaño del código de las tablas, con lo que deberemos de formatear el sqlplus, para ellos pondremos la línea al máximo permitido y un valor muy alto en long

set head off
set feedback off
set pages 0
set linesize 32767
set long  2000000

Lo segundo que hemos de tener en cuenta es que , no vamos a tener ningún tipo de carácter que nos marce la separación entre las sentencias, con lo que deberemos de decirle a la librería dbms_metadata que nos marque el carácter. Ese parámetro es un parámetro de sesión con lo que deberemos de ejecutarlo en cada sesión en la que queramos obtener los datos.

exec dbms_metadata.set_transform_param 
   (DBMS_METADATA.SESSION_TRANSFORM, 'SQLTERMINATOR',TRUE);

A partir de aquí ya podemos usar la llamada DBMS_METADATA.GET_DDL para obtener el código deseado :

select DBMS_METADATA.GET_DDL
 ('TABLE','NOMBRE_TABLA','OWNER') 
      from dual ;

Nota En el caso de las tablas podemos seleccionar algunas de las características que queremos mostrar (incluso transformarlas) como pueden ser las de almacenamiento o particionamiento con la opción SET_TRANSFORM_PARAM.

Mas información en lamágina de DBMS_METADATA de la documentación de Oracle.