Categoría: RAC

RAC Administration

RAC

Nodes Lacking Space Due to Large Cluster Health Monitor File Crfclust.Bdb

Problema

Al llegar un alerta con el 88 % del /u01 catalogado como un critical, enviado por la herramienta de monitoreo #OracleCloudControl13 , comenzamos por revisar los indicadores de Logs, traces que ya tenemos rgistrados con logrotate y con adrci para su depuracion automatizada.

A continuacion mostramos el estado de volumenes ocupados ,siendo los mismos donde almacenamos los binarios de Oracle en cada uno de los nodos miembros del cluster.

[oracle@srvracpro01]$ df -h /u01
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/VolGroupSys-LogVolU01 100G 78G 22G 78% /u01

[oracle@srvracpro02]$ df -h /u01 
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/VolGroupSys-LogVolU01  100G 81G 19G 81% /u01

Analizemos el problema:

Luego de la revision de los paths en el ORACLE_HOME sin encontrar problemas,  procedemos sobre el GRID_HOME. Luego de la ejecucion del comando du * -sch encontramos directorios con mucho volumen.

Nos dirigimos al $GRID_HOME y verificamos los tamaños de los archivos y nos observamos uno en particular, el archivo Crfclust.Bdb que ocupa aproximadamente 48.5G:

[oragrid@srvracpro01]$ pwd
/u01/app/grid/11.2.0.4/crf/db/srvoracd12b

[oragrid@srvoracd12b srvoracd12b]$ ls -lh | grep bdb
-rw-r----- 1 root root 115M Jan 30 17:28 crfalert.bdb
-rw-r----- 1 root root 48.5G Jan 30 17:28 crfclust.bdb
-rw-r----- 1 root root 8.0K Jan 29 11:54 crfconn.bdb
-rw-r----- 1 root root 126M Jan 30 17:28 crfcpu.bdb
-rw-r----- 1 root root 114M Jan 30 17:28 crfhosts.bdb
-rw-r----- 1 root root 135M Jan 30 17:28 crfloclts.bdb
-rw-r----- 1 root root  88M Jan 30 17:28 crfts.bdb
-rw-r----- 1 root root 8.0K Jan  2 16:58 repdhosts.bdb
-rw-r--r-- 1 root root 115M Jan 30 16:51 srvoracd12b.ldb
[oragrid@srvoracd12b srvoracd12b]$

Entendiendo el problema

Este es un problema que viene derivado del proceso monitor Cluster Health Monitor (CHM) y la base de datos relacionada al proceso, que incrementa notoriamente el espacio.

Solucion

Debemos rezisear el tamaño del file. Seguir leyendo «Nodes Lacking Space Due to Large Cluster Health Monitor File Crfclust.Bdb» →

DataGuard, DB - 11gR2, Oracle 12c, RAC, RMAN

Error 1033 received logging on to the standby

Estuvimos armado una STANDBY en el dia de ayer, como un segundo sitio de contingencia, por que tenemos programado realizar una migracion a 12c.

Como nuestro cliente no tiene licencias de Oracle Golden Gate, la estrategia de llevar la data al nuevo servidor, fue la opcion de Oracle Dataguard.

Para ello:

Nuestro Plan fue llevar desde el PRIMARY SITE a una segunda STBY SITE por medio de la configuracion de Dataguard Broker.

Problema

En este caso y como parte de las tareas planificadas se decidio que el equipo local lleve a cabo las tareas de configuracion.

Al ejecutar el siguiente comando para habilitar la configuracion el DG_BROKER en el STBY SITE:

ALTER SYSTEM SET DG_BROKER_START = TRUE;

Notamos que habilitaron el envio de los redo, a pesar no haber terminado la configuracion del borker.

En el PRIMARY SITE , al ver que estaba habilitado el envio de los redo, se intento agregar la instancia al broker:

DGMGRL>
add database "PRODAR" as connect identifier is "PRODAR" maintained as physical;
Error: ORA-01033: ORACLE initialization or shutdown in progress

Failed.

Esto dio la orden en el sitio primario que comience con el envio de redo, pero notaron que no los enviaba y que el alert log comenzo a mostrar el error: Error 1033 received logging on to the standby Seguir leyendo «Error 1033 received logging on to the standby» →

ASM, Oracle 12c, RAC

How to Check Clusterware Version and Name on Cluster Upgrades

Como comentara en uno de los últimos posts de UPGRADE de Cluster, fue necesario conocer la release.

Pero en ocasiones siempre doy por hecho que todo el mundo conoce de lo que estoy hablando.

