El proceso LMS mantiene el registro de los estados de los datafiles y de cada bloque en cache obtiene su información del Global Resource Directory (GRD).
El proceso LMS el flujo de mensajes el flujo de mensajes con la instancia remota y maneja el acceso global a los bloques de datos y transmite imágenes de los caches de buffers entre las diferentes instancias. Este proceso es parte de la Cache Fusion.
Es un proceso muy activo que consume mucha CPU.
El siguiente es un link que creo que está bien tenerlo guardado para futuras referencias. Es un cuadro con el nombre de los procesos de background, su nombre, descripción y máximo número de procesos que se puede levantar. Está inglés, pero tiene la información esencial sobre los procesos:
http://docs.oracle.com/cd/E14072_01/server.112/e10820/bgprocesses.htm
Este proceso de background: database writer process (DBWn) es el encargado de escribir el contenido de los buffers en los datafiles. Los procesos DBWn son los responsables de escribir los buffers modificados (dirty) en la cache de buffer a disco. A pesar de que un solo proceso (DBW0) normalmente es suficiente para una base de datos se pueden especificar más de uno (de DBW1 al DBW9 y de DBWa a DBWj). Esto mejorar el rendimiento en la escritura a disco, en el caso de que la base de datos modifique mucha cantidad de datos. Estos procesos adicionales no tienen ningún sentido si el sistema no es multiprocesador.
Cuando se modifica un buffer en la cache de datos se marca como dirty. Un “cold buffer” es un bufuer que no ha sido utilizado recientemente de acuerdo con el algoritmo “least recently used” -lo menos recientemente usado- (LRU). Los procesos DBWn escriben los cold, dirty buffers a disco para asegurar que los procesos de usuario sean capaces de encontrar cold, clean buffers que se pueden utilizar para leer los nuevos bloques en la cache. A medida que los buffer se van escribiendo por los procesos de usuario, el número de buffers libre disminuye. Si el número de buffers libres alcanza un número demasiado bajo, los procesos de usuario que tiene que leer los bloques de disco a la cache, no son capaces de encontrar buffers libres.
Escribiendo los cold, dirty buffers a disco, el DBWn mejora el rendimiento a la hora de encontrar buffers libres, mientras mantiene los más usados en memoria: Por ejemplo los bloques que son parte de tablas pequeñas o índices a los que se accede frecuentemente se mantiene en cache, con lo cual no se necesita estar constantemente recuperándooslos del disco. El algoritmo LRU mantiene los bloques a los que se llama más frecuentemente, así que cuando un buffer se escribe en disco es porque normalmente no se va a necesitar pronto.
El parámetro de inicialización DB_WRITER_PROCESSES específica el número de procesos. El número máximo es 20. Y si no se especifica al principio Oracle lo determina basandose en el número de CPU y los grupos de procesadores.
Basado en el siguiente documento: http://docs.oracle.com/cd/B14117_01/server.101/b10743/process.htm#i7259
El proceso archiver (ARCn) copia los ficheros redo log files a un dispositivo de almacenaje designado cada vez que se produce un cambio de log. Solamente aparecen cuando la base de datos está en modo ARCHIVELOG y está activado el “automatic archiving”.
Una instancia Oracle puede tener levantados10 procesos ARCn (del ARC0 al ARC9). El proceso LGWR levanta un nuevo ARCn cada vez que el número de procesos ARCn es insuficiente para mantener la carga. En el alert se registra cada vez que el LGWR levanta un nuevo proceso ARCn.
Si se anticipa un carga de trabajo de archive muy alta, por ejemplo en una carga masiva de datos, se pueden especificar múltiples procesos archive con el parámetro LOG_ARCHIVE_MAX_PROCESSES. La sentencia ALTERSYSTEM puede cambiar el valor de este parámetro dinámicamente incrementando o disminuyendo el número de proceso. Sin embargo no es necesario modificar este parámetro porque la base de datos lo incrementará el número de procesos siempre que lo considere necesario.
Cajón de sastre sobre oracle 