Métodos de parcheados del RAC

Hoy vamos a ver unas nociones rápidas sobre el parchado en un RAC
Parchear el RAC es diferente al parcheado de un sibgle node, si Opatch detecta un cluster preguntará al OUI el nombre del nodo local y el listado de nodos.
Además de esto, antes de instalar un parche hay que parar todoas las aplicaciones que corren en ese directorio de software deben de pararse.

Exsisten 3 métodos de parcheado de un RAC

  • All Node Patching
  • Rolling Patching
  • Minimum Dowtime

Para llevar a cabo el parchado seguiremos los siguientes pasos:
1. Parar el grid y todo lo que dependa de el en el nodo ( incluido ASM de single instances)
2. Desbloquear el GRID_HOME, como root ejecutaremos
cd $GRID_HOME/crs/install
perl rootcrs.pl -unlock -crshome /u01/app/11.2.0/grid

Al ejecutar el rootcrs.pl con el flag -unlock desbloqueamos el GRID_HOME con lo que ya puede modificarse
3.Con el usuario del grid p parcheamos con el método que elijamos ( ver 3 métodos)
4. Como root de nuevo,volvemos a bloquear los binarios del grid con
cd $GRID_HOME/crs/install
perl rootcrs.pl -patch

Al ejecutar el rootcrs.pl con el flag -patch bloqueamos el GRID_HOME y se rearranca el Oracle Clusterware stack

Métodos de parcheado

Vamos a describir cada uno de los tres métodos de parchado y las diferencias entre ellos

All Node Patching

Este método consiste en parar todos los recursos de todos los nodos y se instalan a la vez. una vez están todos parcheados arrancamos de nuevo.
Esté método es el que se usa típicamente para los parches críticos y es el que tiene el máximum downtime.
Opatch usa este método cuando el parche no puede aplicarse en “ rolling fashion” y cuando no se especifica la opcion minimize_downtime
Los pasos serían:

$ CRS_home/crs/bin/crsctl stop cluster -all
$ Grid_home/bin/crsctl status resource -t
$ cd Oracle_home/OPatch/4519934/4519934
opatch apply
# Grid_home/bin/crsctl start cluster -all (como root)
$ Grid_home/bin/crsctl status resource -t

Tras esto ejecutamos los post-scripts que nos diga el readme.

Rolling Patching

El método de Rolling patching es el método mas eficiente para la aplicación de parches en un RAC o un GRID. En este método se para un grupo de nodos , se aplican los parches a ese grupo, se levanta.. se va haciendo así hasta que todos los nodos del cluster están parcheados.
De esta forma el downtime es cero ya que siempre dejas un nodo disponible de cada instancia.
No todos los parches pueden ser aplicados mediante este método. Si no puede aplicarse es cuando tendrás que aplicar el “minimun downtime” o “all node”
Los pasos son:

opatch query -is_rolling_patch
$ Grid_home/crs/bin/crsctl stop cluster -n RAC1 (paramostodo)
opatch apply [-local_node rac1] -remote_nodes rac2, rac3 Arrancamos los nodos que hemos parcheado
Comprobamos el estado con crsctl stat res –t
Repetimos lospasos 2-5 en los que quedan
Ejecutamos los comandos post-pacth

Minimun Downtime

Este método es el casi igual que el de rolling patching, pero lo llevamos a cabo cuando losparches no sean “rolling patch”La diferencia principal es que los nodos que se van parando y arrancando son los que tienen un mismo servicio.Se pierde servicio enlos nodos parcheados, pero si hay mas de un servicio el resto sigue funcionando. Es una mezcla entre el mejor (rolling) y el peor(all nodes)
En este método se para un grupo de nodos , se aplican los parches a ese grupo, se levanta.. se va haciendo así hasta que todos los nodos del cluster están parcheados.
Los pasos son:

Elegimos un grupo de onodos aparchear.
$ Grid_home/crs/bin/crsctl stop cluster -n RAC1 (paramos todo)
opatch apply -minimize_downtime
Arrancamos los nodos que hemos parcheado
Comprobamos el estado con crsctl stat res –t
Repetimos lospasos 2-5 en los que quedan
Ejecutamos los comandos post-pacth

A groso modo esta es la diferencia entre los 3 métodos de parchado de un RAC, evidentemente, como siempre, conviene leerse el README tanto para ver las especificaciones del parche, como la vuelta atrás.
Antes de ejecutar los comandos que ponemos aquí, es siempre recomendable el hacer las propias comprobaciones previas con el Opatch tal y como indicábamos en la entrada para ver si la instalación cumple con los requisitos del parche.

Problemas con minusculas en el resource manager desde OEM12c

Hoy vamos a ver un caso que puede volvernos un poco locos y que su solución es terriblemente sencilla.

