Una base de datos en ejecucin consta de 3 cosas: Archivos Control (ctl): almacenan informacin acerca de la estructura de archivos de la base. Rollback (rbs): cuando se modifica el valor de alguna tupla en una transaccin, los valores nuevos y anteriores se almacenan en un archivo, de modo que si ocurre algn error, se puede regresar (rollback) a un estado anterior. Redo (rdo): bitcora de toda transaccin, en muchos dbms incluye todo tipo de consulta incluyendo aquellas que no modifican los datos. Datos (dbf): el tipo ms comn, almacena la informacin que es accesada en la base de datos. Indices (dbf) (dbi): archivos hermanos de los datos para acceso rpido. Temp (tmp): localidades en disco dedicadas a operaciones de ordenamiento o alguna actividad particular que requiera espacio temporal adicional. Memoria Shared Global Area (SGA): es el rea ms grande de memoria y quizs el ms importante Shared Pool: es una cach que mejora el rendimiento ya que almacena parte del diccionario de datos y el parsing de algunas consultas en SQL Redo Log Buffer: contiene un registro de todas las transacciones dentro de la base, las cuales se almacenan en el respectivo archivo de Redo y en caso de siniestro se vuelven a ejecutar aquellos cambios que an no se hayan reflejado en el archivo de datos (commit). Large Pool: espacio adicional, generalmente usado en casos de multithreading y esclavos de I/O. Java Pool: usado principalmente para almacenar objetos Java Program Global Area (PGA): informacin del estado de cursores/apuntadores User Global Area(UGA): informacin de sesin, espacio de stack

Procesos Threading System Monitor: despierta peridicamente y realiza algunas actividades entre las que se encuentran la recuperacin de errores, recuperacin de espacio libre en tablespaces y en segmentos temporales. Process Monitor: limpia aquellos procesos que el usuario termina de manera anormal, verificando consistencias, liberacin de recursos, bloqueos. Database Writer: escribe bloques de datos modificados del buffer al disco, aquellas transacciones que llegan a un estado de commit. Log Writer: escribe todo lo que se encuentra en el redo log buffer hacia el redo file Checkpoint: sincroniza todo lo que se tenga en memoria, con sus correspondientes archivos en disco

SGADatabase Buffer Cache: En esta parte de memoria se almacenan imgenes de los bloques de datos fsicos (de disco) utilizados para realizar consultas o que han sido modificados por una sentencia. Siempre que un proceso necesite una determinada informacin buscar dichos datos en el Database Buffer Cache. Si encuentra la informacin aqu podr leer los datos directamente desde memoria (cache hit). Si por lo contrario, el proceso no encuentra la informacin solicitada en el buffer, tendr que hacer un acceso a disco y traerse los bloques de datos necesarios a memoria. (cache miss). Cuando Oracle modifica los datos, lo hace directamente sobre el Database Buffer Cache. Estos bloques modificados se denominan bloques sucios o Dirty Blocks. La actualizacin de los bloques en el Database Buffer Cache se realiza por el algoritmo LRU.Redo Log Buffer: El Redo Log Buffer se podra definir como una bitcora. Esta parte de la memoria acta como un buffer circular y es donde se registrarn todos los cambios que se produzcan en la base de datos, entendiendo por cambios la ejecucin de las sentenciasDML(Insert,Update,Delete,Merge) y DDL (Create,Alter,Drop, Truncate). Estas entradas de redo se almacenarn por si fuese necesario una recuperacin de la base de datos. Segn los procesos vayan haciendo cambios, se irn generando nuevas entradas de redo que se irn escribiendo en la SGA. Estas entradas se irn almacenando de forma secuencial en el buffer y ser el proceso de background Log Writer (LGWR) el que se encargar de escribir esta informacin en el fichero fsico de log de redo.Shared Pool: El rea de memoria que comprende la Shared Pool contiene la library cache, el data dictionary cache y el result cache.El data dictionary cache es una especie de metadatos de la base de datos, es en definitiva una coleccin de tablas y vistas que contienen informacin de la base de datos, sus estructuras y sus usuarios. Es una zona bastante accedida de la base de datos.Otra rea es la library cache. Es sin duda otra zona bastante concurrida de la base de datos. Oracle representa cada sentencia SQL que se ejecuta con una zona SQL compartida, con lo que Oracle es capaz de reconocer cuando 2 usuarios ejecutan la misma sentencia, y as poder reutilizar la misma rea para ambos usuarios. Esta zona de memoria compartida contiene el plan de ejecucin, con lo que Oracle ahorra memoria utilizando la misma rea para las sentencias que se ejecutan en mltiples ocasiones.En la result cache se almacenan filas y no bloques. En este rea por ejemplo podemos guardar listas de valores muy utilizadas. Para ello tendremos que definir un tipo de Hint especial en nuestras consultas que hagan que los resultados obtenidos se almacenen en esta cache.Large Pool: Esta zona es opcional. El administrador del sistema puede configurarla siempre que quiera reservar memoria para realizar operaciones de backup o recuperacin de la base de datos o consultas en paralelo.Java Pool: Esta zona se utiliza para almacenar cdigo Java almacenado y datos de laJVM. Es a partir de laversin 8ide Oracle a partir de la cual tenemos disponible esta caracterstica.Stream Pool: Zona de memoria utilizada para almacenarOracle Streams. Normalmente se usa en la configuracin deData Guards(Replicaciones de datos, donde a partir de este buffer se ir enviando datos a una base de datos secundaria). A menos que se haya configurado, el tamao de esta zona de memoria ser de 0 kb.Keep, Recyble Pools: Estas zonas de memorias son similares a la Database Buffer Cache, pero se difieren en que son diseados para mantener la informacin ms o menos tiempo de lo que la retendra el algoritmo LRU.Con la infraestructura dinmica de la SGA, el tamao de los buffers puede ser alterado sin parar la base de datos. La base de datos utiliza una serie de parmetros de inicializacin para crear y manejar las estructuras de memoria. La manera ms simple de controlar la memoria de la base de datos es dejar a la base de datos que lo haga de forma automtica. Para conseguirlo, lo nico que tendremos que hacer es establecer 2 parmetros de configuracin: MEMORY_TARGET y MEMORY_MAX_TARGET.PGALaProgram Global Area, es una regin privada de memoria que contiene datos e informacin de control de los procesos del servidor. Cada proceso tiene su propiaPGA, y el acceso a dicha informacin es totalmente exclusivo.En un servidor dedicado, cada proceso tendr un espacio de pila y una zona denominadaUser Global Area(UGA). En un servidor compartido, en el cual mltiples usuarios comparten el mismo proceso servidor, ste solo tendr el espacio de pila, mientras que la UGA se almacenar en la SGA.En laUGAnos encontraremos con la siguiente informacin: Cursores abiertos Informacin de la sesin (quien eres, el rol que tienes) reas de trabajo SQL: Consistentes en la realizacin de varias operaciones SQL, como la ordenacin de las consultas (ORDER BY,GROUP BY). En este ejemplo, en el caso de no haber suficiente espacio para llevar a cabo dicha operacin esta informacin ser llevada a disco

