Archivo de la etiqueta: RAC

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

Acciones comunes sobre el ASM

Posted on por

Hoy vamos a ver un ejemplo de los comando seas habituales que solemos hacer en un ASM

Nombre de los diskgroups

ASMCMD

ASMCMD> lsdg

SQLPLUS

SQL> column name format a20;
SQL>  select NAME,ALLOCATION_UNIT_SIZE,STATE,TYPE,TOTAL_MB,FREE_MB from v$asm_diskgroup
NAME           ALLOCATION_UNIT_SIZE STATE      TYPE     TOTAL_MB    FREE_MB
---------- -------------------- ---------- ------ ---------- ----------
ASMFS             1048576 	  MOUNTED    EXTERN    1019       403
DATA01_PRUEBA     1048576	  MOUNTED    EXTERN    2246       267
OCRVOTING         1048576	  MOUNTED    EXTERN    1019       623
REDO              1048576	  MOUNTED    EXTERN     499       404

Discos en un diskgroup

ASMCMD

ASMCMD> lsdsk -p -G DATA01_PRUEBA
Group_Num  Disk_Num      Incarn  Mount_Stat  Header_Stat  Mode_Stat  State   Path
       2         1  3915953579  CACHED      MEMBER       ONLINE     NORMAL  /dev/oracleasm/disks/ASM01
       2         0  3915953576  CACHED      MEMBER       ONLINE     NORMAL  /dev/oracleasm/disks/DATA_PRUEBA
ASMCMD> lsdsk -G DATA01_PRUEBA
Path
/dev/oracleasm/disks/ASM01
/dev/oracleasm/disks/DATA_PRUEBA

SQLPLUS

SQL> select PATH,STATE,NAME from v$asm_disk where name like '%PRUEBA%';
PATH                		    STATE       NAME
---------------------------------------- ---------- --------------------
/dev/oracleasm/disks/DATA_PRUEBA    NORMAL     DATA01_PRUEBA_0000
/dev/oracleasm/disks/ASM01          NORMAL     DATA01_PRUEBA_0001

Discos candidatos

ASMCMD

ASMCMD> lsdsk --candidate -p
Group_Num  Disk_Num      Incarn  Mount_Stat  Header_Stat  Mode_Stat  State   Path
       0         5  3915953571  CLOSED      FORMER       ONLINE     NORMAL  /dev/oracleasm/disks/ASM02
       0         4  3915953570  CLOSED      FORMER       ONLINE     NORMAL  /dev/oracleasm/disks/ASM03
       0         1  3915953567  CLOSED      PROVISIONED  ONLINE     NORMAL  /dev/oracleasm/disks/ASM04
       0         0  3915953566  CLOSED      PROVISIONED  ONLINE     NORMAL /dev/oracleasm/disks/ASM05

SQLPLUS

column state format a10;
column HEADER_STATUS format a20;
column path format a30;
SQL> select STATE,PATH,HEADER_STATUS from v$asm_disk where header_status !='MEMBER';
STATE    PATH                          	 HEADER_STATUS
-------- -------------------------------------------------- ------------
NORMAL    /dev/oracleasm/disks/ASM05               PROVISIONED
NORMAL    /dev/oracleasm/disks/ASM02               FORMER
NORMAL    /dev/oracleasm/disks/ASM03               FORMER
NORMAL    /dev/oracleasm/disks/ASM04               PROVISIONED

Eliminar un Diskgroup

Para poder eliminar un diskgroup este debe de estar montado.
En caso de querer eliminarlo desmontado deberemos de ponerel flag “forcé”

SQL> drop diskgroup FSARCHPRUEBA force including contents;
Diskgroup dropped.

Creación de Diskgroup

En este caso creamos un grupo de redundancia HIGH, por lo que necesitamos 3 failure groups
SQLPLUS

CREATE DISKGROUP DATA HIGH REDUNDANCY
 FAILGROUP controller1 DISK
   '/dev/oracleasm/disks/ASM01' NAME ASM01,
   '/dev/oracleasm/disks/ASM02' NAME ASM02
FAILGROUP controller2 DISK
   '/dev/oracleasm/disks/ASM03' NAME ASM03,
   '/dev/oracleasm/disks/ASM04' NAME ASM04
FAILGROUP controller3 DISK
   '/dev/oracleasm/disks/ASM05' NAME ASM05
 ATTRIBUTE 'au_size'='4M',
   'compatible.asm' = '11.2',
   'compatible.rdbms' = '11.2';

Ahora creamos un grupo con external 

CREATE DISKGROUP REDO EXTERNAL REDUNDANCY
DISK  '/dev/oracleasm/disks/REDO01' NAME REDO01
ATTRIBUTE 'au_size'='4M',
  'compatible.asm' = '11.2',
  'compatible.rdbms' = '11.2';

ASMCMD
En asmcmd la creación del diskgroup se hace mediante el comando mkdg, pero los parámetros han de ser pasados en un fichero xml

Añadir un disco

ASMCMD (Se hace mediante la sintaxsis en xml)
Chdg fichero-cambios.xml
SQLPLUS

SQL> alter diskgroup DATA01_PRUEBA add disk '/dev/oracleasm/disks/ASM05';
Diskgroup altered.
SQL> select PATH,STATE,NAME from v$asm_disk where name like '%PRUEBA%';
PATH                        		  STATE    NAME
-------------------------------------------------- -------- ------------------------------
/dev/oracleasm/disks/DATA_PRUEBA        NORMAL   DATA01_PRUEBA_0000
/dev/oracleasm/disks/ASM05              NORMAL   DATA01_PRUEBA_0002
/dev/oracleasm/disks/ASM01              NORMAL   DATA01_PRUEBA_0001
Quitamos un disco

ASMCMD (Se hace mediante la sintaxsis en xml)
chdg fichero-cambios.xml
SQLPLUS
Para eliminarse se usa la columna NAME y no PATH



SQL> alter diskgroup DATA01_PRUEBA drop disk DATA01_PRUEBA_0001;

Diskgroup altered.


Comprobar ficheros abiertos de en ASM


ASMCMD> lsof
DB_Name  Instance_Name  Path                                                     
+ASM     +ASM2          +ocrvoting.255.4294967295                                
asmvol   +ASM2          +asmfs/ADVMFS1.256.888838797                             
prueba   prueba2        +data01_prueba/prueba/controlfile/current.256.888313451  
prueba   prueba2        +data01_prueba/prueba/datafile/sysaux.260.888313489      
prueba   prueba2        +data01_prueba/prueba/datafile/system.259.888313463      
prueba   prueba2        +data01_prueba/prueba/datafile/undotbs1.261.888313519    
prueba   prueba2        +data01_prueba/prueba/datafile/undotbs2.267.888578953    
prueba   prueba2        +data01_prueba/prueba/datafile/users.263.888313549       
prueba   prueba2        +data01_prueba/prueba/onlinelog/group_1.257.888313455    
prueba   prueba2        +data01_prueba/prueba/onlinelog/group_2.258.888313459    
prueba   prueba2        +data01_prueba/prueba/onlinelog/group_3.264.888315899    
prueba   prueba2        +data01_prueba/prueba/onlinelog/group_4.265.888315903    
prueba   prueba2        +data01_prueba/prueba/tempfile/temp.262.888313531  

Funcionamiento del Redo en el RAC

Posted on por

Hoy vamos con otra de las entradas para dummies, viendo un poco el funcionamiento del redo en el RAC.
Cada instancia dentro del RAC debe de tener su propio espacio de redo (que se corresponderá con un número único de thread para toda la instancia) y undo.

Pero que ocurre si muere un nodo?
¿Que pasa con los datos que están en esos redos?

En un entorno de RAC, todas las instancias de la base de datos tienen acceso a todos los redo logs de todos los nodos, de esta manera, si uno de los nodos muere, uno de los nodos vivos accederá a el redo de la instancia caída y aplicará de manera automática los cambios de la misma manera que se haría un instance recovery a la hora de arrancar la base de datos. Con lo que los datos en disco siempre estarán consistentes.

¿Que ocurre si caen todos a la vez?
Si todas las instancias cayeran el instance recovery sería llevado a cabo por la primera de las instancias que se levantara, esta sería la encargad de hacer el instance recovery de todos los redos de todas las instancias del rac.