Cuando intentamos usar el resource manager para mapear nuestros usuarios a un determinado grupo de consumidores nos encontramos que podemos intentar hacerlo por algun elemento que tenga mayusculas y minusculas.
Supongamos queremos añadir a el grupo DESARROLLO los usuarios que se conectan con el e toad y SQL Developer. Para ello ejecutaríamos

BEGIN
dbms_resource_manager.clear_pending_area();
dbms_resource_manager.create_pending_area();
dbms_resource_manager.set_consumer_group_mapping(dbms_resource_manager.client_program,'Sqldeveloper.exe','DESARROLLO');
dbms_rsource_manager.set_consumer_group_mapping(dbms_resource_manager.client_program, 'toad.exe','DESARROLLO');
dbms_resource_manager.submit_pending_area();
END; 
commit;

Pero si seguimos la pista a las sesiones de estos dos programas, veremos como no se mapean correctamente con el grupo de consumidores que queremos.
Ejecutando la siguiente consulta podemos ver la causa:

select * from DBA_RSRC_GROUP_MAPPINGS
   where attribute = 'CLIENT_PROGRAM';
ATTRIBUTE        VALUE               CONSUMER_GROUP 
------------------------------------------------------------------
CLIENT_PROGRAM    SQLDEVELOPER.EXE   DESARROLLO 
CLIENT_PROGRAM    TOAD.EXE           DESARROLLO 

¿Que es lo que ha ocurrido?

El problema que tenemos aquí es que las funciones dbms_resource_manager nos van a pasar a mayusculas los valores que le pasemos entre comillas simples.
Si nos fijamos en los comandos que hemos introducido antes vemos que el nombre del client_program lo hemos introducido entre comilla simple

dbms_rsource_manager.set_consumer_group_mapping(dbms_resource_manager.client_program, 'toad.exe','DESARROLLO');

Si lo que buscamos tiene mayusculas y minusculas o simplemente minusculas, deberemos pasarle el parámetro como un literal,es decir, entre comillas dobles

BEGIN
dbms_resource_manager.clear_pending_area();
dbms_resource_manager.create_pending_area();
dbms_resource_manager.set_consumer_group_mapping(dbms_resource_manager.client_program,'"Sqldeveloper.exe"','DESARROLLO');
dbms_rsource_manager.set_consumer_group_mapping(dbms_resource_manager.client_program, '"toad.exe"','DESARROLLO');
dbms_resource_manager.submit_pending_area();
END; 
commit;

Con esto nos cogerá la informacion correctamente.

select * from DBA_RSRC_GROUP_MAPPINGS
   where attribute = 'CLIENT_PROGRAM';
ATTRIBUTE        VALUE               CONSUMER_GROUP 
------------------------------------------------------------------
CLIENT_PROGRAM    SQLDEVELOPER.EXE   DESARROLLO 
CLIENT_PROGRAM    TOAD.EXE           DESARROLLO 
CLIENT_PROGRAM    Sqldeveloper.exe   DESARROLLO 
CLIENT_PROGRAM    toad.exe           DESARROLLO 

La información completa como siempre en metalink

  • Resource Manager Plan Is not Applied With Mixed or Lower Case Application Name (Doc ID 471173.1)
  • 11G: Oracle Resource Manager Client_program Mapping Not Working, Converted to Capital Letters (Doc ID 1586148.1)

Cambiar de Pfile a Spfile en Windows

Hoy vamos a ver una entrada que es muy básica en Unix pero que puede traer algún quebradero de cabeza en windows.

¿Que ocurre cuando queremos pasar de Pfile a Spfile en Windows?

La pregunta parece sencilla de resolver, y es que , simplemente tenemos que dejar un fichero llamado spfile_SID.ora en el directorio $ORACLE_HOME/database ( el equivalente a $ORACLE_HOME/dba de UNIX) pero, cuando hacemos esto en windows falla.

El problema se encuentra en el modo de arranque, a la hora de crear el servicio seguramente se creo con el parámetro «pfile=XXX» , con lo que el motor busca exactamente el fichero init_SID.ora y por eso no arranca con el nuevo spfile.

Para solucionarlo, abriremos el regedit e iremos a:
HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\HOME
Allí hay una entrada para cada instancia llamada ORA__PFILE. Lo que vamos ha hacer es eliminar esa entrada, haciendo que el motor busque el fichero de arranque por defecto.

Ah!, recordad que debería de existir el fichero SPFILE, para crearlo desde la 11g la manera mas sencilla es:

 create spfile  from memory;

Si estáis en alguna versión anterior siempre podéis seguir la entrada http://clemente.pamplona.name/dba/recuperar-un-spfile-borrado/

Como siempre, mas información en Soporte.

  • (Doc ID 378021.1) Oradim and Spfile
  • (Doc ID 232587.1) FAQ About Usage of Spfile and Pfile on Windows

Procesos específicos del RAC

