Archivo de la categoría: Oracle

Entradas sobre bases de datos Oracle

Parametrizacion del kernel en linux: swappiness

Posted on por

Hoy vamos a ver una parámetro poco documentado de la relaccion entre Linux y Oracle.
Cuando miramos las recomendaciones de Oracle para el kernel a la hora de instalarlo en un sistema operativo Linux nos encontramos con:
Configuring Kernel Parameters and Resource Limits

fs.aio-max-nr = 1048576
fs.file-max = 6815744
kernel.shmall = 2097152
kernel.shmmax = 536870912
kernel.shmmni = 4096
kernel.sem = 250 32000 100 128
net.ipv4.ip_local_port_range = 9000 65500
net.core.rmem_default = 262144
net.core.rmem_max = 4194304
net.core.wmem_default = 262144
net.core.wmem_max = 1048586

Pero no hay ni rastro de este parámetro swappiness al que hago referencia. Si miramos en la wikipedia nos indica que :

Swappiness es una propiedad del Núcleo Linux que permite establecer un balance entre el uso del Espacio de intercambio (swap en inglés, por eso el nombre de la propiedad) y la Memoria de acceso aleatorio (RAM).
El swappiness puede tomar valores desde el 0 hasta el 100. Si se establece 0 el núcleo intentará no hacer intercambio, mientras que si se establece 100 el sistema intentará mantener la Memoria de acceso aleatorio lo más libre posible haciendo intercambio.

Este valor está configurado por defecto en las distribuciones Linux a 60 ,y como os decía no encontramos apenas referencias a el en la documentación de Oracle.Pero ¿que significa este valor del swappines a 60?

Significa que, cuando lleguemos al uso de ese 60% de memoria el proceso kswapd se lanzará a hacer su trabajo, haciendo que el rendimiento de nuestra base de datos caíga en picado por el uso de recursos del sistema del proceso kswapd.

¿Que hacer si esto ocurre?

La solucion pasa por modificar este parámetro para que el kswapd no empiece hasta un 10% de memoria libre.

echo vm.swappiness=10 >> /etc/sysctl.conf
sysctl -p

Como os comentaba, esta opcion del kernel de linux está muy poco documentada por parte de Oracle, yo solamente he encontrado referencias a ella en:

ORA-02020: too many database links in use

Posted on por

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 :

Obtener informacion del alert

Posted on por

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

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