Los procesos de oracle

2024-04-05

Background process (procesos background o procesos en segundo plano).

Los procesos background de una instancia son los procesos que son lanzados cuando la instancia comienza y están corriendo hasta que la instancia termina.

Hay 5 procesos de fondos principales:

SMON (System Monitor).

PMON (Process Monitor).

DBWn (Database Writer).

LGWR (Log Writer).

CKPT (Checkpoint Process).

Se tienen además otros 4 procesos comunes pero no esenciales:

MMON (Manageability Monitor).

MMAM (Memory Monitor).

ARCn (Archiver).

RECO (Recover).

Implementación de los procesos según Sistema Operativo (S.O.)

LINUX/UNIX: Se tienen procesos de S.O. separados, con identificador único para cada uno.

Windows: Se tiene un único proceso de S.O. denominado Oracle.exe , con un conjunto de hilos correspondientes a cada proceso background .

Procesos Background

SMON (System Monitor):

Al principio tiene la tarea de montar y abrir una Base de Datos: Monta una Base de Datos localizando y validando el Fichero Control de la Base de Datos. Y la abre, localizando y validando todos los ficheros de datos y los ficheros log, los cuales los encuentra gracias al Fichero de control.

Una vez que la Base de Datos es montada y abierta, SMON es el responsable de varias tareas como la localización del espacio libre para los ficheros de datos .
Si en el arranque de la base de datos se detecta que hay que hacer una recuperación, este proceso se encarga de recuperar la instancia durante el arranque, utilizando para ello los ficheros de actualización ( Redo log files ).

Mientras la base de datos (BD) está en uso, se encarga de varias tareas de mantenimiento como: Limpiar los segmentos temporales no utilizados Compactar el espacio libre contiguo en los ficheros de datos ( Data files ).

PMON (Process Monitor):

Una sesión de usuario es un proceso de usuario que está relacionado con un proceso de servidor.

El proceso de servidor es lanzado cuando la sesión es creada y destruida cuando la sesión se termina.

Una salida ordenada de una sesión implica que todos los procesos terminan correctamente. Cuando esto ocurre, cualquier trabajo que él hacia será completado de un modo ordenado, y su proceso de servidor será terminado.

Si la sesión es terminada de una manera desordenada, (porque el ordenador se reinicie o un corte de luz) entonces la sesión será dejada en un estado que debe ser limpiado.

PMON supervisa todos los procesos de servidor y descubre cualquier problema con las sesiones .

Si una sesión se ha terminado anormalmente:

Destruirá el proceso de servidor, y devolverá la memoria PGA para que sea utilizada por otro proceso.

Y volverá atrás cualquier transacción incompleta que puede haber estado en el proceso.

DBWn (Database Writer):

Por regla general las sesiones no escriben al disco. Las sesiones escriben los datos en el Cache Buffer De La Base de Datos. El escritor de Base de Datos (DBWn)es el que escribe el buffers al disco .

Es posible para una instancia tener varios DBWn (hasta un máximo de 20) que serán llamados DBW0 , DBW 1, etc.

El DBWn escribe la información del DB Cache Buffer a los ficheros de datos, pero no escribe los buffer cuando se mete información. La idea general es que las operaciones de entrada/salida del disco son malas para la ejecución (baja el rendimiento), de aquí que solo se escriba en el disco cuando es realmente necesario.

Si un bloque en un buffer ha sido escrito por una sesión, hay una posibilidad razonable de que sea escrito otra vez por la misma sesión o por otra diferente. Por lo cual solo se grabaran al disco los buffer que no han sido recientemente usados.

DBWn escribe según un algoritmo, hay 4 circunstancias que hacen que DBWn escriba:

Ningún buffer libre.

Demasiados buffer con información.

Un intervalo de espera de 3 segundos.

Cuando hay un checkpoint.

Ningún buffer libre.

Existen 3 estados:

Buffer libre: El espacio se puede utilizar, los datos que contiene ya están pasados al disco.

Buffer sucio: Tiene información que aún no se ha pasado al disco, este buffer no se puede reescribir.

Buffer fijado: Es cuando el buffer está siendo utilizado en ese mismo momento por una sesión.

Cuando no está disponible la cantidad de buffer libre necesario, el DBWn pasará los datos de los buffer sucios al disco. Demasiados buffer con información.

Cuando hay demasiados buffer sucios, el DBWn graba su información al disco. Un intervalo de espera de 3 segundos. Hay un intervalo de espera de 3 segundos, cada 3 segundos DBWn escribirá al disco.

Cuando hay un checkpoint. Existen 2 tipos de checkpoint, checkpoint completo o parcial.

Cuando hay un checkpoint completo, todos los buffers sucios son escritos, a diferencia de los 3 modos anteriores que no escriben todos, sino un número de ellos.

Cuando hay un checkpoint parcial, los buffers sucios de uno o dos ficheros de datos son escritos, pero no todos los buffer sucios del DB Cache Buffer. El único momento cuando un checkpoint es absolutamente necesario es cuando se cierra la.

Base de Datos pero puede ser forzado en cualquier momento con el comando:

ALTER SYSTEM CHECKPOINT .

LGWR (Log Writer): Escribe el contenido del Log Buffer a los ficheros log históricos del disco (Redo Log Files).

La escritura se realiza en los siguientes casos:

Cuando se realiza un COMMIT de una transacción válida.

Cuando se llena un tercio del Redo Log Buffer (aunque no se hayan confirmado los registros) .

Cuando el proceso DBWn está preparado para sobrescribir bloques de datos aún no volcados.

Cuando se ha superado el plazo de 3 segundos.

CKPT (Checkpoint Process ):

Permite registrar Checkpoints (puntos de control) en la cabecera de los ficheros de datos ( Data files ) y en el fichero de control ( Control file ). Estos puntos de sincronización son referencias al estado coherente de todos los ficheros de la BD en un instante determinado.

Mantienen la traza de dónde está la posición del checkpoint incremental dentro de un flujo redo.

Si fuese necesario, insta al proceso DBWn a escribir en los ficheros de datos (Data files) algunos buffers ocupados y así permitir avanzar la posición efectiva del checkpoint .

MMON (Manageability Monitor):

La instancia de una Base de Datos junta un número de estadísticas sobre la actividad y la ejecución. Estas estadísticas son acumuladas en el SGA. MMON con regularidad (por defecto, por cada hora) captura estas estadísticas del SGA y las escribe en el Diccionario de Datos . Estarán almacenados como máximo por 8 días.

Cada vez que MMON junta un juego de estadísticas (conocido como una foto), también lanza el Monitor de diagnóstico de bases de datos automática , el ADDM. El ADDM es un instrumento que analiza la actividad de la Base de Datos.

MMON continuamente supervisa la Base de Datos y la instancia para chequear si alguna alerta debe ser disparada.

MMAM (Memory Monitor):

Mediante este proceso se gestionan, de forma automática, las asignaciones de memoria. Se monitorea la asignación de espacio para las sesiones de usuario y estructuras de memoria SGA y PGA .

El tamaño de la SGA y sus estructuras (exento el Log Buffer) pueden ser modificados de forma automática. MMAN supervisa la demanda de las estructuras de memoria SGA y puede cambiar su tamaño si es necesario. Los DBA solo tienen que poner un máximo total de la memoria PGA y SGA, y MMAN manejará esta memoria según la demanda que exista.

Estos límites se especifican en los Parámetros de Instancia.

ARCn (Archiver):

Es un proceso opcional y puede haber hasta 30 como máximo. Todos los vectores de cambio aplicados a bloques son escritos en el Log Buffer y luego a los ficheros Online Redo Log Files (por el LGWR). Los ficheros Online Redo Log Files son de tamaño y número fijo, una vez que ellos han estado llenos, LGWR los sobrescribirá con los datos más recientes.

El tiempo que se debe pasar antes de que esto pase depende del tamaño y número de fichero log históricos, y la cantidad de actividad DML contra la Base de Datos. Esto significa que el fichero Online Redo Log Files solamente almacena vectores de cambio para reciente actividad.

A fin de conservar un histórico de todos los cambios aplicados a los datos, los archivos Online Redo Log Files deben ser copiados cuando ellos están llenos y antes de que ellos sean reutilizados .

El ARCn es responsable de hacer duplicados de los ficheros Online Redo Log Files antes de que estos vuelvan a ser reescritos. El nuevo fichero que se crea se conoce como fichero Redo Log, si estos ficheros se conservan se podrá hacer una restauración de la Base de Datos a cualquier punto de tiempo anterior, ya que se podrá aplicar los vectores de cambios extraído de ellos. LGWR escribe en los ficheros log online; ARCn los lee.

Las bases de datos pueden encontrase en dos modos:

Modo “Archive log”: Existirán procesos ARCn que se ejecutarán de forma automática y evitarán que el proceso LGWR sobrescriba los Online Redo Log Files hasta haberlos archivado correctamente a un Archivo Log File.

Modo “No archive log”: En este modo la Base de datos no disponte de procesos ARCn por lo que solo se podrá recuperar los datos que se encuentran en los ficheros Online Redo Log File y como solo puede haber un número determinado(por defecto 3) la recuperación de la base de datos solo se podrá según los datos almacenados en ellos. Por lo cual toda Base de Datos en producción tiene que estar en modo Archive Log, para poder crear los ficheros históricos de Redo Log y poder hacer una restauración en cualquier momento anterior.

Se tienen por defecto 4 procesos ARCn. Con el mecanismo Redo Log se almacena los vectores de cambio recientes, mientras que los procesos ARCn se encargan de preservar una historia completa de todos los cambios realizados.

RECO (Recover) (opcional):

Una transacción “distribuida” involucra modificaciones sobre 2 o más Bases de Datos (BDs) y requiere un Commit en dos fases, para garantizar la consistencia.

Si se produce algún error entre la realización de cambios y la confirmación distribuida, el proceso RECO efectúa un Rollback sobre las BDs implicadas.

Otros procesos de background

Existen muchos más procesos background como son: