Archivo por meses: septiembre 2014

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