Si bien el otro da hablaba sobre laarquitectura de una base de datos Oracle, solo tratamos en profundidad la arquitectura de la memoria. Hoy tratar de explicaros la arquitectura de los procesos. En primer lugar vamos a establecer una agrupacin de los procesos en 3 grupos: Procesos de Usuario: Aplicacin o herramienta que se conecta con la base de datos de Oracle Procesos de Base de Datos: Donde nos podemos encontrar con los procesos servidores (aquellos que conectan las aplicaciones con las instancias de base de datos y que se ejecutan cuando se establece una conexin) y con los procesos de Background (Comienzan cuando se arranca una instancia). Demonios: Listeners y GridCuando un usuario ejecuta una aplicacin, como pudiera ser el SQL *Plus o el PL/SQL Developer, est haciendo correr lo que se denomina un proceso de usuario. Este proceso que puede estar o no en la misma mquina donde se encuentra la base de datos se conectar en primer lugar a unListenerel cual crear un proceso servidor que ser el encargado de ejecutar los comandos indicados por el proceso de usuario. Adems de estos procesos,Oraclecuenta con una serie de procesos, llamados procesos de background que pertenecen a cada instancia, los cuales interactan entre ellos y con el sistema operativo para manejar las estructuras de memoria, escribir informacin en disco, y realizar otro tipo de tareas como veremos ms adelante.Losprocesos servidores son los encargados de realizar las siguientes tareas: Analizar y ejecutar sentecias SQL transmitidas por el proceso de usuario. Se encarga de buscar en laDatabase Buffer Cache(SGA) los bloques necesarios, o de recuperarlos de los data files (de disco) si no se encuentran en el buffer. Devolver al proceso la informacin solicitada.En cuanto a los procesos de background, nos podemos encontrar con los siguientes: Database write process (DBWn): Se encarga de escribir los bloques sucios del Database Buffer Cache a disco. Log writer process (LGWR): Se encarga de transferir la informacin del Redo Log Cache a los ficheros fsicos de REDO. Checkpoint process (CKPT): Sincroniza el fichero de control con las cabeceras de los data files. System monitor process (SMON): Es el monitor del sistema. Monitoriza el sistema, recupera la instancia si fuera necesario. Process monitor process (PMON): Es el monitor de procesos. Controla las sesiones, mata las sesiones que considera, y se encarga del registro dinmico del Listener.