Esta semana me han escrito alguno colegas preguntando como obtengo esas salidas.

Aquí mi respuesta …

Cluster Software Version

Nos posicionamos en un nodo, de los n nodos que tengamos.

Si estamos realizando tareas en modo rolling upgrade , podríamos utilizar softwareversion que nos muestra la ultima versión del software, que obtuvo el ultimo start sucesfully en un determinado nodo.

crsctl query crs softwareversion [node_name]

Ejemplo de la ejecución en el mismo nodo donde nos encontramos

[oragrid@exa2adbadm01 ~]$ crsctl query crs softwareversion
Oracle Clusterware version on node [exa2adbadm01] is [12.1.0.2.0]

Ejemplo de ejecucion en un nodo remoto.

[oragrid@exa2adbadm01 ~]$ crsctl query crs softwareversion exa2adbadm02
Oracle Clusterware version on node [exa2adbadm02] is [12.1.0.2.0]

Cluster Active Version

Ahora bien, Seguir leyendo «How to Check Clusterware Version and Name on Cluster Upgrades» →

ASM, exadata, Oracle 12c, RAC

Exadata Apply patch post upgrade

Instalación de Parche en Exadata X5

Cuando administramos un Oracle Exadata Machine es importante encontrarnos con el roadmap actualizado de la fixes de seguridad, patchsets, etc.

Como parte de estas tareas que nos previenen de bugs y otras incidencias, como así también poder migrar los motores de bases de datos, es que decidimos hacer un upgrade  poder llevar a la ultima release de la versión de GridInfra Structure, realizando el upgrade a 12.1.0.2 y decidimos hacer este trabajo en modo rolling :

Verificamos la release actual:

[oragrid@exa2adbadm01 ~]$ crsctl query crs activeversion
Oracle Clusterware active version on the cluster is [12.1.0.0.0]

Stopeamos los servicios del nodo del Cluster:

Run the pre root script.
As the root user execute:

# /crs/install/rootcrs.pl -unlock

Seguir leyendo «Exadata Apply patch post upgrade» →

exadata, Linux, Oracle 12c, RAC

Oracle Exadata | Temporary User Lock and PAM rules

Como parte de las políticas de seguridad de Exadata, en varias ocasiones se encontraron  con que el usuario de Sistema Operativo se lockeo ante diferentes intentos de logueo con la contraseña errónea.

Esto ocurre debido a que debido a que cada Oracle Exadata Machine viene configurada con con pam_tally2 en ON mode.

Existen algunas reglas que ya vienen seteadas, y que nos permite, setear en el archivo de configuración de SSHD, localizados en el file

/etc/pam.d folder

Tip: Dependiendo de la image versión del Exadata es posible que nos encontremos con diferentes configuraciones.

Para conocer cual es nuestra Image Version, podemos ejecutar con el usuario root, el siguiente comando:

[root@exa1adbadm02 ~]# imageinfo

Kernel version: 2.6.39-400.128.17.el5uek #1 SMP Tue May 27 13:20:24 PDT 2014 x86_64
Image version: 12.1.1.1.1.140712
Image activated: 2015-06-24 15:56:48 -0300
Image status: success
System partition on device: /dev/mapper/VGExaDb-LVDbSys1

Ahora bien, para conocer como esta configurado nuestras reglas PAM, nos posicionamos Seguir leyendo «Oracle Exadata | Temporary User Lock and PAM rules» →

DB - 11gR2, exadata, Oracle 12c, RAC, Tunning

Event Monitor (EMON) Slave Process Constantly Consuming CPU

Hoy tuve un problema en produccion en un Exadata X5, con 18 cores CPUS en cada nodo miembro del RAC.

Pude visualizar que estos eventos ocurrian por que estaban siendo generados por los procesos  ora_e000,  ora_e001 , ora_e0002,  ora_e0003 y  ora_e0004.

La base de datos en cuestion es una oracle database 11.2.0.4

Asi mismo revise que el mismo evento ocurria para las dos otras instancias que tenia en la maquina de computo.

