Archivo del Autor: admin

Acerca de admin

Tras más de 20 años trabajando con tecnologías Oracle, me decidí a recopilar en un Blog algunas de las cosillas útiles para el día a día.

Procesos específicos del RAC

Posted on por

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

Posted on por

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

Comprobar versiones del cluster

Posted on por

Hoy vamos a ver otra de estas entradas sencillas que nos pueden llegar a ser de utilidad llegado el caso

Hay veces ( especialmente en los momentos del parcheado) que queremos saber la version de los componentes del cluster. En estos casos podemos tener varios binarios en la máquina y que sean distintos a el software que está corriendo, o distintas versiones entre distintos componentes del cluster, para ello tenemos las opción query del crsctl .
Las opciones que nos serán útiles son:

  • b>releaseversion: Muestra la versión de los binarios instalados en el nodo local. Este comando puede ser “engañado” modificando la variable PATH
  • activeversion: Muestra la versión que está funcionando. Durante un rolling upgrade la activeversion no cambiará hasta que el upgrading finalize. La activeversion siempre es la versión mas baja entre todos los nodos del cluster.
  • softwareversion:Es el contrario de activeversion, nos indicará la ultima versión instalada en el cluster, también puede indicarnos la version mas alta instalada en uno de los nodos.

Algunos ejemplos de la salida son:

[grid@rac1 ]# crsctl query crs releaseversion
Oracle High Availability Services release version on the local node is [11.2.0.4.0]
 
[grid@rac1 ]# crsctl query crs activeversion
Oracle Clusterware active version on the cluster is [11.2.0.4.0]
 
[grid@rac1 ]# crsctl query crs softwareversion
Oracle Clusterware version on node [rac1] is [11.2.0.4.0]
En single node no
[grid@rac1 ]# crsctl query has releaseversion
Oracle High Availability Services release version on the local node is [11.2.0.4.0]

Procesos background de ACFS

Posted on por

Una vez tenemos un dispositivo bajo /dev/asm/ podemos trabajar con el como si de un disco normal fuera, pero, para poder trabajar en un sistema en cluster necesitaremos ACFS o una solución de terceros.

Procesos background de ACFS

Oracle lanza nuevos procesos para las instancias de ASM que tienen asociados filesystems ACFS
Estos procesos son :

00:00:04 asm_vdbg_+ASM1
00:00:00 asm_vmb0_+ASM1
00:00:00 asm_vbg0_+ASM1
00:00:43 asm_acfs_+ASM1

VDBG.- Volume driver background (asm_vdbg_+ASM1)

Este proceso es el encargado de pasarlas peticiones del ASM al driver de ASDM.
Es tan importante que si muriera de manera no planificada tiraría abajo la instancia ASM

VBGn Volume background process (asm_vmb0_+ASM1)

Es un pool de procesos worker que son los que se encargan de las peticiones entre ASM y ADVM
El nombre es muy similar al anterior,, pero el otro acaba en G y estos en numero

ACFS background process (asm_acfs_+ASM1)

Gestionan todas las transiciones del estado de los miembros del cluster en el ACFS

ACFS background process (asm_acfs_+ASM1)

Gestionan todas las transiciones del estado de los miembros del cluster en el ACFS

Volume Menbership background process (asm_vmb0+ASM1)

The Volume Membership Background processes (VMB0) plays the role of an I/O barrier and I/O fencing function. Interestingly, during an ASM instance failure, this process continues to exist until the ADVM driver has had a chance to write out pending I/O. +ASM_vmb_.trc

Instalación de ADVM

Posted on por

Los binarios necesarios para la generación de los volúmenes se encuentran bajo el árbol de directorios el $GRID_HOME.
Para comprobar el estado de los binarios (soportado,instalado,cargado) usaremos el binario $GRID_HOME/bin/acfsdriverstate

acfsdriverstate [-orahome ORACLE_HOME ]{ installed | loaded | version | supported }

En caso de tenerlo soportado e instalado, puede dares el caso de que no esté cargado, para eso se usa otro binario de la rama que es: $GRID_HOME/bin/acfsload

acfsload { start | stop  } [ -s ]

Donde la –s es el “silent mode”
No existe un /etc/init.d/acfsload por lo que para cargar el módulo en el arranque es necesario el crearlo y ejecutarlo.
Cuando ADVM está cargado, tenemos los siguientes módulos en el kernel 

root@rac1 ~] lsmod |grep ora
oracleacfs           1990406  0 
oracleadvm            250040  0 
oracleoks             427672  2 oracleacfs,oracleadvm
oracleasm              54297  1
  • oracleacfs: gestiona las opciones de sistema de ficheros l ACFS
  • oacleavdm: gestiona las opciones de interfaz del ADVM con el S.O
  • oracleoks: Gestiona la gestión de memoria , y la sincronización y bloqueos de disco

ADVM Creación de un volumen

Para la ceración de un volumen debemos de tener antes un DISKGROUP de ASM
Captura de pantalla 2015-11-21 a las 20.03.02

Vamos a crear un volumen de 500 M llamado ADVMFS1 en el diskgroup ASMFS

ASMCMD> volcreate -G ASMFS -s 500M ADVMFS1
ASMCMD> volinfo -a
Diskgroup Name: ASMFS
	 Volume Name: ADVMFS1
	 Volume Device: /dev/asm/advmfs1-491
	 State: ENABLED
	 Size (MB): 512
	 Resize Unit (MB): 32
	 Redundancy: UNPROT
	 Stripe Columns: 4
	 Stripe Width (K): 128
	 Usage: 
	 Mountpath:

Si miramos el dispositivo que nos ha dicho, vemos como si que existe. ¡!En ambos nodos!! 

[grid@rac1 ~]$ ls -l /dev/asm/advmfs1-491
brwxrwx--- 1 root asmadmin 252, 251393 Aug 27 11:39 /dev/asm/advmfs1-491
[grid@rac2 ~]$ ls -l /dev/asm/advmfs1-491
brwxrwx--- 1 root asmadmin 252, 251393 Aug 27 11:39 /dev/asm/advmfs1-491

Borrado de un volumen

Se lleva a cabo mediante el comando voldelete , necesita el Diskgroup y el volumen 

ASMCMD> volinfo -a
Diskgroup Name: ASMFS
    Volume Name: ADVMFS1
    Volume Device: /dev/asm/advmfs1-491
    State: ENABLED
    Size (MB): 512
    Resize Unit (MB): 32
    Redundancy: UNPROT
    Stripe Columns: 4
    Stripe Width (K): 128
    Usage: ACFS
    Mountpath: /app/oracle/acfsmounts/prueba/ 
ASMCMD> voldelete -G ASMFS ADVMFS1

Al igual que en la creación, elimina el dispositivo en todos los equipos.

ADVM comandos

Los comandos de ADVM son bastante básicos y se ejecutan desde el ASMCMD (o desde el asmca)
Los comandos básicos son:

  • Volcreate: Creación de volumen
  • Voldelete: Elimina el volumen NO es necesario que esté deshabilitado
  • Voldisable: Lo habilita o deshabilita (debe de estar inactivo) “ in mounted disk groups”
  • Volenable: Hablita el dispositivo “ in mounted disk groups”
  • Volinfo: Ofrece información del volumen, con la opción –a da de todos.
  • Volresize: Redimensiona el volume, si está montado un filesystem oracleACFS no se puede hacer un resize, es necesario hacerlo con el comando propio de ACFS acfsutil size 
  • Volset: Sirve para dar/modificar atributos
    Captura de pantalla 2015-11-21 a las 20.05.23

  • Volstat: Da información del I/O del volumen