SISTEMA GESTOR DE ORACLE...2
Funcionamiento General...2
Estructura de Física de la Base de Datos, ficheros...6
Estructura de Lógica de la Base de Datos. Tablespaces, segmentos y objetos...14
Estructura de Memoria...25
Estructura de Procesos...29
Usuarios, Seguridad de Acceso...35
SISTEMA GESTOR DE ORACLE
En éste capítulo se verá, a modo de ejemplo, el funcionamiento del Sistema Gestor de Base de Datos de ORACLE, uno de los SGBDR más utilizados en el mundo de las grandes empresas. Si el lector quiere introducirse en los por menores de éste, es necesaria la consulta con el manual apropiado que ORACLE proporciona a tal efecto. Nosotros presentaremos dicho funcionamiento a grandes rasgos para que este pueda concebir el sistema genérico utilizado por un SGBD.
Funcionamiento General
El sistema gestor de Base de Datos de ORACLE puede ser configurado para dar el servicio de manera más eficiente según sea la configuración que éste tome. La figura 1 ilustra el funcionamiento general del SGBD de ORACLE.
Una Base de Datos ORACLE es una colección de datos tratados todos ellos como una unidad. Una Base de Datos que está formada por diversos tipos de ficheros dentro de un sistema operativo. Físicamente, trataremos la Base de Datos como un conjunto de ficheros de base de datos y ficheros de traza. Lógicamente, la veremos como un conjunto de diccionarios, tablas de usuarios y ficheros de traza conteniendo datos de recuperación de errores. Adicionalmente, una Base de datos requiere uno o más ficheros de control. Ellos contienen aquella información que identifica y describe el resto de la Base de Datos.
El funcionamiento del SGBD pasa por la definición de una instancia ORACLE [fig.2]. Una instancia consiste, básicamente en:
- Una área de memoria (llamada Area Global del Sistema, SGA) que permita una comunicación entre los procesos,
- Al menos cinco procesos en background (SMON, PMON, DBWR, LGWR y ARCH) utilizados por los usuarios de ORACLE.
FICHEROS DE TRAZA OFF-LINE FICHEROS DE TRAZA ON-LINE BASE DE DATOS Fichero de Traza Activo Segm ento de Rollback Segm ento de Datos Procesos LGW R ARCH SMON PMON DBWR USUARIO_ 1
AREA GLOBA L DEL SISTEMA (SGA ) Búffer Base Búffer Redo PGA Areas de contexto
Figura 1. Funcionamiento General del SGBDR ORACLE.
Cada una de las instancias necesita del acceso al código ejecutable que ORACLE proporciona, aunque éste código puede ser compartido por cada una de las instancias. Una Base de Datos puede ser accedida por múltiples instancias simultáneamente, por ello podemos decir que ORACLE es un sistema compartido. La figura 3 muestra como se produce el acceso de dos instancias a la Base de Datos.
Buffers Ficheros
Estructuras de la Base de Datos Estructura de Usuarios
Estructuras de memoria Estructuras de Procesos
AREA GLOBAL DEL SISTEMA (SGA)
Buffers Ficheros B.D.
CODIGO EJECUTABLE ORACLE
USU_N USU_3 USU_1 FICHEROS DE BASE DE DATOS FICHEROS TRAZA FICHEROS CONTROL USU_2 ARCH LGWR DBWR SMON PMON
Figura 2. Relación de las Estructuras de ORACLE.
Veremos el funcionamiento de ORACLE a partir de cada uno de los componentes que lo componen, es decir, la estructura física de fichero y la lógica de tablas, la estructura de procesos y la estructura de memoria.
SGA SGA INSTANCIA B INSTANCIA A A R C H L G W R P M O N S M O N D B W R A R C H L G W R P M O N S M O N D B W R FICHEROS DE CONTROL FICHEROS TRAZA FICHEROS DE BASE DE DATOS
Estructura de Física de la Base de Datos, ficheros.
En éste capítulo veremos los ficheros necesarios para ejecutar el producto ORACLE. Estos están agrupados en diferentes tipos según el uso interno y la utilización que a cada uno de ellos se les da. Por ello éstos serán agrupados según la función que desempeñen:
- Ficheros de Programas de ORACLE - Ficheros de Base de Datos
- Ficheros de Control - Ficheros de Traza
Obviamente, será sólo el Administrador de la Base de Datos a quien le concernirá la información incluida en los ficheros especificados anteriormente. Los usuarios de la Base de Datos raramente necesitarán saber la información existente en éstos, a ellos les concierne la información ‘lógica’ que de ellos se extrae, es decir los objetos de la Base de Datos que éstos representan.
La figura 4 ilustra el número de ficheros mínimo que requiere ORACLE para su funcionamiento:
Tipo de Ficheros Número Tamaño aproximado
F. de Base de Datos 1 500 Kb.
F. de Traza 2 50 Kb.
F. de Control 1 Según tipo de Instalación
Programas ORACLE Muchos aprox 17400 Kb. (según instalación)
Figura 4. Número Mínimo de Ficheros por tipos
Estructuras Físicas, Estructuras Lógicas
Una estructura física es aquella que está almacenada de una manera tangible en un medio hardware (un disco, una cinta magnética, un disquete, etc.). De ésta manera, un fichero corresponde a un área reservada de espacio por el sistema operativo para almacenar una determinada información. Dicho fichero, de alguna manera es tangible ya que existe de una manera física en un medio tangible.
una unidad de espacio, sus límites son independientes de su localización física. Una tabla puede ser almacenada a lo largo de varios ficheros de bases de datos físicos.
Ficheros de Programas de ORACLE
Entre éste tipo de ficheros encontramos aquellos que son propios de la instalación del producto ORACLE. Dependiendo del tipo de instalación, variará el número de éste tipo de ficheros, así con el espacio requerido por éstos. De ésta manera, tendremos ficheros ejecutables, ficheros de comandos y librerías de objetos, todos ellos formando parte de los llamados ficheros de programa.
Obviamente, es necesaria su conservación ya que de su existencia depende la ejecución correcta del producto.
Ficheros de Bases de Datos
Una Base de Datos ORACLE está formada por uno o más ficheros de base de datos. Estos contienen todos los datos de la Base de Datos y se caracterizan porque:
- Cada fichero está asociado solamente a una Base de Datos.
- Una fichero físico forma una unidad lógica de la Base de Datos llamada
tablespace. Cada tablespace puede estar formado por varios ficheros de base de
datos, aunque éstos solamente pueden estar relacionados con un tablespace. Dada su importancia, nos extenderemos en los tablespaces en posteriores capítulos.
- Todos los ficheros de base de datos de tablespaces on-line deben ser accesibles al arrancar ORACLE RDBMS.
- Aunque no es necesario que el espacio asignado a un fichero de base de datos sea contiguo, sí que es aconsejable para una mejor accesibilidad.
- Una vez creado, un fichero de base de datos no cambiará de tamaño.
El número de ficheros de base de datos variará en función de las necesidades de espacio de nuestros aplicativos y del incremento realizado al ampliar dicho espacio requerido. Siempre será obligatorio tener definido un fichero de base de datos asociado al tablespace SYSTEM. Este almacenará información del diccionario de datos y del segmento de rollback iniciales. El parámetro MAXDATAFILES del comando CREATE DATABASE marcará el número máximo de ficheros. Si éste no es precisado, lo marcará el parámetro DB_FILES del fichero INIT.ORA, fichero propio del producto ORACLE.
Las lecturas/escrituras de los ficheros de bases de datos realizadas por el sistema operativo vendrán determinadas por el llamado tamaño de bloque. Este viene definido por
el parámetro DB_BLOCK_SIZE del fichero CONFIG.ORA. Normalmente suele tener un tamaño de 4Kb.
Ficheros de base de datos on-line y off-line
Mediante la instrucción ALTER TABLESPACE conseguiremos cambiar un tablespace en modo on-line a off-line y viceversa. Un tablespace on-line indica que las tablas que éste contiene son accesibles por el gestor de ORACLE. Un tablespace off-line será aquel que por cualquier razón esté desactivado.
De esta manera, diremos que los ficheros asociados a un tablespace están on-line si el tablespace lo está y estarán off-line si el tablespace del que dependen está off-line.
Creación y eliminación de un fichero de base de datos
Las instrucciones CREATE DATABASE y CREATE TABLESPACE ... DATAFILE ... permiten crear los ficheros de base de datos, definiendo el tamaño asignado a éstos. Una vez se ha alcanzado el máximo de dicho espacio, es posible definir un nuevo fichero de base de datos asociándolo a un tablespace existente mediante la instrucción ALTER TABLESPACE ... ADD DATAFILE.
Mediante la instrucción DROP TABLESPACE conseguiremos borrar un tablespace del sistema. Para ello deberemos asegurarnos que anteriormente esté off-line. Seguidamente podremos eliminar los ficheros asociados al tablespace utilizando los comandos de sistema operativo correspondientes.
Ficheros de Control
Los ficheros de control son pequeños ficheros binarios asociados a una Base de Datos que son chequeados cada vez que la Base de Datos de ORACLE se abre. Los ficheros de control se crean durante la instalación del producto ORACLE y deben ser siempre accesibles cada vez que sea arrancada la Base de Datos.
Deberemos saber, pues, cuántos ficheros de control mantener, y en qué dispositivo colocarlos. Un fichero de control contiene información sobre la manera de acceder a la Base de Datos asociada. Por ello contiene información tal como:
- Nombre físico de la Base de Datos y de los ficheros de traza, - Fecha y hora de creación de la Base de Datos,
que éste sea editado por un operador cada vez que se produzca un cambio en su información. Es recomendable realizar copias de los ficheros de control en diferentes dispositivos para evitar el riesgo de fallo en un dispositivo, aunque sea tedioso el posterior mantenimiento de éstos.
El nombre del fichero de control asociado a una Base de Datos está indicado en el fichero INIT.ORA mediante el parámetro CONTROL_FILE. Este indica una lista de uno o más nombres de ficheros de control. Es posible cambiar la lista para añadir o cambiar la localización los ficheros de control siempre que la base de datos esté abajo. Para crear un nuevo fichero de control, deberemos copiar un fichero de control existente en uno nuevo y seguidamente añadirlo a la lista de ficheros de control. Para llevar a efecto dicho cambio, deberemos llevar abajo la Base de Datos (shutdown) y volverla a encender (startup). El tamaño de un fichero de control suele tener pequeñas dimensiones. Éste viene determinado por los parámetros DB_FILES y LOG_FILES del fichero de configuración INIT.ORA.
Ficheros de Traza
Las trazas están compuestas por un conjunto de ficheros (llamados ficheros de
traza) externos a la Base de Datos que almacenan los cambios hechos durante cada una de
las transacciones contra la Base de Datos. Existen dos tipos de ficheros de traza: los
ficheros de traza on-line y ficheros de traza off-line.
Los primeros almacenan los cambios realizados por transacciones cada vez que se produce un COMMIT en éstas. Gracias a éstos, es posible recuperar el estado de la Base de Datos después de que se haya producido un error en ésta. El proceso encargado de escribir las trazas en éste fichero, denominado LGWR, debe tener acceso a dichos ficheros de traza, ya que de otra manera, ORACLE RDBMS desmontaría la Base de Datos. Cada Base de Datos debe tener al menos dos ficheros de traza activos on-line.
El uso de los archivos de traza off-line es opcional, estos son copias de los primeros realizadas en otro dispositivo físico. Para archivar los ficheros de traza, debe operarse el ORACLE en modo Archivelog. Tanto los primeros como los segundos serán utilizados en caso de error en la Base de Datos.
El uso de los ficheros de traza se debe a que el proceso encargado de escribir los cambios en la Base de Datos, DBWR, no sincroniza dichos cambios producidos por un COMMIT con escrituras físicas en los ficheros de bases de datos (vistos anteriormente). Estos quedan en un búffer de operaciones de escritura a la Base de Datos. Los ficheros de traza se utilizan básicamente para asegurar que éstos cambios se lleven a efectos. De ésta manera se pueden llevar a cabo la vuelta atrás para aquellas transacciones terminadas en ROLLBACK.
Los ficheros de traza son utilizados para operaciones de vuelta atrás. Es decir, operaciones que mediante acceso a los ficheros de traza deben dejar la Base de Datos en un estado anterior al actual. Para éstas operaciones se utilizan los llamados segmentos de
rollback. Estos segmentos se corresponden con áreas de disco que contienen la información
necesaria para la vuelta atrás.
Ficheros de Traza On-Line
Los ficheros de traza on-line son formados por al menos parejas de dos ficheros. Éstos se crean en el momento de creación de la Base de Datos a los que automáticamente se asocian. Al ejecutar el comando CREATE DATABASE se especifican las siguientes acciones que afectan a los ficheros de traza on-line:
- Modo de operación de la Base de Datos, Archivelog o Noarchivelog. - Número de ficheros de traza on-line a utilizar,
- El tamaño de éstos,
- Lugar en donde serán creados los ficheros de traza on-line.
Los ficheros de traza on-line son una parte esencial del producto ORACLE. Estos contienen la manera en que se produjeron cada una de las grabaciones de cada una de las transacciones de datos realizadas en la Base de Datos asociada. Así, un COMMIT realizado en la Base de Datos sólo se completará si se ha podido realizar una traza en el fichero de traza asociado. Por ello, los ficheros de traza son la única manera de recuperar la Base de Datos en caso de problemas.
El modo de funcionamiento de los ficheros de traza on-line se asemeja a un tiovivo. Es decir, cuando el proceso LGWR escribe sobre un fichero de traza on-line y llega hasta el final de éste, utiliza el siguiente fichero de traza on-line disponible. Cuando se completa el último fichero de traza disponible, el gestor de la Base de Datos ORACLE utilizará el primer fichero de traza on-line, completando y continuando la rueda de escrituras. Diremos que cada vez que ORACLE cambia de fichero de traza se produce un cambio de fichero de
F.TRAZA ON-LINE B F.TRAZA ON-LINE C F.TRAZA ON-LINE A
Figura 5. Escritura Circular para los Ficheros de Traza on-line.
Es posible numerar cada uno de los ficheros de traza on-line que forman el ciclo de escrituras visto anteriormente y marcar la secuencia en el que deben hacerse los cambios de
fichero de traza. Ello se consigue con el comando ARCHIVE LOG LIST.
Tanto el tamaño de cada fichero de traza, como el número de éstos dependerá de cada instalación de ORACLE, según las necesidades de cada sistema, para ello deberemos considerar los siguientes factores:
- Cuanto más grandes sean los ficheros de traza, mayor será la información de vuelta atrás almacenada.
- Cuanto mayores sean los ficheros de traza, menores serán los puntos de chequeo para realizar un cambio de fichero de traza.
- Cuanto mayor sea el número de ficheros de traza on-line utilizados, menor será el uso que hagamos de los ficheros de traza off-line, ya que implícitamente estamos haciendo un uso implícito de los ficheros de traza off-line.
- Cuanto menor sea un fichero de traza on-line menor será la información real que habremos perdido.
Ficheros de Traza Off-Line
Los ficheros de traza off-line son utilizados para proteger la Base de Datos contra los errores físicos que pueda sufrir el disco en la que se almacena. En importante, siempre que sea posible, almacenar los ficheros de base de datos y los ficheros de traza on-line en discos diferentes, pero no siempre es posible, por ello almacenaremos periódicamente los
ficheros de traza on-line en un medio diferente, convirtiendo los ficheros de traza on-line en ficheros de traza off-line copias de los primeros. Esta operación puede realizarse de manera automática o manualmente, aunque siempre estando la Base de Datos en modo ARCHIVELOG.
Puntos de Chequeo
Diremos que se produce un punto de chequeo siempre que sea necesaria la escritura de un número predeterminado de bloques de traza a disco. También se produce un punto de
chequeo siempre que se produzca un cambio de fichero de traza. Cada vez que se produce
un punto de chequeo, el proceso DBWR escribe todos los cambios existentes en el búffer del SGA desde el anterior punto de chequeo. Por ello, los puntos de chequeo aseguran la escritura de los bloques de traza a sus correspondientes ficheros de traza, así como los cambios que éstos provocan en la Base de Datos mediante la escritura a los correspondientes ficheros de base de datos.
Segmentos de Rollback
Los segmentos de Rollback son áreas de disco utilizadas para almacenar los cambios provocados en la Base de Datos, permitiendo la vuelta atrás de dichos cambios mediante la instrucción ROLLBACK. Representan aquella unidad lógica asociada a un fichero de traza. En la creación de un Segmento de Rollback se define aquel tablespace en donde se definirá éste. Como ya sabemos, los tablespaces están representados por uno o más ficheros de base de datos.
Al crear una Base de Datos, se crea por defecto el segmento de rollback del sistema. Es posible añadir cuantos segmentos de rollback sean necesarios. Para ello deberemos considerar los siguientes puntos:
- El espacio de la Base de Datos que dedicaremos a nuestros segmentos de rollback. - La media de transacciones que tenemos en nuestra Base de Datos de manera concurrente (para cada transacción deberemos prever un espacio en el segmento de rollback).
- La cantidad de espacio necesario para almacenar los cambios que éstas transacciones provocan. Normalmente, las transacciones asociadas a procesos batch utilizan mayor cantidad de espacio que las transacciones asociadas a procesos on-line.
- ¿ Es posible dividir las entradas de los segmentos de rollback en varios discos ? Por todo ello deberemos tener en cuenta la siguiente tabla, ella indica un número aproximado de segmentos de rollback a tener en cuenta para nuestras instalaciones:
Número de Transacciones concurrentes
Número de Segmentos de Rollback recomendado
menos de 16 4 segmentos
entre 16 y 32 8 segmentos
más de 32 nº transac / 4 (menor que 50)
Figura 6. Número de Segmentos de Rollback
Sea cual sea en número de segmentos de rollback escogido, es recomendable que todos ellos tengan un tamaño similar. Al igual que las tablas de datos (que veremos posteriormente), los segmentos de rollback se definen a partir de un tamaño inicial, que es incrementado en extensiones finitas una vez que se haya completado el espacio asignado. Por ello, nos aseguraremos que el tamaño total que sean capaces de cubrir nuestros segmentos de rollback sea siempre el espacio necesario que generen las transacciones concurrentes.
Estructura de Lógica de la Base de Datos. Tablespaces, segmentos y objetos
En éste punto trataremos la estructura lógica de la Base de Datos de ORACLE. Esta estructura está apoyada, obviamente, sobre la estructura de ficheros vista anteriormente, de la que depende.
La siguiente figura representa la relación entre cada uno de los componentes lógicos de la Base de Datos.
BASE DE DATOS BD
TABLESPACES TS_1 SYSTEM
OBJETOS:
Tablas, Indices, Vistas Tb_1 Tb_2 Tb_3 Ind_1 Ind_2 ... ... SEGMENTOS Dato Dato Dato Indice Indice ... ... EXTENSIONES
Figura 7. Estructura Lógica de la Base de Datos ORACLE
Base de Datos BASE DE DATOS
Tablespaces SYSTEM TBSPC_1
Objectos /home/oracle/dbs/fichero1.dbf /home/oracle/dbs/fichero2.dbf /home/oracle/dbs/fichero3.dbf
Espacio no ocupado en el fichero de base de datos (f. de b.d.)
Espacio ocupado por un objeto del Tablespace SYSTEM en el f. de b.d. .../dbs/fichero1.dbf Espacio ocupado por un objeto del Tablespace SYSTEM en el f. de b.d. .../dbs/fichero1.dbf Espacio ocupado por un objeto del Tablespace SYSTEM en el f. de b.d. .../dbs/fichero1.dbf Espacio ocupado por un objeto del Tablespace TBSPC_1 en el f. de b.d. .../dbs/fichero2.dbf Espacio ocupado por un objeto del Tablespace TBSPC_1 en el f. de b.d. .../dbs/fichero2.dbf Espacio ocupado por un objeto del Tablespace TBSPC_1 en el f. de b.d. .../dbs/fichero2.dbf Espacio ocupado por un objeto del Tablespace TBSPC_1 en el f. de b.d. .../dbs/fichero2.dbf Espacio ocupado por un objeto del Tablespace TBSPC_1 en el f. de b.d. .../dbs/fichero2.dbf
El SGDB de ORACLE es capaz de administrar cuantas Bases de Datos seamos capaces de definir en el sistema (dentro de unos límites lógicos, aunque normalmente tendremos definida una sola Base de Datos). Cada Bases de Datos estará dividida en una estructura lógica denominada tablespace. Veremos su utilidad en el ejemplo que a continuación se define. A su vez, cada tablespace contendrá, ahora sí, cada uno de los objetos que necesitemos definir y sobre los que nuestros aplicativos trabajarán, es decir cuantas tablas, índices, vistas, etc ... necesitemos para almacenar la información deseada. Cada uno de los tablespaces definidos estará asociado a un fichero de base de datos, que a su vez contendrá cada uno de los datos almacenados en las tablas lógicas que vemos.
La creación de dichos objetos físicos obliga a definir el tamaño inicial para este, un tamaño de extensión una vez se haya completado el tamaño inicial asignado y un número máximo de extensiones que puede alcanzar dicho objeto, para evitar un crecimiento descontrolado y una dispersión física del objeto lógico dentro del fichero de base de datos. La figura 8 muestra la manera en que quedan ligadas la estructura física y la lógica.
Tablespaces
Hemos visto anteriormente la estructura básica en que se compone una Base de Datos. Hemos visto que ésta se divide en unidades lógicas llamadas tablespaces. Una Base de Datos puede estar formada por uno o varios tablespaces, aunque siempre deberá existir el tablespace primario denominado SYSTEM. Un tablespace está asociado ineludiblemente a uno o más ficheros de base de datos (vistos anteriormente). Principalmente, los tablespaces son utilizados por el administrador de la Base de Datos para:
- Controlar el espacio que ocupan cada uno de los objetos de la base de datos asociados al tablespace, tales como tablas, índices, vistas, etc . . .
- Definir cuotas de espacio para los usuarios de los objetos asignados a un tablespace.
- Controlar el acceso a los datos, situando un tablespace en on-line u off-line. - Realizar copias de seguridad de una manera más flexible.
Es decir, podríamos entender los tablespace como 'cada una de las áreas en que
podemos dividir una Base de Datos'. Obviamente, ubicaremos en cada tablespace aquellos
objetos pertenecientes a dicha 'área' (tablas, índices, vistas, etc ... necesarios).
Veamos ahora la función del tablespace SYSTEM. Éste tablespace debe existir en cada Base de Datos. Al crearse ésta, dicho tablespace es creado automáticamente y es obligatorio que el tablespace SYSTEM esté siempre on-line ya que contiene la siguiente información:
- Los segmentos de rollback temporales,
- La ayuda en línea, siempre que ésta esté cargada,
- Aquellas tablas que el producto ORACLE utilice para su funcionamiento, - La definición de los usuarios creados.
Aunque no es obligatorio, el uso de múltiples tablespaces permitirá al Administrador de la Base de Datos una mayor flexibilidad. Algunos de los beneficios de un sistema con múltiples tablespaces son:
- Diversificación en los accesos a disco siempre que los tablespaces estén asociados a ficheros de base de datos situados en diferentes unidades de disco,
- Posible separación de los tipos de objetos en tipos, teniendo la posibilidad de asociar todos las tablas a un tablespace, los índices a otro tablespace y las vistas a un tercero, etc. ...,
- Forzar esquemas de utilización del espacio del disco, dependiendo de la situación física de los ficheros de base de datos a éstos,
- Posibilidad de situar un tablespace de on-line a off-line y viceversa. - Reservar tablespaces para tablas de un índice de actividad parecido.
Una manera de optimizar una Base de Datos es la de asociar un tablespace a un fichero de base de datos, colocando éste fichero en un espacio de disco contiguo y en un lugar de fácil acceso, siempre que sea posible (recordar que la parte central de un disco tiene un acceso más rápido que los extremos de éste). De ésta manera, la accesibilidad de la Base de Datos se haya mejorado con respecto a una Base de Datos sin una organización previa. Por ello, la importancia de que la estructura de tablespaces y ficheros de base de datos en la rapidez de acceso a la Base de Datos.
Segmentos y extensiones
Todos los datos de un tablespace son almacenados en 'pedazos' del espacio reservado para la Base de Datos llamados segmentos. Por ello, un segmento es un conjunto de bloques de la Base de Datos distribuidos para almacenar los datos de ésta. Éstos se corresponden con el siguiente nivel lógico en que se divide la estructura lógica de la Base de Datos, después de los tablespaces, por ello no pueden expandirse a través de más de uno de ellos, pero sí a través de más de un fichero de base de datos (en caso de que un tablespace esté asociado con más de uno de ellos).
Una Base de Datos se compone de cinco tipos de segmentos: - Segmentos de Datos,
- Segmentos de Indices, - Segmentos de Rollback, - Segmentos Temporales y
De todos ellos, los dos primeros son los más utilizados implícitamente por los usuarios de ORACLE. Al Administrador de la Base de Datos le conciernen los tres siguientes; aunque todos ellos tienen una estructura similar, especificada mediante los parámetros de almacenamiento, esto es, se define un tamaño inicial (compuesto por un número finito de segmentos) y seguidamente un número, finito también, de extensiones, o ampliaciones que permite su crecimiento. El propósito de los parámetros de almacenamiento es controlar el espacio en que va creciendo un objeto de la Base de Datos, limitándolo a un tamaño finito de extensiones. Una extensión será pues un espacio contiguo de la Base de Datos (dentro de un fichero de base de datos) expresado en bytes. Por ello, al crearse una tabla, su segmento de datos asociado contiene una extensión inicial con un número finito de bytes. Aunque dicha tabla no contenga ninguna fila, éste espacio inicial queda reservado de manera definitiva. A medida que el número de filas va incrementándose, dicho espacio va siendo ocupado por datos de la tabla hasta que éste espacio inicial se completa. Entonces es creada automáticamente una extensión. En éste momento diremos que el segmento de datos contiene ahora extensiones.
Segmentos de Datos e Indices
Evidentemente el primero de ellos contiene todos los datos de tablas, mientras que el segundo contendrá los datos pertenecientes a índices. Una tabla puede tener uno, más de uno o ningún segmento de índices, dependiendo del número de índices asociados a dicha tabla.
Segmentos de Rollback
Aunque de ellos nos hemos ocupado anteriormente, hablaremos ahora de cada uno de los tipos de segmentos de rollback existentes, por ello podemos decir que existen:
- Segmentos de Rollback Públicos y - Segmentos de Rollback Privados.
Aunque es posible definir ambos tipos de segmentos de Rollback en una Base de Datos, de los primeros diremos que son los más usados en las instalaciones de ORACLE, utilizados por cualquiera de las instancias de la Base de Datos. Los segundos son útiles en casos excepcionales, por ejemplo para instancias particulares que requieran de un tamaño extremadamente grande de segmento de rollback para ser ejecutadas.
Al igual que los segmentos de rollback privados, los segmentos temporales son utilizados en casos excepcionales. Por ello los utilizaremos en operaciones tales como:
- Creación de Indices,
- Instrucciones como: SELECT ... ORDER BY, SELECT ... DISTINCT, SELECT ... GROUP BY, SELECT ... UNION, SELECT ... INTERSECT, SELECT ... MINUS,
- Selección de Datos a través de varias tablas (Joins) sin índice, - Selección de subqueries,
- Etc ...
Segmento de Arranque
El segmento de Arranque es creado en el tablespace SYSTEM automáticamente al crearse la Base de Datos. Contiene la definición del diccionario de datos para las tablas, es decir la definición de cada estructura de cada una de las tablas creadas en la Base de Datos. Obviamente, dicho segmento ocupa un espacio pequeño comparado con el espacio que ocupan los demás segmentos.
Objetos de la Base de Datos
Los diferentes objetos que forman parte de una Base de Datos ORACLE son los siguientes: - Tablas, - Indices, - Vistas, - Clústers, - Secuencias y - Sinónimos.
Debido al amplio conocimiento que se le supone al lector de éste capítulo (es caso contrario es recomendable la lectura del capítulo dedicado al Modelo y Teoría Relacional) veremos de manera rápida la definición y posterior desarrollo de los dos primeros tipos de objetos. Nos detendremos en cuestiones particulares utilizadas por ORACLE.
datos. Compuesta, como es sabido, por filas que representan elementos de la entidad a la que representan y columnas, con un nombre, tipo y tamaño asociado que representan cada uno de los atributos de cada elemento de la entidad. Las tablas son creadas a partir de la instrucción CREATE TABLE. Los parámetros de almacenamiento asociados a éste comando permiten definir un tamaño inicial y un número finito de extensiones. La localización física de una tabla la deberemos encontrar siempre en el fichero de base de datos asociado al tablespace en el que sé difinió la tabla, aunque es imposible adivinar (no para el SGDB) qué espacio exacto ocupa un dato concreto de una tabla.
Diremos que la operación de compactación de una tabla consiste en situar de una manera contigua a cada uno de los segmentos que componen una tabla.
Indices
Los índices son estructuras de datos opcionales asociadas a tablas y clústers. Son utilizados básicamente para:
- Incrementar el acceso a las filas de la tabla asociada,
- Garantizar la unicidad de las filas mediante el uso de las claves únicas.
Por tanto, crearemos un índice siempre que deseemos incrementar algunos de los parámetros anteriores, teniendo en cuenta que un número elevado de índices asociados a una tabla decrementará las operaciones de modificación y creación de filas. Normalmente los índices son creados en una tablespace específico. El uso de un tablespace distintos para datos y otro para índices, situados en diferentes discos, incrementa la accesibilidad de los datos. Situando los índices y datos en un único tablespace obtendremos una mayor facilidad en el mantenimiento de la Base de Datos para realizar backups. Situaremos los índices en el tablespace que más nos convenga, dependiendo siempre de la instalación que debamos realizar.
El acceso de los datos a través de los índices asociados se realiza utilizando la estructura de Arboles B+. Veamos como se funcionan dichas estructuras a partir de la figura 9:
TURNER WARD MARTIN MILLERSCOTT
JAMES JONES ADAM ALLEN BLAKE FORD MI T M B J Figura 9. Arboles B+
A partir de un nodo inicial, y basándonos ramificaciones, llegaremos al nodo deseado. El identificador de la fila asociado a dicho nodo nos permitirá el acceso directo a la tabla de datos para la que se define el índice. Las filas con valores nulos no formarán parte de dicha estructura de índice.
Vistas
Aunque técnica y físicamente no podemos tratar las vistas como tablas de datos, sí que podemos afirmar que lógicamente son verdaderas tablas de datos. Una vista almacena el resultado de una consulta previamente definida realizada contra una tabla de datos. Por ello, aplicando la teoría relacional, podemos tratar las vistas como verdaderas tablas lógicas de datos.
Normalmente utilizaremos las vistas para facilitar y restringir las consultas de datos hacia las tablas definidas en la Base de Datos. Debido que éstas son simples referencias a las tablas de datos, no ocupan el espacio físico de la consulta que representan (sólo ocupan espacio en el diccionario de datos).
El usuario de vistas debe tener presente en cada momento las tablas de datos a las que éstas hacen referencia, ya que un cambio en éstas últimas (alteración de campos, eliminación de la tabla de datos asociada, etc ...) no modificará automáticamente las vistas de éstas.
Dada la tabla de datos CLIENTES, supongamos que deseamos ocultar a los usuarios la información referente a los clientes no pertenecientes a nuestra provincia. Para ello crearemos la vista
CREATE VIEW clientes_baleares AS SELECT * FROM clientes WHERE provincia = 'BALEARES'
No olvidemos que los usuarios de dicha vista verán los datos que ésta ofrece como una tabla lógica de datos.
Figura 10. Uso de las Vistas
Clústers
Los clústers son utilizados como un modo alternativo de almacenamiento de tablas. Los clústers representan grupos de tablas almacenadas de manera conjunta ya que éstas comparten columnas comunes y son utilizadas frecuentemente juntas.
Por ello, el uso de clústers puede modificar sensiblemente la velocidad de respuesta frente a consultas de datos con tablas enlazadas mediante éste sistema. Debemos tener en cuenta una serie de consideraciones sobre el uso de éstas:
- Los tiempos de búsqueda y cálculo se reducen ya que la información está almacenada de manera conjunta,
- El espacio de almacenamiento se reduce al estar almacenada una sola vez la información redundante de varias tablas,
- Los clústers almacenan más eficientemente un conjunto de tablas que si éstas fuesen almacenadas de manera separada,
- El uso de clústers, así como el de índices, no afecta al diseño futuro de las aplicaciones que manejen dichos datos,
- El uso de clústers permite una mejor identificación de la información existente (ello se nota especialmente al asociar las columnas código con la tabla que contiene la descripción de dicho código)
Así, aquellas tablas que son consultadas frecuentemente de manera conjunta son candidatas a ser asociadas mediante clústers. Obviamente, las columnas que formen el campo clave de unión con las tablas serán utilizadas en la asociación.
Secuencias
Las secuencias son un tipo de objetos utilizados para establecer y asociar una numeración correlativa de manera automática en las columnas que así se desee realizar. Las secuencias serán numeradores siempre de tipo numérico a los que se les asocian las siguientes propiedades:
- Un inicio, - Un final,
- Un valor de incremento,
- Una marca que indique si la secuencia es cíclica o no.
Existen dos funciones utilizadas en la manipulación de las secuencias: NEXTVAL es utilizada para generar el siguiente valor de la secuencia, para ello incrementa la secuencia en la unidad de incremento definida para ésta y obtiene dicho valor; CURRVAL obtiene el valor actual de la secuencia sin incrementar el valor de ésta.
El siguiente ejemplo muestra el uso de las secuencias:
Supongamos la secuencia seqval definida como: CREATE SEQUENCE seqval INCREMENT BY 10
START WITH 0 La sentencia:
SELECT seqval.NEXTVAL A, seqval.NEXTVAL B, seqval.CURRVAL C FROM dual generaría la salida:
A B C 10 20 20
Figura 11. Uso de las Secuencias
El uso de los operadores CURRVAL y NEXTVAL está restringido en las siguientes cláusulas: - SELECT ... WHERE ... - SELECT ... ORDER BY ... - SELECT ... CONNECT BY ... - SELECT ... GROUP BY ... - SELECT DISTINCT ...
En cambio, el uso de secuencias está indicado para las sentencias siguientes: - INSERT ... VALUES ...
- UPDATE ... SET ...
- UPDATE ... SELECT .NEXTVAL.
Es posible modificar el valor de una secuencia, así como alguna de las propiedades que la definen, utilizando el comando ALTER SEQUENCE.
Sinónimos
Un sinónimo es un objeto utilizado como enlace para el acceso a cualquiera de los demás objetos definidos en la Base de Datos. Es decir, dado cualquier objeto de la misma, podemos crear un segundo acceso a ésta mediante la utilización de un sinónimo. Veamos la siguiente figura para entender mejor el uso de los sinónimos:
Supongamos la tabla: EMPLEADOS
Podemos acceder a la información que ésta contiene mediante la instrucción: SELECT codigo, direccion, telefono FROM empleados
WHERE nombre LIKE 'A%' Después de la instrucción:
CREATE PUBLIC SYNONYM trabajadores ON empleados la instrucción:
SELECT codigo, direccion, telefono FROM trabajadores WHERE nombre LIKE 'A%'
implica la misma consulta que la primera.
Figura 12. Uso de sinónimos
El Diccionario de Datos
Hasta ahora hemos estado hablando del Diccionario de Datos aunque en ningún momento hemos definido la finalidad y estructura del mismo. En éste punto veremos la definición del diccionario de datos, qué tipo de objetos lo forman, el esquema de diseño que sigue y la manera de modificar su contenido.
Dicha estructura es utilizada por el Administrador de la Base de Datos, aunque algunos usuarios pueden beneficiarse de alguno de sus contenidos. Así, podemos definir el Diccionario de Datos como un conjunto de tablas y vistas de sólo lectura, propias del producto ORACLE que contienen la siguiente información:
- Los nombre de cada uno de los usuarios de la Base de Datos ORACLE, - Derechos y privilegios que tienen cada uno de ellos,
- Los nombres de cada uno de los objetos definidos en la Base de Datos, es decir, tablas, vistas, índices, clústers, sinónimos y secuencias,
- Claves primarias y externas referentes a los índices existentes, - Valores por defecto para las columnas,
- Enlaces entre columnas,
- Espacio que ocupan los objetos definidos,
- Información referente a las posibles auditorias realizadas en la Base de Datos, - Información general de la Base de Datos.
He aquí una breve relación de las tablas y vistas más utilizadas en el diccionario de datos:
DICTIONARY: Relación de las tablas y vistas que componen el Diccionario de Datos ALL_USERS: Información acerca de los usuarios de la Base de Datos
ALL_OBJECTS: Información acerca de cada uno de los objetos, es decir, tablas, índices, vistas, secuencias, synónimos, etc. ... existentes en la b.d. accesible por el usuario.
ALL_TABLES: Descripción de las Tablas accesibles por los usuarios ALL_INDEXES: Relación de los índices accesibles por los usuarios. ALL_SEQUENCES: Relación de las secuencias existentes
ALL_VIEWS: Texto de las Vistas accesibles en la Base de Datos ALL_SYNONYMS: Relación de sinóminos en la Base de Datos.
ALL_TAB_COLUMNS: relación de cada una de las columnas y tablas existentes en la b.d.
TABLE_PRIVILEGES: Relación de cada uno de los privilegios existentes en cada una de las tablas de la Base de Datos, asociándolo con cada uno de los usuarios.
En éste apartado describiremos la estructura de memoria utilizada por ORACLE. Dicha estructura viene definida a partir de las siguientes áreas:
- Area Global del Sistema (SGA), - Búffers de base de datos,
- Búffers de traza,
- Area Global de Programas (PGA), - Areas de contexto,
- Areas de software, - Memoria virtual.
Es decir, en ella se almacenará básicamente información del tipo: - El código de sus programas ejecutables,
- Los datos necesarios para la ejecución de éstos,
- Información necesaria para comunicación entre procesos.
Todas las operaciones realizadas por el Gestor de la Base de Datos ORACLE están basadas en la estructura de memoria y procesos existente. Esta se basa en la memoria principal de la computadora sobre la que está instalado el producto. Un proceso es un trabajo o tarea que realiza operaciones en memoria. Entre éstos, se incluyen los procesos que cada uno de los usuarios ejecuta, más los cinco procesos background de ORACLE ya presentados en la introducción y que en capítulos posteriores desarrollaremos.
Veamos cada una de las áreas en que se compone la estructura de memoria de manera separada.
Area Global del Sistema (SGA)
La SGA (System Global Area, Area Global del Sistema) es un conjunto de Búffers de memoria compartida que contiene tanto datos como información de control para una instancia de la Base de Datos. El SGBD es quien escribe directamente sobre dicha área a partir de la ejecución del código que el usuario procesa.
El SGA contiene entonces los búffers de la Base de Datos, los búffers de redo e incluso información cacheada del diccionario de datos. Por ello, cada instancia mantendrá su propia SGA, y todas las SGAs existentes serán compartidas por cada uno de los usuarios conectados a la Base de Datos.
Veamos como actúan los búffers de la Base de Datos existentes en el SGA durante la ejecución de una transacción que produce modificación de datos:
- Cada instrucción que ejecuta una transacción modifica el bloque de segmento de datos correspondiente en su buffer correspondiente. Un bloque del buffer de la Base de Datos se corresponde unívocamente con un bloque de un fichero de base de datos (vistos anteriormente). Si es demandada una información de un bloque del fichero que no existe en el buffer de la Base de Datos, éstas es leída y llevada al buffer. De ésta manera, la transacción modifica la información existente en el buffer de la Base de Datos, nunca directamente la información existente en el fichero de base de datos.
- Al mismo tiempo, se almacena aquella información necesaria para realizar una posible vuelta atrás de la transacción en su correspondiente bloque de rollback del buffer de redo correspondiente.
- Al grabarse una transacción, la información existente en el buffer de redo es escrita en su correspondiente fichero de traza (aquel que esté on-line en el momento de la escritura).
La información existente en el buffer de la Base de Datos no es escrita al terminar la transacción, sino que dicha información queda en dicho buffer. El proceso DBWR será el encargado de escribir dicha información en los ficheros físicos de base de datos siguiendo un algoritmo llamado LRU (Least fRequence Used, el menos utilizado frecuentemente). Dicho algoritmo trabaja de la siguiente manera:
- Los procesos de cada usuario provocan nuevas inserciones de bloques en el buffer de memoria,
- Aquellos bloques que no son utilizados quedan marcadas en una 'lista de utilización de bloques',
- De ésta manera, inserciones de nuevos bloques provocan la salida de aquellos bloques situados al final de la 'lista'.
Area Global de Programas
El área global de programas (Program Global Area, PGA) es un búffer de memoria de lectura-escritura no compartida que contiene datos e información de control acerca de cada uno de los procesos de un usuario. Por ello, diremos que cada proceso provocado por un usuario contendrá su propia PGA.
Un usuario, al conectar con la Base de Datos ORACLE (desde cualquiera de sus componentes) provoca la creación de una PGA que contiene información acerca de la conexión. Si el sistema operativo no es capaz de suministrar dicha memoria, se producirá
de contexto que serán descritas seguidamente. Los parámetros: - OPEN_CURSORS, - OPEN_LINKS, - SAVEPOINTS, - DB_FILES y - LOG_FILES
del fichero de configuración INIT.ORA permiten definir el tamaño de cada PGA. El tamaño para los procesos background (DBWR, LGWR, SMON, PMON y ARCH) vendrá definido adicionalmente por éstos y otros parámetros.
Areas de Contexto
El término área de contenido es asociado frecuentemente al término cursor1, ya que
en muchas ocasiones representan lo mismo.
Cada instrucción SQL provocada por un proceso de un usuario requiere de su área
de contexto, un buffer de memoria de lectura-escritura no compartida creado para
almacenar la información del proceso acerca de la ejecución de la instrucción SQL.
El SGBD crea automáticamente una área de contexto cada vez que una instrucción SQL lo requiere, y la cierra al finalizar la ejecución de la misma. Por ello, un proceso puede tener varias áreas de contexto asociadas a su PGA. Esta estructura contiene información acerca de:
- El texto de la instrucción SQL, - La traducción de dicho texto,
- Una fila para el resultado de valores intermedios en la ejecución de la instrucción, - Información de la ejecución del cursor de la instrucción,
- Información de control para instrucciones de ordenación de datos.
Areas de Software
1El término cursor está asociado a la ejecución de instrucciones SQL. La ejecución de una instrucción SQL
provoca la 'creación de una tabla fictícia' sobre la que se opera, o consulta. El apuntador a cada una de éstos registros que componen la tabla se denomina cursor. Diremos, pues que al iniciarse una instrucción SQL se abre un cursor, que es cerrado al finalizar la ejecución de la misma. Un usuario es capaz de crear pues cursores de una manera implícita. El lector encontrará una mayor extensión acerca de la utilización de cursores explícitos en el capítulo dedicado a la programación de PRO*C.
Las áreas de software proporcionan porciones de memoria de sólo lectura, compartidas o exclusivas según instalación utilizadas para almacenar el código que el usuario ejecuta. El código contenido en cada uno de los cinco procesos background también ocupa espacio en dichas áreas de memoria, aunque éste espacio ocupa un lugar protegido y exclusivo diferente al asignado a los usuarios.
Estas áreas están asociadas al contenido de los ficheros programas de ORACLE vistos anteriormente.
Memoria Virtual
Dependiendo del sistema operativo sobre el que esté instalado el producto ORACLE, éste puede utilizar parte de la llamada memoria virtual. Esta proporciona la ventaja de utilizar espacio de disco simulando espacio de memoria real o principal.
El objetivo de éste apartado no es el de explicar el funcionamiento de la memoria virtual, sino simplemente hacer constancia de la existencia de éste tipo de estructura de memoria.
Trataremos ahora la descripción general de los tipos de procesos utilizados por el SGBD de ORACLE, su utilización, la implementación actual y las opciones que nos ofrece el sistema operativo. Hablaremos de conceptos tales como los procesos de usuarios, los cinco procesos background utilizados por el sistema de usuarios y la diferencia de funcionamiento entre un sistema ORACLE funcionando en single-task o funcionando en
two-task.
Definimos un proceso como un mecanismo, dentro del sistema operativo sobre el que convive, capaz de ejecutar una serie de instrucciones en una área, normalmente propia, de memoria. La estructura de procesos de un sistema define cuantos procesos pueden ejecutarse al mismo tiempo y como son ejecutados éstos. Dicha estructura debe conseguir dos metas básicas:
- Simular un entorno privado en un entorno público de procesos, en donde todos ellos trabajan simultáneamente y
- Permitir que cada uno de los procesos comparta todos los recursos de la máquina sobre la que se ejecuta sin que ninguno de ellos hagan un uso individual de éstos. En un sistema ORACLE existen diferentes tipos de procesos. Estos son:
- Procesos de usuario, es decir, aquellos procesos que son utilizados directamente por un usuario o por las aplicaciones que éste ejecuta.
- Procesos del servidor, aquellos invocados por otros procesos. Estos a su vez se dividen en:
- Procesos sombra: asociados indefectiblemente a un proceso de usuario - Procesos background, compuesto por el conjunto de cinco procesos vistos anteriormente: SMON, PMON, DBWR, LGWR y ARCH, utilizados en un sistema multiproceso, no están asociados a un proceso de usuario, aunque éstos se sirven de los procesos background para realizar funciones contra la Base de Datos. Su ciclo de vida empieza al arrancar el SGBD y finaliza al hacerlo éste.
Todos ellos serán descritos con mayor extensión en los siguientes puntos.
Single-Task contra Two-Task
La estructura de procesos del SGBD presenta dos variaciones principales dependiendo de sí los programas que representan los procesos son compartidos o no.
Los procesos de usuario son creados cada vez que un usuario del sistema hace referencia a cualquier aplicación que requiera conexión con ORACLE. Los procesos de usuario se comunican con la Base de Datos a través del llamado program interface.
En sistemas single-task, las aplicaciones del usuario, el núcleo de ORACLE y el program interface son todos ejecutados bajo un mismo proceso. Este último es el encargado la protección del código ejecutable de éstos, así como del traspaso de datos entre el usuario y ORACLE. Bajo éste sistema solo se permite una única conexión a la Base de Datos por proceso. Este sistema es utilizado cuando se requiere una clara separación entre los programas de usuario y los de ORACLE, así como una integridad y privacidad de los datos que el sistema operativo no es capaz de asegurar.
Program Interface Programa ORACLE Un Proceso para dos programas Programa Usuario
Proceso Sombra Program Interface Programa ORACLE Proceso del Usuario Programa Usuario
Figura 15. Two Task sobre un ordenador
Los sistemas two-task sitúan los procesos sombra, aquellos generados a partir de los procesos de usuario de los que dependen, en diferentes procesos asociados. Para ello se utiliza el mecanismo de comunicación entre procesos que ofrece el sistema operativo. De ésta manera, cada proceso conectado a ORACLE tendrá su propio proceso sombra.
El sistema two-task es utilizado por el producto SQL*Net al ejecutar un programa en un ordenador cuya Base de Datos remota está situada en otra máquina externa a ésta.
Protocolo Comunicación Máquina Remota Máquina Local Proceso Sombra Program Interface Programa ORACLE Proceso del Usuario Programa Usuario
Figura 16. Two Task sobre dos ordenador
Instancias en Multiproceso contra Monoproceso
El Gestor de la Base de Datos de ORACLE puede funcionar en cualquiera de los modos expuestos en el título anterior dependiendo del valor del parámetro SINGLE_PROCESS (true ó false) dentro del fichero de configuración INIT.ORA. Veamos las peculiaridades de cada uno de los modos de procesamiento que presenta el Gestor.
El monoproceso, o también llamado único usuario, permite la entrada a la Base de Datos de un único usuario. Así la entrada de más de un usuario de forma concurrente no está permitida. Aquellas instalaciones de ORACLE sobre sistemas operativos que no soporten dicha concurrencia deben hacerse en éste modo (p.e. MS-DOS). Por ello éstas instalaciones son también 'monoinstanciales', la Base de Datos no puede ser consultada por dos o más instancias a la vez.
El multiproceso es aquel que permite el acceso de dos o más usuarios contra la Base de Datos de una manera concurrente. Éste modo requiere de la puesta en marcha de los cinco procesos que anteriormente hemos llamado procesos background. La función de éstos es la de mejorar el sistema de manera que se permita un acceso concurrente y fiable a
dicha concurrencia. Veamos de manera separada cada uno de éstos procesos:
DBWR: Database Writer
Está encargado de escribir aquellas modificaciones provocadas en los bloques existentes en el buffer de la Base de Datos. El algoritmo que sigue dicho proceso asegura la existencia de los bloques que últimamente han sido consultados, escribiendo aquellos bloques que no son consultados frecuentemente; de ésta mantiene los bloques con aquella información que más recientemente ha sido requerida y escribe los bloques que no son requeridos.
LGWR: Log Writer
Se ha dicho con anterioridad que la finalización de una transacción mediante un COMMIT no aseguraba la escritura física del bloque correspondiente a disco, sino que es el proceso DBWR el encargado de dicha tarea (siguiendo el llamado algoritmo). El proceso LGWR permite la actualización de las modificaciones que realiza una transacción en los ficheros de trazas a partir de las modificaciones anotadas en el buffer de redo. La terminación de dicha transacción en COMMIT provoca la escritura de las anotaciones realizadas en el buffer sobre el fichero de traza on-line que es el momento de la escritura esté activo.
SMON: System Monitor
Este proceso se encarga de la recuperación de instancias en caso de error. Por ello, éste es referenciado por aquellos procesos que los requieran.
PMON: Process Monitor
El proceso PMON actúa en caso de errores en procesos de usuarios. Está encargado de liberar aquellos recursos utilizados por los usuarios. Por ello resetea la tabla de transacciones activas, modifica los bloqueos entre tablas y elimina los procesos que ya no actúan.
ARCH: Archiver
Está encargado de realizar copia a cinta (u otro medio) de aquellos ficheros de traza on-line cuando éstos se llenan siempre que esté habilitado el modo ARCHIVELOG.
El Program Interface
El program interface actúa como interface entre los programas de usuario (aplicaciones, programas batch, etc ...) y los programas de ORACLE. Las funciones principales de éste son:
- Asegurar una barrera de seguridad, previniendo la Base de Datos de accesos destructivos de procesos de usuarios no deseados,
- Actuar como un mecanismo de comunicaciones entre los procesos de usuario y la Base de Datos, transformando y traduciendo datos y errores de ésta entre posiblemente ordenadores diferentes y aplicativos con tipo de datos distintos,
- Formatear la información requerida de la Base de Datos, traduciendo y devolviendo errores.
Por ello, decimos que el program interface es un nivel, o 'capa' situada entre la Base de Datos y los aplicativos de los usuarios. La estructura viene definida a partir de estructuras básicas, entre las que pueden distinguirse las siguientes:
- UPI, User Program Interface (Program Interface del Usuario), - OPI, ORACLE Program Interface ( Program Interface de ORACLE), - Drivers, por ejemplo de comunicaciones,
- Software de Comunicaciones propio del sistema operativo, - OCI, ORACLE Call Interface (Call Interface de ORACLE), - SQL, Interface del Precompilador de SQL.
Hasta ahora hemos hablado de los elementos esenciales que integran el SGBD, pero es precisamente la presencia de los usuarios lo que activa la ‘maquinaria’ del producto ORACLE. Obviamente, sin la existencia de dichos usuarios no se justificaría de ningún modo la presencia de todas las estructuras vistas anteriormente.
En éste capítulo distinguiremos la accesibilidad de los usuarios respecto a la Base de Datos y de éstos hacia cada uno de los objetos definidos en ésta.
Usuarios y Base de Datos
Empezaremos por definir los tipos de acceso que se le otorga a un usuario, la manera en que se puede cambiar los atributos de éste y un procedimiento útil a seguir para la creación de los usuarios de la Base de Datos.
Una de las tareas encomendadas al Administrador de la Base de Datos es la de permitir la entrada a aquellos usuarios que deban tener acceso a ésta de una manera controlada. Para ello, el usuario debe tener un nombre de usuario y una contraseña de
entrada definida en la Base de Datos ORACLE. Una vez creado el usuario, ORACLE
define una serie de prioridades que pueden ser otorgadas a éstos. Dichas prioridades marcan el tipo de acceso que un usuario puede realizar a la Base de Datos. La información referente a dichos privilegios, así como aquella asociada a cada usuario, queda almacenada en el diccionario de la Base de Datos, y por ello en éste tenemos información acerca de:
- El tipo de acceso del usuario a la Base de Datos, es decir acceso del tipo CONNECT, RESOURCE o DBA,
- Tablespace por defecto asociado al usuario, y por ello tablas, índices, etc. ... asociados a dicho tablespace,
- tablespace temporal para la ejecución de aquellos procesos que los requieran, - Cuota de tablespace máxima de utilización dentro del tablespace.
Como hemos visto anteriormente, es posible asociar un privilegio a cada uno de los usuarios de la Base de Datos, de manera que éste le permite realizar una serie de acciones u otras en función de dicho privilegio. En ORACLE es posible definir hasta tres tipos de entrada diferentes a la Base de Datos cada uno de ellos con unas peculiaridades. Veamos cada uno de ellos:
- Usuarios con privilegio CONNECT: a un usuario con éste tipo de privilegio sólo le es permitido una conexión simple a la Base de Datos. De ésta manera, dicho usuario podrá ejecutar cuantas transacciones requiera siempre que sean del tipo:
- Conexión a la Base de Datos (CONNECT),
- Consultas con tablas, vistas de otros usuarios, (SELECT) siempre que dichos objetos tengan uso público o uso privado definido para dicho usuario (veremos posteriormente los privilegios que pueden tener los objetos de la Base de Datos),
- Realizar operaciones de modificación e inserción (UPDATE, INSERT) contra objetos de la Base de Datos con privilegios para ello,
- Crear objetos propios tales como vistas, sinónimos y enlaces a Bases de Datos externas. Sin embargo, no podrá crear tablas, clústers, secuencias o índices.
Aquellos usuarios que convivan en un entorno con más de una Base de Datos deberán tener el privilegio CONNECT en cada una de las Bases de Datos en donde deseen acceder.
- Usuarios con privilegio RESOURCE: los usuarios con el privilegio RESOURCE adquieren automáticamente los privilegios anteriormente vistos. Además, éste privilegio permite la posibilidad de crear aquellos objetos de la Base de Datos que no es posible crear con el privilegio anterior, es decir crear tablas, clústers, secuencias e índices. El privilegio RESOURCE puede darse de tres maneras diferentes:
- Sin restricciones de acceso a ninguna de las tablas de la Base de Datos, - Restringiendo el acceso a aquellas tablas de la Base de Datos asociadas a un tablespace,
- Especificando una cuota de espacio para aquellas tablas pertenecientes a un tablespace.
La manera normal de operar, y la que asegura una protección a la Base de Datos es la permitir a todos los usuarios un acceso con CONNECT a toda la Base de Datos, y asociar a los tablespaces requeridos el privilegio de RESOURCE a los usuarios que lo soliciten.
- Usuarios con privilegio DBA: los usuarios con el privilegio DBA tienen asegurados los privilegios anteriores. Además pueden realizar las siguientes operaciones:
- Acceder a cualquier tabla existente en la Base de Datos y ejecutar cualquier instrucción SQL sobre ésta,
- Dar y/o eliminar los privilegios sobre objetos existentes a cualquiera de los usuarios,
- Crear sinónimos de uso público,
- Crear y/o modificar tablespaces, así como operar con ellos (poner en on/off-line, realizar copia de seguridad de un tablespace, etc. ...).
Aunque el número de usuarios DBA en un sistema ORACLE no está restringido, no es correcto que dicho número sea ilimitado por razones obvias. Por defecto, las instalaciones de ORACLE vienen configuradas con dos usuarios del tipo DBA, los usuarios SYSTEM y SYS. Es importante que tanto los privilegios como las características de éstos no sean alterados.
Es posible modificar los privilegios que a un usuario se le han otorgado, ya sea para incrementar las operaciones que éste puede realizar, como para disminuirlas. Existen otros atributos asociados a un usuario, alguno de ellos vistos anteriormente. Estos son:
- El tablespace por defecto al sobre el que un usuario trabaja, y por tanto sobre el que creará sus objetos,
- El tablespace temporal por defecto de dicho usuario,
- La cuota de espacio permitida a un usuario sobre un tablespace.
- Definiendo un usuario con el prefijo ‘OPS$’ en el nombre de un usuario, permitiremos un acceso directo2 a la Base de Datos de éste, tomando el nombre de
usuario de sistema operativo. Es decir un usuario de sistema operativo llamado ‘alfonso’ tendrá acceso directo siempre que exista en la Base de Datos un usuario llamado ‘ops$alfonso’.
Por todo ello, seguiremos el siguiente procedimiento para crear un usuario en la Base de Datos ORACLE:
1- Decidir el nombre y contraseña inicial del usuario,
2- Decidir si dicho usuario es de acceso directo, por ello añadiremos al nombre del usuario el prefijo ‘OPS$’,
3- Si el usuario va a crear objetos, identificar sobre que tablespace realizará dichas operaciones de creación de objetos. Identificar el tablespace temporal que dicho usuario utilizará,
4- Decidir el tipo de acceso, así como la cantidad de espacio permitido sobre cada tablespace,
5- Permitir el privilegio RESOURCE sobre el tablespace requerido, con la cuota de espacio necesario, así como marcar el tablespace temporal que utilizará (según pto. 3),
6- Informar al usuario de su nombre de usuario, password y si es de acceso directo o no.
Usuarios y los Objetos de la Base de Datos
2 Acceso directo a la Base de Datos indica que podemos omitir la entrada de
nombre_usuario/password en cualquier producto ORACLE simplemente pulsando Intro/Intro en cada una de ellas.
Este apartado está especialmente indicado a aquellos usuarios a los que se les ha asignado el privilegio DBA ya que éste explica, entre otras, los posibles accesos que puede realizarse hacia un objeto.
Como ya es sabido, un objeto tiene como característica principal la del propietario, es decir, la persona que creó dicho objeto (mediante la instrucción CREATE TABLE, INDEX, VIEW, etc.). Este propietario, en principio, está autorizado al acceso de todos los datos que representa dicho objeto (es decir, acceso a todas las filas y columnas) y a conceder acceso parcial o total a otros usuarios (mientras que un usuario del tipo DBA no se quite ésta propiedad sobre el objeto determinado).
Veamos los tipos de accesos que es posible definir a partir de la instrucción que permite otorgar dichos accesos:
GRANT SELECT, UPDATE, INSERT, DELETE, INDEX ON objeto
TO usuario WITH GRANT OPTION
Ello nos indica los tipos de acceso que es posible otorgar a un usuario no propietario de un objeto. Por ello diremos que los usuarios podrán consultar, modificar y añadir filas o borrarlas (SELECT, UPDATE, INSERT, DELETE respectivamente) sobre un objeto según el acceso que se haya definido sobre él. El parámetro WITH GRANT OPTION indica que el usuario, a su vez, puede otorgar accesos a otros usuarios. El acceso INDEX indica el uso, en caso de que existan, de los índices asociados al objeto.
Este tipo de acceso está definido especialmente sobre tablas y vistas. Existen algunas restricciones tales como:
- No es posible ejecutar instrucciones del tipo UPDATE, INSERT o DELETE sobre vistas que estén basadas en expresiones, joins o operadores de conjunto (UNION, INTERSECT, etc. ...),
- Los propietarios de una vista B basada en una tabla A no pueden otorgar a su vez acceso a otros usuarios en la vista B si no poseen el privilegio sobre la tabla A. La instrucción GRANT permite, además, otorgar un acceso parcial a las columnas que el objeto representa. De ésta manera, es posible ejecutar la instrucción:
GRANT SELECT, UPDATE, ... REFERENCES (columna_1, columna_2, ...) ON objeto
TO usuario WITH GRANT OPTION
Obviamente, el uso de las opciones DELETE y REFERENCES son incompatibles, así como cualquiera de las opciones UPDATE, INSERT, DELETE, INDEX sobre secuencias.
De la misma manera que es posible definir GRANTs sobre objetos, es posible revocar dicho acceso sobre los mismos. La instrucción:
REVOKE SELECT, UPDATE, INSERT, DELETE, INDEX ON objeto
La Estructura de Datos Ejemplo.
Veamos lo anteriormente expuesto en un ejemplo práctico. Esta podría ser la estructura de datos simple de una empresa que haya elegido como gestor de Base de datos un entorno ORACLE:
Estructura Lógica de la Base de Datos:
B. Datos BASE DATOS EJEMPLO
TABLESPACES SYSTEM PERSONAL CONTABILIDAD ADMINISTRACION INDICES TEMPORAL OBJETOS TABLAS EMPLEADOS SALARIOS ... ASIENTOS APUNTES ... FACTURAS RECIBOS ... IND_1 IND_2 ...
SISTEMA CATEGORIAS ASISTENCIA ... CENTROS
DE COSTE ... ... CLIENTES ... IND_3 IND_N ...
B.Datos BASE DATOS DESARROLLO APLICATIVOS
TABLESPACES DESARROLLO_1
OBJECTOS TABLAS DE PRUEBA PARA DESARROLLO DE PROGRAMAS SEGMENTOS
ROLLBACK
RS_BIG RS_2 RS_3 RS_4 RS_5 RS_6 RS_7 RS_8 RS_9 RS_10
Estructura Física de la Base de Datos:
Ficheros de Base de Datos Montado en Disco /home/oracle/dbs_1/system.dbf Disco A /home/oracle/dbs_1/personal.dbf Disco B /home/oracle/dbs_1/contabilidad.dbf Disco A /home/oracle/dbs_1/administración_1.dbf Disco B /home/oracle/dbs_1/administracion_2.dbf Disco B /home/oracle/dbs_1/indices_1.dbf Disco C /home/oracle/dbs_1/indices_2.dbf Disco C /home/oracle/dbs_1/temporal.dbf Disco C /home/oracle/dbs_2/temporal.dbf Disco D /home/oracle/dbs_3/desarrollo.dbf Disco D
Ficheros de Traza Montado en Disco /home/oracle/dbs_t/trazas.dbf Disco C
Figura 13. Ejemplo de la Estructura Global de una Base de Datos Real.
En ésta se presentan seis tablespaces asociados a la Base de Datos Corporativa. Uno para cada una de las áreas en que hemos dividido la empresa, y por tanto la Base de Datos asociada. Para ello hemos creado los tablespaces 'Personal', 'Contabilidad', 'Administración'. Estos contendrán las tablas de datos asociadas a cada área que representan, de ésta manera, el primer tablespace 'Personal' contendrá las tablas de 'Empleados', 'Categorías', 'Salarios', 'Asistencia', etc. ..., el segundo, las tablas de 'Asientos', 'Apuntes', 'Centros de Coste', etc. ... Se ha reservado un tablespace 'Indices' al
'Temporal' contiene todos aquellos objetos utilizados en la Base de Datos que no están representados en ningún tablespace particular y que sean utilizados de manera temporal, por ejemplo tablas de datos e índices utilizados por procesos batch, etc. ... . De ésta manera los accesos a las tablas, y por tanto a sus índices se reparten de una manera más uniforme a lo largo del disco ya que debemos tener en cuenta que el acceso a un registro de una tabla que tiene asociado un índice supone el acceso a un registro de índice para cada uno de los índices definidos para la tabla.
