Hoy vamos a ver otra de esas entradas sencillas que nos pueden ahorra mucho tiempo.
Uno de los errores que podemos encontrarnos cuando trabajamos con DBlinks es
ORA-02020: too many database links in use
Esto puede ser facilmente solucionable con los parámetros del init.ora
open_links=500 open_links_per_instance=500
Como siempre, la informacion la tenemos en oracle :
En la nueva versión de Oracle Linux (y RedHat) han optado por eliminar el tradicional método de arranque de servicios de /etc/init.d por el uso de systemctl.
Esta nueva funcionalidad cambia totalmente la manera de trabajar con los ficheros de arranque y parada de los servicios y, entre las supuestas virtudes de este sistema , personalmente no ha ninguna que me convezca.
En cualquier caso En esta web Uso de services de RedHat tenemos la información del funcionamiento de los comandos.
A modo de «bookmark» hago un copy & paste de dos tablas de ese documento que pueden sernos de utilidad
Hoy vamos a ver una entrada muy rápida sobre alguna información albergada en el alert.log
Como hemos hablado en alguna entrada anterior , las versiones 11 y 12 de Oracle disponen de una vista con la información del alert.log, ¿de que nos sirve esto?
Pues puede sernos muy útil para obtener mediante consultas SQL algunos patrones, por ejemplo
Veces que se ha hecho un ALTER en lo que llevamos de año
select
ORIGINATING_TIMESTAMP,
MESSAGE_TEXT
from sys.x$dbgalertext
where ORIGINATING_TIMESTAMP >
TO_TIMESTAMP('01-01-14 00:00:00','DD-MM-RR HH24:MI:SS')
and ( MESSAGE_TEXT like 'ALTER%')
Podemos filtrar mucho mas, por ejemplo , quitando las opciones de rman
Veces que se ha hecho un ALTER en lo que llevamos de año quitando el rman
select
ORIGINATING_TIMESTAMP,
MESSAGE_TEXT
from sys.x$dbgalertext
where ORIGINATING_TIMESTAMP >
TO_TIMESTAMP('01-01-14 00:00:00','DD-MM-RR HH24:MI:SS')
and module_id not in ('rman')
and ( MESSAGE_TEXT like 'ALTER%')
and( MESSAGE_TEXT not like 'ALTER DATABASE BACKUP CONTROLFILE TO %')
O si queremos ver las veces que se ha llevado a cabo un evento concreto como arrancado la base de datos
Veces que se ha hecho un ALTER DATABASE OPEN
select
ORIGINATING_TIMESTAMP,
MESSAGE_TEXT
from sys.x$dbgalertext
where ORIGINATING_TIMESTAMP >
TO_TIMESTAMP('01-01-14 00:00:00','DD-MM-RR HH24:MI:SS')
and( MESSAGE_TEXT like 'ALTER DATABASE OPEN%')
Como decía al principio, es una entrada muy sencilla, pero que, puede aportarnos información útil en muchos casos
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';
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 :
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