Añadir un recurso a grid control /clusterware

Una de las ventajas que nos ofrece Oracle clusterware o Oracle Grid control es el gestionar una serie de elementos/procesos/aplicaciones arrancándolas o parándolas de manera centralizada.

Si instalamos nuestras bases con  la infraestructura de grid control, podemos aprovecharnos de la misma para gestionar en el arranque otros elementos como servidores de aplicaciones o la consola de administracion.Esto puede sernos muy util por ejemplo en caso de reinicio del servidor ya que grid control se puede encargar de levantar estos procesos.

En esta entrada vamos a ver como añadir la consola de administracion a el grid control, pero puede ser igualmente valido para cualquier procesos/servidor como podría ser un tomcat, apache o cualquier cosa por el estilo.

Como pasos prvios necesitaremos:

  • Script de arranque/parada/check de nuestra aplicacion, en nuestro caso estará en /opt/oracle/app/admin/PRUEBAS/consola/dbconsole
  • SID del grid  en nuestro caso +ASM
  • SID de la instancia en nuestro caso PRUEBAS
  • Nombre del servidor: En nuestro caso  pruebas.org

Vamos primero a ver el script que arranca/para /chequea la consola

#! /bin/sh
# Author:    Clemente Pamplona
# Date:      15-10-2012
# Usage:     dbconsole [start|stop|status|check]
# Purpose:   Arranca ,para y quequea la dbconsole 
# Copyright: GNU GPL

export ORACLE_SID=PRUEBAS
export ORAENV_ASK=NO
export ORACLE_BASE=/opt/oracle
export ORACLE_HOSTNAME=pruebas.org
. oraenv 
case $1 in
    START|start)
        emctl start dbconsole
         ;;
    STOP|stop)
        emctl stop dbconsole
        ;;
    STATUS|status)
        emctl status dbconsole
        ;;
    CHECK|check)
      rm /var/tmp/consola_status.txt
      emctl status dbconsole 
      if [ $? != 0 ]
        then exit 1;
        fi
        ;;

    *) echo "Usage: dbconsole [start|stop|status|check]"
       exit
     ;;
   esac

Este script podemos probarlo como usuario oracle en el servidor.

Una vez tenemos nuestro script creado que es capaz de arrancar y parar la consola, cargaremos el entorno del grid.

[oracle@pruebas.org consola]$ . oraenv
ORACLE_SID = [oracle] ? +ASM

Lo primero que vamos ha hacer es comprobar que elementos tiene corriendo nuestro grid

[oracle@pruebas.org consola]$ crs_stat -t
Name              Type                Target    State     Host
-----------------------------------------------------------------
ora.DATA.dg       ora.diskgroup.type ONLINE    ONLINE    pruebas.org
ora.LISTENER.lsnr ora.listener.type  ONLINE    ONLINE    pruebas.org
ora.asm           ora.asm.type       ONLINE    ONLINE    pruebas.org
ora.cssd          ora.cssd.type      ONLINE    ONLINE    pruebas.org
ora.pruebas.db    ora.database.type  ONLINE    ONLINE    pruebas.org
ora.diskmon       ora.diskmon.type   OFFLINE   OFFLINE
ora.evmd          ora.evm.type       ONLINE    ONLINE    pruebas.org
ora.ons           ora.ons.type       OFFLINE   OFFLINE

Vemos como tenemos claramente identificados el ASM, el Listener y la instancia . Así pues vamos  a añadrir un recurso local  tal y como dice la documentacion del crsctl

crsctl add resource dbconsola_pruebas -type local_resource \
-attr "ACTION_SCRIPT=/opt/oracle/app/admin/PRUEBAS/consola/dbconsole,\
 CHECK_INTERVAL='300',\
 RESTART_ATTEMPTS='2',\
 START_DEPENDENCIES=hard(ora.pruebas.db)"

Con esto le indicamos que cree:

  • recurso llamado pruebas
  • del tipo local_resource
  • usará nuestro script para actuar sobre él
  • chequeará su funcionamiento cada 5 minutos (300 segundos)
  • Intentará rearrancarlo 2 veces
  • Para arrancarlo deberá de estar la base de datos pruebas activa

Ahora podremos arrancarlo /pararlo /monitorizarlo desde las herramientas del grid.

$ORACLE_HOME/bin/crsctl start resource dbconsola_pruebas

$ORACLE_HOME/bin/crsctl stop resource dbconsola_pruebas