[oracle@exaxxxxxx.com.ar] /home/oracle  > ps -ef | grep -i e00
oracle    24719  14021  0 13:28 pts/0    00:00:00 grep -i e00
oracle    42114      1  0 Feb16 ?        00:00:31 ora_e000_ARDOP2
oracle    42118      1  0 Feb16 ?        00:00:33 ora_e001_ARDOP2
oracle    42120      1  0 Feb16 ?        00:00:33 ora_e002_ARDOP2
oracle    42122      1  0 Feb16 ?        00:00:33 ora_e003_ARDOP2
oracle    42124      1  0 Feb16 ?        00:04:37 ora_e004_ARDOP2
oracle   118746      1  0 Mar29 ?        00:00:00 ora_e000_ARTOP2
oracle   118748      1  0 Mar29 ?        00:00:00 ora_e001_ARTOP2
oracle   118750      1  0 Mar29 ?        00:00:00 ora_e002_ARTOP2
oracle   118752      1  0 Mar29 ?        00:00:00 ora_e003_ARTOP2
oracle   118754      1  0 Mar29 ?        00:00:07 ora_e004_ARTOP2
oracle   172631      1  0 Feb23 ?        00:00:27 ora_e000_NTTOP2
oracle   172633      1  0 Feb23 ?        00:00:27 ora_e001_NTTOP2
oracle   172635      1  0 Feb23 ?        00:00:27 ora_e002_NTTOP2
oracle   172637      1  0 Feb23 ?        00:00:28 ora_e003_NTTOP2
oracle   172639      1  0 Feb23 ?        00:03:59 ora_e004_NTTOP2

Busco evidencia por medio de Cloud Control en la seccion de Performance Home

Vemos el consumo de CPU de los procesos en un nodo sin transacciones: Seguir leyendo «Event Monitor (EMON) Slave Process Constantly Consuming CPU» →

exadata, Oracle 12c, RAC, Tunning

Exadata Performance : Recommended Redo Log File Size >= 4GB

En el día de hoy estuve revisando un Exadata X5, en el cual pudimos verificar que no estaba cumpliendo con las políticas recomendadas para el tamaño de REDO, para las maquinas de computo
Oracle Exadata Machine.

Oracle, en su documentación oficial, recomienda que el tamaño de los REDOLOG file deben ser >= 4GB y < 32GB.

Como detalle, es importante saber que no es ideal superar la marca de los 32GB , salvo que se lo requiera el soporte de Oracle.

Esta recomendacion surge,  por que la máquina Exadata puede soportar una tasa extrema de I/O.

Con la última versión de Exadata X-6, se pueden realizar operaciones de I/O de lectura de base de datos de 5 KB hasta 8 GB, o operaciones de escritura de flash de 8 MB de 5 MB por segundo por rack completo.

Revisamos la base de datos en el Exadata:

SQL> SELECT a.group#,
                   b.STATUS,
                   a.MEMBER,
                   b.BYTES/1024/1024 "Size (Mb)"
     FROM gv$logfile a,
                 gv$log b
   WHERE a.group# = b.group# ;

    GROUP# STATUS           MEMBER                                                                            Size (Mb)
---------- ---------------- -------------------------------------------------------------------------------- ----------
         1 INACTIVE         +RECO_EXA/AMX/onlinelog/AMX_redolog_t1g1m2.log                                  512
         1 INACTIVE         +DATA_EXA/AMX/onlinelog/AMX_redolog_t1g1m1.log                                  512
         1 INACTIVE         +RECO_EXA/AMX/onlinelog/AMX_redolog_t1g1m2.log                                  512
         1 INACTIVE         +DATA_EXA/AMX/onlinelog/AMX_redolog_t1g1m1.log                                  512
...
...
         6 INACTIVE         +DATA_EXA/AMX/onlinelog/AMX_redolog_t2g6m1.log                                  512
         6 INACTIVE         +RECO_EXA/AMX/onlinelog/AMX_redolog_t2g6m2.log                                  512
         6 INACTIVE         +DATA_EXA/AMX/onlinelog/AMX_redolog_t2g6m1.log                                  512
         6 INACTIVE         +RECO_EXA/AMX/onlinelog/AMX_redolog_t2g6m2.log                                  512

48 rows selected.

SQL>

 

Algunas consideraciones:

  • Si la aplicación está generando una gran cantidad de LOG SWITCH, 4 GB puede que no sea suficiente y debemos considerar aumentarlo.
  • Los registros de REDO de tamaño inferior a 4GB, pueden llevar a interrupciones de registro innecesarios,  ya que en su mecanismo de control causan cuellos de botella en el rendimiento.
  • Se puede comenzar con el tamaño recomendado de 4 GB y observar los cambios de comportamiento antes de que decidamos aumentar o disminuir el tamaño del REDO.

Idealmente, los archivos de registro de REDO on line deben tener el mismo tamaño y estar configurados para cambiar aproximadamente una vez por hora durante la actividad normal.

Seguir leyendo «Exadata Performance : Recommended Redo Log File Size >= 4GB» →