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\u00e1pido a estos procesos.<\/p>\n
Entre estos procesos, los mas destacables son:<\/p>\n
Los procesos LCK manejan las peticiones que no son parte del cache-fusi\u00f3n. Adem\u00e1s de esto mantiene una lista de los elementos bloqueados que utilizar\u00e1 para validarlos durante la recuperaci\u00f3n de la instancia.
\nSolamente puede haber un \u00fanico proceso lck<\/i> por instancia.<\/p>\nLMON: Lock Monitor Process<\/h1>\n
El lock monitor (LMON) es el proceso responsable de monitorizar el global enqueue.
\nEs el responsable de la reconfiguraci\u00f3n de los bloqueos de los recursos del cluster cuando una instancia entre o sale del cluster adem\u00e1s de ser el responsable del dynamic lock remastering. Tambi\u00e9n es el responsable de comprobar si un nodo est\u00e1 muerto e iniciar la reconfiguraci\u00f3n lo antes posible.
\nLMON generar\u00e1 un fichero de traza cada vez que ocurra una reconfiguracion (as opposed to
\nremastering of a subset of locks). <\/p>\n
El lock manager server (tambi\u00e9n llamado global cache service process) es el responsable de transmitir los bloques entre las instancias para las peticiones de cache-fusion.
\nEn una petici\u00f3n consistent-read el LMS primero har\u00e1 un rollback del bloque creando una consstent read (CR) de bloque y enviar\u00e1 esa versi\u00f3n del bloque por la interconexi\u00f3n al proceso foreground remoto.
\nAdem\u00e1s de esto, el LMS interact\u00faa con el LMD (Lock Manager Daemon Process) para obtener las peticiones de bloqueos.
\nUna instancia puede tener entre 1 y 26 procesos LMS. El n\u00famero de procesos se puede fijar con el par\u00e1metro GCS_SERVER_PROCESSES y es un par\u00e1metro dependiente del numero de CPUS. En el momento del arranque se marca en CPU_COUNT\/4.
\nEste proceso debe de correr con la m\u00e1xima prioridad en el S.O (scheduling priority set to Real Time)<\/p>\n
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.<\/p>\n
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)<\/p>\n
Los procesos Global Transaction (GTXn) es un proceso Nuevo de la 11g Release 2 que ayudan a mantener informaci\u00f3n global sobre las transacciones globales (XA) atraves del cluster.<\/p>\n
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 <\/p>\n
Tambi\u00e9n nuevo en la 11g Release 2, cada pocos segundos se env\u00edan pings entre las instancias, el tiempo del ping es recopilado y medido <\/p>\n
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\u00f1ade al cluster <\/p>\n
El Remote Slave Monitor (RSMN) background process administra la creaci\u00f3n de procesos esclavos y la comunicaci\u00f3n entre sus corrdinadores. Estos procesos realizan tareas en nombre de un proceso de coordinaci\u00f3n corriendo en otra instancia de cl\u00faster .<\/p>\n","protected":false},"excerpt":{"rendered":"
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 … Sigue leyendo