ESTRUCTURA DE LOS PROCESOS

Estructura de los procesos

Cuando un usuario se conecta a una base de datos de Oracle ejecuta dos módulos de código diferentes, que además el encargado de gestionar estos procesos es el sistema operativo, estos dos módulos diferentes son:

-Aplicación o Herramienta Oracle: normalmente son programas clientes que se conectan a la base de datos y permiten ejecutar sentencias SQL. Ej.: SQL*Plus, SQL developer

-Código del servidor de Oracle: son los diferentes procesos que se han de ejecutar en el servidor para atender las peticiones del usuario.

La base de datos Oracle es un sistema multiproceso, lo que significa que no toda la base de datos está corriendo en un mismo proceso, si no que varias partes de la base de datos se ejecuta concurrentemente. Permitiendo a múltiples usuarios conectarse a la misma vez, y mayor rapidez en el tiempo de respuesta, puesto que siempre que pueda va a utilizar al máximo al ordenador, por ejemplo si tiene ocho núcleos el servidor, y resulta que una petición se puede paralelizar se ejecutara esa petición por partes en cada núcleo.

De los procesos que se ejecutan en el servidor podemos hacer dos grandes grupos:

-Procesos de usuarios: Cada vez que un usuario ejecuta una aplicación, ya sea propia o de Oracle se crea un proceso, que puede ser de dos tipos.

>conexión: Que es la vía de comunicación entre la aplicación y la instancia de la base de datos a la que se ha conectado.

>sesión: Es la conexión específica con la base de datos proporcionando un usuario y su contraseña.

Esto permite que desde un mismo equipo se puedan conectar varios usuarios simultáneamente, y que un usuario se pueda conectar desde diferentes equipos simultáneamente.

-Procesos de Oracle: Son propios de la base de datos, y el usuario no tiene control sobre ellos, pueden ser de dos tipos:

>Procesos de servidor: Se crea cuando una aplicación intenta acceder a la base de datos, para atender a las peticiones de la aplicación y devolver los resultados que se precisen.

>Procesos de background: Se crean cuando se inicia una instancia de la base de datos, solo hay un proceso de cada tipo de los que especificaremos a continuación, y no han de estar todos siempre presentes en el servidor. Se utilizan para realizar labores de mantenimiento, y para guardar la integridad de la base de datos. Los diferentes tipos de procesos son los siguientes:

Database Writer Process (DBWn)

El (DBWn) escribe el contenido de los buffers en los archivos de datos. El proceso DBWn es responsable por la escritura de los buffers modificados del buffer cache al disco. El proceso DBWn escribe buffers modificados al disco bajo las siguientes condiciones:

- Cuando un proceso no puede encontrar un buffer limpio reusable después de haber recorrido un número de determinado de buffers en el buffer caché, éste envía una señal al DBWn para la escritura. El DBWn escribe los buffers sucios al disco.

-El DBWn periódicamente escribe los buffers cuando se lleva a cabo un checkpoint. Chekpoint es una posición en el hilo de redo (log) donde se iniciará luego la recuperación. La posición en el log está determinada por el último buffer sucio en el buffer caché.

Log Writer Process (LGWR)

El proceso LGWR es responsable del manejo del redo log buffer, las escrituras del redo log buffer al archivo de redo log en el disco. El LGWR escribe todos los registros de redo que han sido copiados en el buffer desde la última vez que éste se escribió. El redo log buffer es un buffer circular. Cuando LGWR escribe los registros del redo log buffer al redo log file, el proceso servidor puede copiar nuevos registros sobre aquellos que se pasaron a disco. LGWR normalmente escribe lo suficientemente rápido para asegurar que el espacio esté siempre disponible en el buffer para nuevos registros, aún cuando la escritura al redo log file sea lenta.

LGWR escribe en porciones contiguas del buffer al disco. El LGRW escribe:

- Un registro de commit cuando un usuario hace commit de una transacción

- Redo log buffers:

-cada tres segundos

-cuando el redo log tenga un tercio lleno

-cuando un proceso de DBWn escriba los buffers modificados a disco, si es necesario.

Cuando un usuario lleva a cabo una instrucción de commit, el LGWR coloca el registro de commit en el log buffer y escribe la transacción a disco inmediatamente en el redo log. Los cambios correspondientes a los bloques de datos en el buffer caché, son dejados hasta que se tenga una escritura más eficiente que hacer. Esto se denomina el mecanismo de fast commit. La escritura de un registro de redo del commit de la transacción es un evento atómico.

Existe un mito con respecto a la escritura en el redo log buffer, se dice que en el redo log buffer o redo log file aparecerán sólo las transacciones comprometidas. En el redo log file se escriben todas las transacciones, no sólo las comprometidas, es por ello que el redo log permite rehacer los segmentos de undo del cualquier punto en el tiempo cuando se hace recuperación incompleta (point in time recovery).

Redo Log Files

Los Redo Log Files se agrupan en grupos de Redo Log. Todos los miembros de un Redo Log Group son idénticos, es decir contendrán la misma información. Dentro de un grupo de Redo Log se "multiplexan" los archivos para evitar los puntos de fallas, es decir si se perdiera un archivo de Redo Log habría otro que contendría la información y que permitiera la recuperación de la base de datos.