Una de las principales diferencias que vamos a encontrar cuando nos encontremos en un RAC es que aparecen un monton de nuevos procesos daemon en el sistema operativo que apriori no sabemos para que sirven. En esta entrada vamos a echar un vistazo rápido a estos procesos.

  • LCK: Lock Process
  • LMD: Lock Manager Daemon Process
  • LMON: Lock Monitor Process
  • LMS: Lock Manager Server Process
  • ACFS: ASM Cluster File System CSS Process
  • ACMS: Atomic Control File toMemory Service Process
  • GTXn: Global Transaction Process
  • LMHB: Global Cache/Enqueue Service Heartbeat Monitor
  • PING: Interconnect Latency Measurement Process
  • RMSn: Oracle RAC Management Process
  • RSMN: Remote Slave Monitor Process

Entre estos procesos, los mas destacables son:

LCK: Lock Process

Los procesos LCK manejan las peticiones que no son parte del cache-fusión. Además de esto mantiene una lista de los elementos bloqueados que utilizará para validarlos durante la recuperación de la instancia.
Solamente puede haber un único proceso lck por instancia.

LMON: Lock Monitor Process

El lock monitor (LMON) es el proceso responsable de monitorizar el global enqueue.
Es el responsable de la reconfiguración de los bloqueos de los recursos del cluster cuando una instancia entre o sale del cluster además de ser el responsable del dynamic lock remastering. También es el responsable de comprobar si un nodo está muerto e iniciar la reconfiguración lo antes posible.
LMON generará un fichero de traza cada vez que ocurra una reconfiguracion (as opposed to
remastering of a subset of locks).

LMS: Lock Manager Server Process

El lock manager server (también llamado global cache service process) es el responsable de transmitir los bloques entre las instancias para las peticiones de cache-fusion.
En una petición consistent-read el LMS primero hará un rollback del bloque creando una consstent read (CR) de bloque y enviará esa versión del bloque por la interconexión al proceso foreground remoto.
Además de esto, el LMS interactúa con el LMD (Lock Manager Daemon Process) para obtener las peticiones de bloqueos.
Una instancia puede tener entre 1 y 26 procesos LMS. El número de procesos se puede fijar con el parámetro GCS_SERVER_PROCESSES y es un parámetro dependiente del numero de CPUS. En el momento del arranque se marca en CPU_COUNT/4.
Este proceso debe de correr con la máxima prioridad en el S.O (scheduling priority set to Real Time)

ACFS: ASM Cluster File System CSS Process

El Automatic Storage Management (ASM) Cluster File System CSS (ACFS) es un proceso Nuevo de la 11g Release 2 que entrega los cambios de miembros del CSS al ASM, estos cambios son necesarios para que el ASM mantenga la consistencia con el cluster.

ACMS: Atomic Control File toMemory Service Process

El Atomic Control File to Memory Service (ACMS) ) es un proceso Nuevo de la 11g Release 2 que se asegura que las updates del SGA son correctos globalmente o globalmente abortados (evento de fallo)

GTXn: Global Transaction Process

Los procesos Global Transaction (GTXn) es un proceso Nuevo de la 11g Release 2 que ayudan a mantener información global sobre las transacciones globales (XA) atraves del cluster.

LMHB: Global Cache/Enqueue Service Heartbeat Monitor

Los LM Heartbeat Monitor (LMHB) son un procesos Nuevo de la 11g Release 2 que se encargan de monitorizar que los LMON, LMD, and LMSn funcionan correctamente sin bloqueos

PING: Interconnect Latency Measurement Process

También nuevo en la 11g Release 2, cada pocos segundos se envían pings entre las instancias, el tiempo del ping es recopilado y medido

RMSn: Oracle RAC Management Process

El proceso Oracle RAC Management (RMSn) lleva a cabo varias tareas como puede ser crear los recursos de un RAC cuando una instancia se añade al cluster

RSMN: Remote Slave Monitor Process

El Remote Slave Monitor (RSMN) background process administra la creación de procesos esclavos y la comunicación entre sus corrdinadores. Estos procesos realizan tareas en nombre de un proceso de coordinación corriendo en otra instancia de clúster .

Troubleshooting Oracle Clusterware: diagcollection.pl

Hoy vamos a ver una entrada sencilla sobre como recopilar información del Clusterware para enviar a Oracle.
Diagcollecton.sh es un script del CRS que recolecta los logs del CRS del nodo local , es un wrapper sobre el perl diagcollection.pl
Obtiene información sobre:
• Cluster Synchronization Services (CSS),
• Event Manager (EVM),
• Cluster Ready Services (CRS) daemons.
Este log suele ser solicitado por soporte Oracle , El tamaño es bastante grande ( del orden de 1,1 Gb )

La forma de uso es muy sencilla,solamente hay que buscarlo bajo el arbol de directorios del GRID.

Esta herramienta va a buscar también información sobre el sistema operativo, con lo que será conveniente su ejecución como root