Una primera y sencilla aproximación a la arquitectura general utilizada por el RDBMS ORACLE para el manejo de base de datos (independientemente de la configuración single, multi-thread, parallel- utilizada) es la mostrada en la siguiente figura.
Esta arquitectura puede ser divida en dos porciones lógicas:
- estructura de procesos y memoria
- estructura para el manejo de los datos
Estructura de procesos y memoria.
Independientemente de la arquitectura computacional, o de su configuración, cada base de datos dentro del RDBMS ORACLE es asociada a una determinada instancia, y de igual forma una instancia puede abrir y utilizar sólo una base datos ORACLE en cualquier momento de su ejecución. Es posible poseer múltiples instancias ejecutándose concurrentemente dentro de una misma máquina, cada una accediendo su propio espacio físico de datos (su base de datos ORACLE). En el sistema de operación, la variable de entorno ORACLE_SID permite identificar el nombre de la instancia ORACLE a la cual se conectarán, por defecto, las aplicaciones de usuario.
Cada vez que el RDBMS ORACLE es inicializado, tanto el System Global Area (SGA) como los procesos demonios son levantados. El SGA junto con los procesos demonios es lo que se demonina como una instancia ORACLE.
La memoria en Oracle
El System Global Area es un conjunto de estructuras de memoria compartida que contienen datos e información de control para una determinada instancia ORACLE. El SGA se mantiene en la memoria virtual del computador en el que reside la instancia ORACLE. Si dentro de la instancia existe la posibilidad de que más de un usuario se encuentren conectados simultáneamente, los datos dentro del SGA de la instancia son compartidos entre todos los usuarios. Es por esto que algunas veces al SGA también se le suele denominar Shared Global
Area. La estructura interna de la SGA de un RDBMS shared server puede observarse en esta figura:
Veamos que es lo que hace cada componente:
Buffer Cache (o Database Buffer Cache) :
El Buffer Cache está organizado en dos listas: la lista de bloques sucios (dirty buffers) y la lista de los más recientemente usados (= L.R.U. last recent used ). La lista de sucios almacena los bloques sucios, que contienen datos que han sido modificados pero que no han sido escrito todavía a disco. La lista LRU mantiene los buffers libres (no modificados y disponibles), los reservados (pinned buffers) que son lo que actualmente son accedidos y los bloques sucios que todavía no han sido escritos a disco. El número de bloques manejados por el Buffer Cache puede ser configurado para mejorar el rendimiento, así como el tamaño del bloque de
datos. En cualquier caso el tamaño de bloque de datos utilizado debe ser el mismo que el que se ha configurado para la instancia como tamaño de bloque de datos utilizado por el RDBMS. No obstante se pueden crear cachés adicionales con tamaños de bloque diferentes (2Kb, 4K, 8Kb, 16Kb ó 32Kb) para que sean usados con tablespaces con un tamaño de bloque diferente. Los parámetros para estas subcachés son del tipo DB_nK_CACHE_SIZE, siendo n uno de los cinco valores indicados antes.
Redo Log Buffer:
en los bloques de datos producidos por transacciones diferentes. El tamaño de este Buffer también puede ser configurado para mejorar el rendimiento de la instancia y de las aplicaciones que sobre ellas se ejecutan.
Shared Pool:
Library Cache
- Texto de la instrucción.
- Árbol de parseo, es decir la versión compilada de la instrucción.
- Plan de Ejecución, es decir la secuencia de pasos a ser realizados para ejecutar la instrucción a bajo nivel de acuerdo con los resultados producidos por el optimizador de consultas. Basándose en esta información, si una consulta es ejecutada nuevamente, y su información permanece todavía en el Library Cache, no será necesario compilar de nuevo la instrucción. En tal sentido este componente de la arquitectura permite mejorar el rendimiento de las aplicaciones que se ejecutan periódicamente.
Data Dictionary Cache
Request Queue y Response Queue:
las acciones necesarias para que la base de datos complete la solicitud y colocarán la petición en la Response Queue asociada al proceso que atendió la solicitud.
Los procesos en Oracle
Los procesos de ORACLE realizan funciones para los usuarios del manejador. En general se puede establecer una partición en los procesos de ORACLE:
- Procesos Servidores (o Shadow Proceses), los cuales ejecutan funciones de interacción con el servidor de datos basándose en las peticiones de los usuarios.
- Procesos Demonio (o Background Proceses), quienes realizan funciones para el RDBMS como un todo.
- Procesos de Red, encargados de proveer la interconexión entre procesos de usuario y el RDBMS o entre RDBMS que establecen un sistema de bases de datos distribuidas.
Procesos Servidores y el Program Global Area (PGA)
Los procesos servidores (Snnn) se comunican con los diferentes procesos de usuario e interactúan con ORACLE para satisfacer las peticiones. Por ejemplo, cuando un proceso de usuario solicita datos que no se encuentran en el SGA (en alguno de los buffer caches, dependiendo del tipo de operación y de la fase de su procesamiento), el proceso servidor que atiende la petición será el encargado de leer los bloques de datos y almacenarlos en el SGA (recuerde que el SGA en un área de memoria compartida). Puede existir una correspondencia de uno a uno entre procesos de usuario y procesos servidor (por ejemplo en la configuración de RDBMS dedicado); aunque un proceso servidor puede conectarse a múltiples procesos de
usuario (como en la configuración de RDBMS multi-threaded). Las conexiones admitidas dependerán en todo momento de la configuración de opciones del RDBMS realizadas durante la instalación del mismo. El PGA constituye una región de memoria asociada a cada proceso servidor, la cual contiene datos e información de control para cada una de las sesiones que los usuarios mantienen con el RDBMS ORACLE a través de éste proceso servidor. Por lo tanto el PGA no es un área de memoria compartida. Una región de memoria para almacenar un PGA es solicitada cuando un proceso usuario establece una sesión de trabajo con el manejador de datos. El tipo de información que se almacena en el PGA depende de las opciones instaladas para el servidor ORACLE. Por ejemplo, cuando se utiliza una configuración de servidor dedicado, el PGA contiene los siguientes componentes:
- Sort Area, que es utilizada para llevar a cabo los posibles ordenamientos de filas requeridos antes de que las filas sean procesadas o devueltas al usuario como resultado de una consulta.
- Stack Space, el cual contiene las variables de sesión de usuario y sus valores.
- Cursor State, el cual almacena el estado de los diferentes cursores que están siendo utilizados en la sesión del usuario.
- Session I nformation, la cual mantiene información sobre los privilegios que el usuario que ejecuta la sesión.
Ejemplo: Cada vez que se invoca SQL*Plus, se crear un proceso usuario. Este proceso usuario se comunicará (bien sea por los mecanismos de IPC en caso de que el servidor ORACLE y el proceso usuario estén en la misma máquina- o por mecanismos de software de comunicación en Red como SQL*Net en caso de que el servidor ORACLE y el proceso usuario estén en máquinas diferentes) con el proceso servidor que le proveerá del acceso necesario al servidor ORACLE.
Procesos Demonios
Los procesos demonio, también conocidos como Background Proceses, constituyen programas que llevan a cabo funciones específicas de soporte y mantenimiento a la ejecución del servidor de bases de datos. Esto no quiere decir que sean opcionales, por el contrario sin ellos no se podría operar correctamente en un entorno basado en ORACLE. Estos procesos pueden ser observados en esta figura:
Database Writer (DBWR) :
Si el entorno no posee AIO, el rendimiento del sistema puede ser mejorado agregando más procesos DBWR.
Log Writer (LGWR) :
- Cuando el Redo Log Buffer está lleno en un 33% o más.
- Cuando ocurre un timeout (cada 3 segundos).
- Antes de que el DBWR escriba algún bloque modificado a disco.
- Cuando una transacción se confirme (= COMMIT ).
Checkpoint (CKPT) :
System Monitor (SMON) :
Process Monitor (PMON) :
Archiver (ARCH) :
Recoverer (RECO) :
Dispatcher (Dnnn) :
Control de Recursos
ORACLE administra el uso de los diferentes recursos que gestiona a través de latches . Un latch es un cerrojo o semáforo mantenido por la instancia de ORACLE que permite administrar una cierta actividad. Los latches limitan la cantidad de tiempo y espacio en los que un proceso puede mantener un recurso en un instante dado. De igual forma, los latches son utilizados para garantizar el acceso exclusivo a un recurso. El monitoreo de latches permite determinar situaciones en la que se crea contención por el acceso a un recurso. El número de latches existentes depende de la configuración y la información de los latches definidos y manejados por la instancia puede ser extraída del diccionario de datos.
Estructura Física para el Manejo de Datos
Una base de datos ORACLE, identificada por un nombre lógico mantenido en la variable de entorno DB_NAME, representa las estructuras físicas y está compuesta de archivos del sistema de operación. Aunque es posible utilizar un nombre de base de datos diferente al del nombre de la instancia, se recomienda utilizar el mismo nombre para hacer más sencilla la administración. Los archivos que conforman la base de datos contienen los datos del usuario e información adicional que es necesaria para garantizar el funcionamiento de la base de datos. Una base de datos ORACLE consiste de los siguientes tipos de archivos:
Archivos de datos (Data Files) :
Archivos de bitácora (Redo Log Files o Redo Log) :
Archivos de Control (Control Files) :
Estructura Lógica de Almacenamiento
ORACLE es el encargado de manejar el espacio donde van a ser almacenados todos los objetos de una base de datos. Las unidades lógicas de almacenamiento son: bloques de datos, extents, segmentos y tablespaces. La siguiente figura muestra la relación existente entre estas estructuras de datos:
Tablespaces:
Los tablespaces pueden estar constituidos de varios archivos de datos. Al utilizar más de un archivo de datos por tablespace pueden distribuirse los datos sobre varios discos y balancear la carga de E/S, mejorando así el rendimiento del sistema. Como parte del proceso de crear la base de datos, ORACLE automáticamente crea un tablespace llamado SYSTEM. Aunque sólo una base de datos pequeña puede ser almacenada en SYSTEM, es recomendable que se cree uno (o varios) tablespace(s) para los datos del usuario. El tablespace SYSTEM almacena los datos del diccionario. Los Archivos de datos pueden ser archivos del sistema de operación, y en algunos sistemas de operación se permite que un archivo de datos sea un dispositivo de almacenamiento secundario crudo (o parte de él).
Segmentos:
- de datos:
- de índice:
base de datos
- de Rollback:
- temporales:
Extents:
Bloques de Datos:
El Diccionario de Datos de ORACLE
El diccionario de datos es una parte fundamental de toda base de datos ORACLE. El diccionario de datos de ORACLE está constituido por una serie de tablas, vistas y ORACLE packages a los que puede accederse para obtener información sobre la base de datos. Las tablas del diccionario de datos son creadas automáticamente durante el proceso de instalación de ORACLE y permiten al administrador conocer, entre otros:
- La estructura lógica y física de la base de datos
- Los usuarios de la base de datos
- Las restricciones de integridad definidas sobre las tablas de la base de datos
- El espacio asociado a cada objeto en la base de datos y cuánto de este espacio está siendo realmente utilizado por los diferentes objetos creados por los usuarios de la base de datos
ORACLE predefine un usuario dueño de todo el diccionario de datos denominado SYS. Este usuario tiene todos los permisos sobre cualquier objeto de la base de datos (incluidos los objetos de cualquier usuario). Debido a que este usuario puede modificar entradas del diccionario de datos es recomendable no utilizarlo ya que cualquier error generado sobre el diccionario de datos puede provocar errores irrecuperables en el RDBMS. Sólo se deberá hacer uso cuando se requiera efectuar modificaciones CONTROLADAS sobre el diccionario para reparar errores en el mismo (cirugía de la base de datos). Sus componentes son:
Tablas Base:
Vistas Estáticas:
Estas vistas se dividen en tres categorías de acuerdo con el prefijo de sus nombres:
- Vistas con prefijo USER:
SELECT * FROM USER_TABLES;
Se desplegará toda la información de aquellas tablas cuyo dueño sea el usuario ci531301.
- Vistas con prefijo ALL:
- Vistas con prefijo DBA:
Vistas Dinámicas
Todas las vistas dinámicas se identifican por poseer el prefijo V$. Por ejemplo la vista dinámica V$_SESSION incluye información sobre las sesiones actuales y la vista V$SYSSTAT provee información estadística sobre el RDBMS. Para obtener información general sobre las vistas del diccionario de datos puede usarse la consulta:
SELECT * FROM DICTIONARY WHERE table_name LIKE ´%indicador%´;
Por ejemplo, para ver todas las vistas relacionadas con tablas podríamos ejecutar la instrucción SQL:
SELECT * FROM DICTIONARY WHERE table_name LIKE ´%TABLE%´;
En el manual ORACLE9i Reference se dispone de toda la información detallada de las vistas estáticas y dinámicas que provee el RDBMS.
Introducción a la arquitectura de Oracle
No hay comentarios:
Publicar un comentario