Como veis, a pesar de la complejidad del RAC, el funcionamiento no deja de ser muy sencillo, al menos, visto desde arriba 😉

Arquitectura CRS en 11gR2 II el CRSD

Posted on por

Vamos a seguir viendo la arquitectura del CRSD en la version 11gr2
Primero vamos a recordar la arquitectura del sistema
crs11g

CRSD

El Cluster Ready Services Daemon va a ser el responsable de gestionar los recursos de aplicación del cluster, esto es las bases de datos,y el resto de elementos y aplicaciones. Esta información la sacará el OCR (Oracle cluster registry )

Podemos dividir estos procesos que gestiona en dos grandes grupos:

CRSD oraagent

El CRSD oraagent administra (start/stop/check/clean) varios recursos como son bases de datos, instancias,servicios,diskgroups,node listeners,SCAN listeners…
Podemos tener mas de un oraagent (en la imagen tenemos uno para el grid y otro para la base de datos), esto sucede cuando hay mas de un propietario de la instalacin ( por ejemplo en grid y el de la base de datos)

CRSD orarootagent

CRSD orarootagent es el que se encarga de gestionar (start/stop/check/clean) Elementos como el GNS, las VIPs y los recursos de red.

Arquitectura CRS en 11gR2 I

Posted on por

En la version 11gR2 del RAC la arquitectura del Cluster ready services ha cambiado considerablemente.
En estas dos imágenes, podemos ver el arbol de procesos en la version 10g-11gr1 y la 11gR2

Procesos en la 10g y 11gR1
CRS10g

Procesos en la 10g y 11gR2
crs11g

Como podemos ver el arbol de procesos se ha dividido en dos ramas bien diferenciadas, el OAHSD que manejará los procesos de bajo nivel, y el CRSD que seguirá manejando estos procesos de alto nivel.

[table width=»650″ colwidth=»200|300|150″ colalign=»left|left|left»]
Elemento,Proceso ,Dueño
Oracle High Availability Service, ohasd ,init root
Cluster Ready Service (CRS), Cluster Ready Services, root
Cluster Synchronization Service (CSS), ocssd cssd monitor cssdagent ,grid owner
Event Manager (EVM), evmd evmlogger, grid owner
Cluster Time Synchronization Service (CTSS), octssd, root
Oracle Notification Service (ONS), ons eons, grid owner
Oracle Agent, oragent, grid owner
Oracle Root Agent, orarootagent, root
Grid Naming Service (GNS), gnsd, root
Grid Plug and Play (GPnP), gpnpd ,grid owner
Multicast domain name service (mDNS), mdnsd, grid owner
[/table]
Echemos un vistazo a estos daemons:

OAHASD

Es el primer proceso de todos, este es el que busca en el /etc/oracle/scls_scr/hostname
Además de usar este fichero (no es texto plano) también va a utilizar el directorio de /var/tmp/.oracle para conexiones named pipe
Wste demonio se arranca automáticamente desde el inittab y está respawneado, pero también puede hacerse desde

/etc/init.d/ini.oahsd run

El arranque y la parada será con 

crscrl start crs 

crscrl stop crs

En caso de querer deshabilitar manualmente este arranque podemos hacerlo con 

crsctl disable crs

crsctl enable crs

Vamos a verlos por ramas:

OAHSD oraagent

Es el agente que administra /start/stop los procesos :
[table width=»650″ colwidth=»100|550″ colalign=»left|left»]
Proceso , Funcionalidad
ora.asm,• El ASM deberá de star levantado para que el CSRD pueda acceder a la información contenida dentro\, esto es levantado desde aquí para que esté disponible
ora.emvd,•Es el Event Monitor Daemon y se encarga de publicar y suscribir los eventos del nodo ( como puede ser «database down».
ora.mdnsd,•Multicast Domain Name Services\, es usado en el PNP\, así como para res`pmder al DNS peticiones del Grid Naming Service Daemon (GNSD)
ora.GPNPD,• Grid Plug and Play Daemon \, otro de los nuevos del 11R2 que se usa par ala sincronizacion del GPnP profile entre los nodos.
ora.GPNPD,• Encargado del nuevo protocolo de intercomuicacion del grid Grid IPC
[/table]