$ORACLE_HOME/bin/crsctl status resource dbconsola_pruebas

O bien con la salida total del sistema

[oracle@pruebas.org consola]$ crs_stat -t
Name              Type                Target    State     Host
-----------------------------------------------------------------
dbco..._pruebas  local_resource      ONLINE    ONLINE    pruebas.org
ora.DATA.dg       ora.diskgroup.type ONLINE    ONLINE    pruebas.org
ora.LISTENER.lsnr ora.listener.type  ONLINE    ONLINE    pruebas.org
ora.asm           ora.asm.type       ONLINE    ONLINE    pruebas.org
ora.cssd          ora.cssd.type      ONLINE    ONLINE    pruebas.org
ora.pruebas.db    ora.database.type  ONLINE    ONLINE    pruebas.org
ora.diskmon       ora.diskmon.type   OFFLINE   OFFLINE
ora.evmd          ora.evm.type       ONLINE    ONLINE    pruebas.org
ora.ons           ora.ons.type       OFFLINE   OFFLINE

 

P.D uede parecer algo evidente, pero, nuestro recurso nunca podrá llamarse ora.

‘wait for possible quiesce finish’ regenerando la consola

Regenerar el EMC en una 10g es siempre una caja de sorpresas. Como vimos en una entrada anterior la base de datos se pone en modo quiesce  al menos hasta una version de parcheado  , pero  ¨que ocurre si el tiempo pasa y pasa y el proceso no avanza

 

oracle@server:emca -repos recreate
STARTED EMCA at Jun 4, 2012 10:13:56 AM
EM Configuration Assistant, Version 10.2.0.1.0 Production
Copyright (c) 2003, 2005, Oracle.  All rights reserved.
Enter the following information:
Database SID: ORCL
Listener port number: 1521
Password for SYS user:
Password for SYSMAN user:
Do you wish to continue? [yes(Y)/no(N)]: Y
Jun 4, 2012 10:14:11 AM oracle.sysman.emcp.EMConfig perform
INFO: This operation is being logged at /opt/oracle/product/10.2.0/db_1/cfgtoollogs/emca/produccion/emca_2012-06-04_10-13-56-AM.log.
Jun 4, 2012 10:14:11 AM oracle.sysman.emcp.EMReposConfig dropRepository
INFO: Dropping the EM repository (this may take a while) ...

Como deciamos en la entrada anterior, muchas veces la instancia se pone en modo «quiesce», pero ,  puede haber sesiones que no le dejen ponerse en ese modo, y por eso no pueda ser capaz de eliminar el repositorio.

Si miramos la sesion en la que estamos haciendo  el   vmos que  esta en un evento de espera ‘wait for possible quiesce finish’

mediante la consulta :

 Select p.spid, s.osuser, s.machine, s.username, s.sid, s.serial#
 from v$session s, v$process p
 where p.addr = s.paddr
 and s.sid in (select sid from v$lock where type = 'TX');

podemos ver que sesiones son y hacer lo que queramos con ellas ( matarlas o esperar ).

En mi experiencia, las veces que me ha ocurrido la solución ha pasado por hacer estos  procesos en una ventana programada  en horario en el que no haya usuarios, ya que, cuando la base de datos tiene este tipo de sesiones no suele ser algo  excpcional, sino que suele ser parte de la carga habitual de la base de datos y este tipo de sesiones irán apareciendo una tras otra  entorpeciendo el proceso de regeneracion de la consola

Como siempre, la solucion la tenía Oracle en la nota [152819.1]

 

Reconfigurar el Enterprise manager

Tener que reconfigurar en Enterprise Manager o reconstruir el EM Repository es algo bastante común.

Los comandos para llevarlos a cabo son bastante básicos

emctl stop dbconsole
emca -deconfig dbcontrol db
emca -repos recreate
emca -config dbcontrol db

Sin embargo, hay varios parámetros utiles, como por ejemplo:

-ORACLE_HOSTNAME

-PORT

Nota:Hay que tener cuidado con las regeneraciones en producción ya que en el momento del borrado la base de datos queda en «quiesce mode» con lo que pueden darse casos en los que haya pérdida de servicio  nota  [ID 375946.1]

La forma de ver si esta en quiesce mode es :

SQL> select active_state from v$instance;
ACTIVE_ST
———
QUIESCING

Para mas info genérica  está como siempre el metalink nota   [ID 1099271.1]