Los redo log se utilizan de forma circular, mediante grupos de archivos. Por defecto la base de datos Oracle genera 3 grupos de archivos. Se considerará el grupo current (actual) aquel donde se esté utilizando para escribir las transacciones actuales de la base de datos. Se considera un grupo active (activo), aquel que no es el actual y que posea transacciones cuyos cambios no se han hecho permanentes en los archivos de datos e inactivo aquel que contenga transacciones que han sido completamente escritas a disco, finalmente también se puede tener que un grupo de redo log esté limpio porque nunca haya sido escrito.

Los archivos de redo log trabajan de forma circular porque se sobrescriben, generalmente con los tres grupos se tendrá que uno de ellos se encontrará activo, el siguiente en enumeración será el actual y el siguiente estará inactivo listo para que se escriba en él. Una vez llenado el grupo actual se comenzará a escribir en el inactivo, que ahora será el actual, el que anteriormente era el actual pasará a ser activo si aún no se han escrito todas sus transacciones a disco y eventualmente el que inicialmente estaba activo pasará a ser inactivo y permitirá que al llenarse el grupo actual se escriban las transacciones en él.

Si se llenara el grupo actual de los archivos de redo y el resto de los grupos se encontraran activos, la base de datos no permitiría ninguna transacción hasta que se escriban todas las transacciones a disco del siguiente grupo de redo log y que este quedase inactivo. Cuando se trabaja con una base de datos en modo ARCHIVELOG, antes de sobrescribir el archivo se hace una copia de ese grupo de redo log al destino de los archivos.

Checkpoint Process (CKPT)

El CKPT lleva a cabo un checkpoint, entendiéndose como tal a la escritura parcial o completa de los buffers de memoria a disco. El CKPT no es el responsable de escribir los bloques a disco, para ello llama al DBWn y como en esa escritura podrían almacenarse en disco buffers de transacciones no comprometidas el CKPT también llama al LGWR para que registre en los redo log files esta escritura que permita generar los segmentos de undo de transacciones no comprometidas cuando se realice una recuperación incompleta. También si en la escritura del checkpoint hay transacciones que no se habían terminado de escribir en disco se escriben, se actualiza la cola de transacciones activas y un grupo de redo log que estaba activo podría pasar a inactivo.

Cuando un checkpoint ocurre, Oracle debe actualizar todas las cabeceras de los archivos de datos con los detalles del checkpoint, ésta es una tarea del CKPT.

System Monitor Process (SMON)

El proceso SMON lleva a cabo la recuperación, si es necesaria, de la instancia en el inicio de la misma, es decir rehacer cualquier transacción comprometida en el redo log file que no haya sido escrita a disco. SMON también es responsable de limpiar los segmentos temporales que no estén en uso por algún tiempo y de desfragmentar si cree oportuno alguna zona de los discos.

Process Monitor (PMON)

PMON lleva a cabo procesos de recuperación cuando un proceso de usuario falla. Es responsable de la limpieza del buffer caché, también de deshacer los cambios que se hayan hecho desde el ultimo commit y de la liberación de recursos que el proceso estaba usando. Por ejemplo este restaura el status de la tabla de transacciones activas, libera los locks y remueve el ID del proceso de la lista de procesos activos, asociados a un proceso usuario que pudo haber perdido la conexión de red.

Recoverer (RECO)

Este proceso solo se observa cuando la base de datos ejecuta la opción distribuida de Oracle. La transacción distribuida es una en la que dos o más emplazamientos de datos deben mantenerse sincronizados, Por ejemplo cuando se tiene una copia de los datos en diferentes ciudades y por fallas en una línea telefónica se pierde una transacción en la mitad de su actualización. El proceso recuperador entonces resuelve las transacciones que hayan quedado inconsistentes en las dos ciudades.

Archiver Processes (ARCn)

El ARCn copia los archivos de redo log llenos a un espacio de almacenamiento distinto para no perderlos al ser sobreescritos. El ARCn sólo está habilitado cuando la base de datos está en el modo ARCHIVELOG. En Oracle 10g para colocar la base de datos en modo archive basta con colocarla en modo ARCHIVELOG y especificar los destinos de "archive". En Oracle 9i se distinguía entre el "archive" manual y automático. Con "archive" manual el DBA debía ordenar hacer la copia de los redo log a los "archives", en el modo automático se copiaban automáticamente antes de ser sobrescritos. En Oracle 10g al poner una base de datos en modo ARCHIVELOG automáticamente se coloca en el modo automático.

Lock (LCKn)

Es un proceso opcional, configurado para manejar los bloqueos entre bases de datos Oracle cuando estas se encuentran en distintos computadores y compartiendo el mismo conjunto de discos (es decir en modo servidor en paralelo).

Job Queue (SNPn)

Es un proceso opcional, que se encarga de planificar los procesos que se deben ejecutar y asegurar que todos deben de terminar en algún momento.

Queue Monitor (QMNn)

QMNn es un proceso opcional de background para el encolamiento avanzado de Oracle, que monitorea las colas de mensajes. El encolamiento avanzado se usa con comunicación asíncrona. Los procesos envían los mensajes y en lugar de esperar por la respuesta siguen con su trabajo.

Dispatcher (Dnnn)

Es un proceso opcional que permite a los usuarios compartir procesos de servidor. Permitiendo que se conecten múltiples usuarios al mismo servidor.

Shared Server (Snnn)

Este tipo proceso se encarga de atender a cada uno de los clientes conectados a la base de datos compartiendo los procesos del servidor.