Unidad Didáctica 2 Introducción al Modelo Físico del SGBD Oracle 10g
UNIDAD DIDÁCTICA 2
Introducción al Modelo Físico del SGBD Oracle 10g
Índice 1. Arquitectura de Oracle 10g 1.1. Arquitectura 1.2. Bases de datos en varias instancias 1.3. Las transacciones 2. La instancia Oracle (I) 2.1. Estructuras de memoria 2.2. El Área Global de Programas (PGA) 2.3. Área SQL privada 2.4. El Área Global del Sistema (SGA) 3. La instancia Oracle (II) 3.1. Los procesos 3.2. Procesos de Usuario (cliente) 3.3. Procesos de Oracle 4. Base de Datos 4.1. Base de Datos 4.2. Ficheros de Datos 4.3 Ficheros de control 4.4 Ficheros de Redo o Undo 5. Diccionario de Datos 5.1. Diccionario 5.2. Uso del Diccionario de datos 5.3. Tipos de vistas en el Diccionario de Datos 5.4. Tablas dinámicas de rendimiento 5.5. Actualización de la información del diccionario de datos
Esquema de contenidos:
Introducción El servidor Oracle 10g es un Sistema Gestor de Base de Datos (SGBD) objeto-relacional que permite administrar la información que almacena de manera sencilla y completa. El modelo físico de Oracle 10g, se basa en una arquitectura divida en dos zonas diferenciadas: •
Instancia de Oracle
•
Base de Datos
Esta unidad se centra en los elementos que componen cada una de estas partes. Además se describirá el concepto de Diccionario de Datos en Oracle 10g, así como su función dentro del SGBD. Al finalizar cada lección se plantearán una serie de ejercicios prácticos que inciden en los conceptos presentados y refuerzan su aprendizaje, intentar su resolución y trabajarlos es primordial para conseguir los objetivos fijados en esta unidad.
Objetivos En esta unidad aprenderás: -
Aspectos relativos a la instancia de Oracle. Sus componentes principales son: o Estructuras de memoria o Procesos
-
Aspectos relativos a la Base de Datos (BBDD). Los elementos que lo componen son: o Ficheros de Datos o Fichero de Control o Ficheros de Redo
-
Descripción y utilización del Diccionario de Datos (DD).
Lección 1
Arquitectura de Oracle 10g
Índice 1.1. Arquitectura 1.2. Bases de datos en varias instancias 1.3. Las transacciones
Introducción En esta lección se describe la arquitectura de un SGBD Oracle 10g. En segundo lugar se introducen los componentes más importantes de la misma, se explica la posible utilización compartida de las instancias y se describe el concepto de transacción. Al finalizar se incluyen una serie de ejercicios de auto evaluación para comprobar los conocimientos aprendidos.
Objetivos En esta lección aprenderás: -
La arquitectura del SGBD Oracle 10g.
-
Los componentes principales de cada parte de la arquitectura. o Descripción del concepto de BBDD en Oracle 10g o Descripción del concepto instancia en Oracle 10g
-
La utilización compartida de las instancias.
-
El concepto de transacción.
Apartado 1.1: Definición de Base de Datos El servidor Oracle 10g es un SGBD objeto-relacional que permite administrar datos de manera sencilla y completa. Todo servidor Oracle 10g consta de dos partes diferenciadas (ver Figura 1): •
Base de Datos: Es un conjunto de datos relacionados entre sí que se administran de forma conjunta. Sirven para almacenar y recuperar información. La BBDD se compone de estructuras lógicas (tablespaces, segmentos, extensiones y bloques) y físicas (ficheros de datos, control
y redo). Ambas se gestionan por
separado, por lo que el aspecto físico puede manipularse sin afectar al acceso a las estructuras lógicas. •
Instancia: Cada vez que se desea facilitar el acceso a una BBDD, se reserva una porción de memoria y se arrancan una serie de procesos en segundo plano (background). El conjunto de memoria adquirida y de procesos arrancados que se dedican a la gestión de una BBDD conforman la instancia de Oracle 10g.
Figura 1. Visión general de la arquitectura de un servidor Oracle 10G
En la Figura 2, puede observarse en detalle la arquitectura completa de un servidor de Oracle 10G. La utilidad e interacción de los diferentes componentes se explicará a lo largo de esta unidad.
Figura 2. Visión detallada de la arquitectura de un servidor de Oracle 10G
Apartado 1.2: Bases de datos en varias instancias En Oracle 10g toda BBDD en ejecución está siempre asociada con una instancia. Sin embargo Oracle también permite que varias instancias estén asociadas a una misma BBDD (ver Figura 3). Esto se consigue con la opción Real Application Cluster (RAC) que incorpora Oracle 10g, la cual aprovecha las arquitecturas cluster y permite que varias instancias compartan una única BBDD física. De este modo, los usuarios de varias máquinas pueden acceder a una única BBDD con una mejora sustancial del rendimiento.
Figura 3. BBDD con varias instancias
Apartado 1.3: Las transacciones En Oracle 10g los cambios en la BBDD no son guardados inmediatamente
en
las
estructuras
físicas
de
almacenamiento.
Estas
modificaciones son tomadas como provisionales hasta que el SGBD recibe la instrucción de hacerlas definitivas. En Oracle esto se consigue gracias a la utilización de transacciones. El término transacción describe a una unidad lógica de trabajo que está compuesta de una o más sentencias SQL, que deben terminar con una instrucción commit (validación) o rollback (vuelta atrás). En ese instante, una nueva transacción dará comienzo y estará activa hasta que se ejecute alguno de esos dos comandos otra vez. Esta validación o vuelta atrás puede ser explicita, expresada por el usuario, o implícita, realizada por Oracle. Oracle admite además el uso de puntos de ruptura (checkpoints) para almacenar valores intermedios y volver a cualquier de ellos si interesa. La utilización de las transacciones permite maximizar la productividad, ya que controla el acceso concurrente por parte de varios usuarios a la información almacenada en la BBDD.
Conclusión En esta lección se ha descrito la arquitectura de un Sistema Gestor de Base de Datos (SGBD) Oracle 10g, comentando los componentes más importantes de la misma. Además se ha comentado la utilización compartida de las instancias para un misma BBDD y el concepto de transacción dentro de Oracle 10g. Para ampliar las ideas incluidas en esta lección, se recomienda consultar la bibliografía propuesta para esta unidad didáctica.
Lección 2
La instancia Oracle (I)
Índice 2. La instancia Oracle (I) 2.1. Estructuras de memoria 2.2. El Área Global de Programas (PGA) 2.3. Área SQL privada 2.4. El Área Global del Sistema (SGA)
Introducción Una instancia de Oracle 10g está compuesta por diversas zonas de memoria compartida y una serie de procesos. Esta lección se centra en el primero de estos componentes principales de la instancia de Oracle 10g: las estructuras de memoria. Al finalizar se incluyen una serie de ejercicios de auto evaluación para comprobar los conocimientos aprendidos.
Objetivos En esta lección aprenderás: -
Descripción del Área Global de Programas o PGA
-
Componentes de la PGA.
-
Descripción del Área Global del Sistema o SGA.
-
Componentes de la SGA.
Apartado 2.1: Estructuras de memoria Oracle crea y utiliza estructuras de memoria para llevar a cabo distintas tareas; como por ejemplo almacenamiento del código del programa que se está ejecutando o datos que pueden compartir los usuarios. Las estructuras básicas de memoria que utiliza una instancia Oracle son (ver Figura 4): •
Áreas Globales del Programa (PGA): Estructura de memoria que contiene datos e información de control de un proceso servidor. Asociadas en cierto grado a ellas, existen unas zonas que proporcionan
una
funcionalidad
adicional
para
operaciones
específicas. Se trata de las Áreas de Ordenamiento. •
Área Global del Sistema (SGA): Conjunto de estructuras de memoria compartida que contienen datos e información de control de una instancia Oracle.
Figura 4. Estructuras de memoria en Oracle 10g
Apartado 2.2: El Área Global de Programas (PGA) El Área Global del Programa (PGA) es un área de memoria que contiene datos e información de control para un proceso servidor. Cada vez que se arranca un proceso de servidor (por ejemplo, cuando se conecta un usuario), se crea una zona PGA. En este caso y a diferencia de la SGA, la información que contiene es estrictamente privada y no se comparte. Por tanto, las PGA pueden considerarse compartimentos estancos. El tamaño y la información que almacena esta área depende de la configuración que se haya elegido para la instancia, pero, en general puede clasificarse en dos categorías: el área SQL privada y la memoria de sesión. (ver Figura 5)
Figura 5. Estructura área de memoria PGA
Apartado 2.3: Área SQL privada Esta zona contiene información de las sentencias SQL que envían las sesiones cliente. A su vez, esta zona se divide en el área permanente (que contiene información de variables y sólo se libera al cerrar el cursor asociado a la sentencia) y el área de tiempo de ejecución, que se elimina cuando se finaliza la ejecución de la sentencia. Esta área se crea como primer paso en una solicitud de ejecución. Cuando se trata de una sentencia INSERT, UPDATE o DELETE, Oracle libera esta área al terminar la ejecución de la sentencia. Cuando se trata de una sentencia SELECT, la libera cuando la consulta ha terminado de suministrar filas o ha producido un error. El lugar en el que se encuentra esta área depende del modelo de servidor que se haya adoptado, servidor dedicado o servidor compartido. En los primeros, las áreas SQL privadas se almacenan en la PGA del proceso servidor, mientras que en los segundos, las áreas SQL privadas se almacenan en la porción Área Global del Usuario (UGA) de la SGA. Esto es debido a que la zona UGA se utiliza en lugar de la PGA en entornos compartidos.
1.
Memoria de sesión Ésta es la memoria asignada para almacenar variables de una sesión tales
como la información de conexión, y otra información asociada a la sesión. En el caso de los servidores compartidos, la memoria de sesión no es de tipo privado, sino que se almacena como información compartida.
2.
Áreas de Trabajo de SQL Ciertas aplicaciones realizan tareas con alto coste computacional, como
lecturas de múltiples filas para su posterior agrupación, ordenación y listado. Estas operaciones (explícitas o implícitas) utilizan éste área de trabajo para depositar los datos y organizarlos para su uso posterior.
Si el volumen de datos que tienen que utilizar estas áreas es demasiado elevado, los datos se dividen en fragmentos de menor volumen y, mientras un fragmento se procesa en memoria, el resto se almacena temporalmente en disco (lo que da lugar a los segmentos temporales de almacenamiento). Las operaciones que utilizan estas áreas de trabajo son las cláusulas ORDER BY y GROUP BY, la palabra clave DISTINCT para eliminar registros duplicados, la creación de índices con CREATE INDEX y, en general, cualquier operación que implique la ordenación de datos, como las combinaciones de tablas (que, según la estrategia adoptada, deben ordenar los datos de una para compararlos con los datos de otra, y así sucesivamente).
Apartado 2.4: 2.4: El Área Global del Sistema (SGA) El Área Global del Sistema es una zona compartida de la memoria que contiene datos e información de control de una instancia de Oracle. La SGA se distingue de otras estructuras de memoria en que la información que contiene se encuentra a disposición de todos los procesos (tanto de usuario como de servidor). Por lo tanto, a menudo se conoce la SGA como Área Global Compartida. Oracle 10g reserva automáticamente la memoria para su SGA cuando se arranca la instancia, al cerrar dicha instancia el sistema operativo vuelve a recuperar esta memoria. Para mejorar el rendimiento, la SGA debe ser tan grande como sea posible, sin desbordar la memoria física disponible y sin restarle memoria al sistema sobre el que se ejecuta, ya que cuanta más cantidad almacene, más se reduce la lectura/escritura en disco. El tamaño del SGA es uno de los puntos más críticos a la hora de mejorar el rendimiento de una BBDD, ya que, cuanto más memoria se reserve (mientras no sea memoria virtual), más rápidas se realizarán ciertas operaciones. Por ejemplo, las ordenaciones (una de las operaciones que más rápido deben hacerse) se realizan en el SGA si hay espacio suficiente. En caso contrario, se realizarán directamente en el disco, utilizando segmentos temporales. Los valores utilizados en los siguientes parámetros son los que tienen un mayor impacto en el tamaño del SGA: •
LARGE_POOL_SIZE
•
SHARED_POOL_SIZE
•
DB_CACHE_SIZE
•
LOG_BUFFER
La SGA es de lectura y escritura: es decir, todos los usuarios conectados a una instancia pueden leer la información que contiene la SGA, y varios procesos de la instancia escriben en la SGA durante el funcionamiento de Oracle. En realidad, la SGA no es un todo continuo: está dividida en distintas estructuras de memoria, las cuales se detallan a continuación (ver Figura 6)
Figura 6. Componentes de la zona SGA de la intancia de Oracle
1.
La caché de buffers. Almacena los bloques de datos utilizados recientemente (se hayan o no
confirmado sus cambios en el disco). Al utilizarse este buffer se reducen las operaciones de entrada y salida y por esto se mejora el rendimiento.
2.
El buffer de redo log. Guarda los cambios efectuados en la BBDD. Estos buffers escriben en el
archivo físico de redo tan rápido como se pueda sin perder eficiencia. Este último archivo se utiliza para recuperar la BBDD ante eventuales fallos del sistema.
1. El área conjunto compartido. Esta área almacena estructuras de memoria compartida, tales como las áreas de código SQL compartido e información interna del diccionario. Una cantidad insuficiente de espacio asignado a esta área podría redundar en problemas de rendimiento. En resumen, contiene las áreas del caché de biblioteca y del caché del diccionario de datos (DD).
2. La caché de biblioteca Se utiliza para almacenar código SQL compartido. Aquí se manejan los árboles de parsing utilizados para analizar las sentencias SQL y el plan de ejecución de las mismas. Si varias aplicaciones utilizan una misma sentencia SQL, esta área compartida garantiza el acceso por parte de cualquiera de ellas en cualquier instante.
3. La caché del Diccionario de Datos Almacena las últimas definiciones de la BBDD utilizadas (tablas, índices, privilegios, usuarios, etc). Cada vez que una sentencia utiliza un objeto de la BBDD (tabla, índice,...) se comprueba en el Diccionario de Datos y se almacena en este caché. De este modo la siguiente vez no hace falta acceder al diccionario real.
Conclusión En esta lección se ha descrito el primero de los elementos principales de la instancia de Oracle, las estructuras de memoria. Además se ha detallado cada uno de los componentes en lo que se desglosan estas zonas. Para ampliar las ideas incluidas en esta lección, se recomienda consultar la bibliografía propuesta para esta unidad didáctica.
Lección 3
La instancia Oracle (II)
Índice 3.1. Los procesos 3.2. Procesos de Usuario (cliente) 3.3. Procesos de Oracle
Introducción Introducción Una instancia de Oracle 10g está compuesta por diversas zonas de memoria compartida y una serie de procesos. Esta lección se centra en el segundo de estos componentes principales de la instancia de Oracle 10g: los procesos. Al finalizar se incluyen una serie de ejercicios de auto evaluación para comprobar los conocimientos aprendidos.
Objetivos En esta lección aprenderás: -
Definición e importancia de los procesos de usuario dentro del SGBD.
-
Definición e importancia de los procesos de Oracle, que se dividen a su vez en: o Los procesos de servidor o Los procesos en segundo plano o background.
Apartado 3.1: Los procesos Los procesos son hilos de trabajo del sistema operativo capaces de ejecutar una serie de tareas, que requieren una zona de memoria privada en la cual ejecutarse. Oracle 10g utiliza distintos tipos de procesos. Por un lado, emplea múltiples procesos especializados que ejecutan tareas muy concretas del servidor. A estos hay que sumar una serie de procesos destinados a los usuarios (bien uno por usuario, o bien uno o más que comparten varios usuarios). Gracias a esta especialización de los procesos, los servidores Oracle 10g permiten que se conecten al mismo tiempo múltiples usuarios y aplicaciones sin pérdida de rendimiento. En función de las necesidades, la instancia Oracle 10g, puede configurarse para que un proceso de usuario sea atendido mediante un proceso de servidor dedicado, o bien para que varios procesos de usuario sean atendidos mediante uno o varios procesos de servidor compartidos.
Apartado 3.2: Procesos de usuario (cliente) Los procesos de usuario se crean y mantienen para ejecutar el código generado por una aplicación externa al SGBD, o de una herramienta Oracle (como el Oracle Enterprise Manager). Cuando un usuario establece una conexión, está abriendo una vía de comunicación entre su proceso de usuario y la instancia Oracle. (ver Figura 7). Si la aplicación cliente se encuentra en el mismo equipo que la instancia (es decir, se produce una conexión local), esta vía de comunicaciones se genera mediante mecanismos de comunicación entre procesos o IPC. Si el equipo en el que se ejecuta la aplicación es distinto del servidor en el que reside la instancia, la comunicación se establece a través del software de red. Una vez establecida una conexión, se crea una sesión. Ésta puede definirse como la conexión que establece un usuario con una instancia Oracle a través de un proceso de usuario, facilitando para ello credenciales de seguridad. La sesión dura desde el momento de la conexión hasta que el proceso de usuario deja de atenderla, y un único usuario puede establecer múltiples sesiones, cada una con un proceso de usuario distinto.
Apartado 3.3: Procesos de Oracle Los procesos de Oracle llevan a cabo tareas en nombre de otros procesos. Estos se dividen en procesos de servidor y procesos en segundo plano. A continuación se describen los distintos tipos de procesos existentes en Oracle 10g y las funciones que desempeñan.
1. Procesos de servidor Oracle crea procesos de servidor para atender las peticiones de los procesos de usuarios que establecen una conexión con la instancia. Los procesos de servidor se comunican con el proceso de usuario, e interactúan con Oracle para desempeñar la tarea que les ha encargado el proceso de usuario correspondiente.
Figura 7. Comunicación entre proceso de usuario y proceso de servidor Aunque lo más corriente es que se ejecuten de forma independiente, en algunos sistemas los procesos de usuario y de servidor se combinan en un único proceso para reducir el coste de mantenimiento de ambos. Si se ha optado por la configuración de servidor compartido, o si los procesos de usuario y de servidor se ejecutan en distintas máquinas, están obligados a existir por separado. Los sistemas cliente/servidor separan los procesos de usuario y los de servidor y los ejecutan en distintas máquinas.
La misión de los procesos de servidor consiste en compilar y ejecutar sentencias SQL que envía la aplicación, trasladar los bloques de disco a memoria y devolver los resultados de la sentencia a la aplicación para que ésta los procese.
2. Procesos en segundo plano (background) Oracle arranca un conjunto de procesos en segundo plano para cada instancia. Éstos se encargan de desempeñar funciones que, de otro modo, habría que ejecutar mediante varios programas por cada proceso de usuario. Por tanto, los procesos en segundo plano agrupan funciones comunes, leen y escriben de forma asíncrona, supervisando los demás procesos de Oracle. A continuación, se enumeran y explican los distintos procesos en segundo plano que componen una instancia de Oracle.
Figura 8. Interacción de los procesos de servidor con las estructuras físicas de la arquitectura
DBWR (Database writer) Es el responsable de la escritura en disco de toda la información almacenada en los buffers de bloques que no se han actualizado. (ver Figura 8) DBWR se encarga de descargar los bloques modificados de la caché de BBDD en los ficheros de datos. Además traslada los buffers sucios de la caché de BBDD a disco para que los procesos de usuario puedan encontrar buffers limpios donde depositar nuevos bloques. A medida que los procesos de usuario ensucian buffers, el número de buffers libres disminuye, por lo que si esta tendencia se prolongase finalmente los procesos de usuario no serían capaces de escribir en la caché. Para solucionarlo DBWR descarga esta zona de memoria de modo que los procesos de usuario encuentren buffers libres al tiempo que se mantienen en memoria los utilizados. En este proceso se eliminan de la caché
aquellos bloques más antiguos,
intentando así que no haya que volver a cargarlos en poco tiempo. En la mayoría de los sistemas, basta con un único proceso escritor, pero se pueden configurar más si se modifican datos con mucha frecuencia (aunque resultan poco eficientes en equipos con un solo procesador). El parámetro que controla el número de procesos de escritura a disco es db_writer-processes.
LGWR (log writer) Es el responsable de escribir información de forma secuencial desde el buffer de log hacia el fichero o archivo de redo. (ver Figura 8). LGWR escribe en el disco porciones contiguas completas del buffer de log. Esta escritura se produce ante situaciones como las que se enumeran a continuación: •
Cuando se confirma una transacción con COMMIT.
•
Cuando un tercio del buffer de redo está lleno.
•
Cuando el buffer de redo almacena más de un megabyte de registros de cambios.
•
Antes de que DBWR traslade los bloques modificados de la caché de BBDD a los ficheros de datos.
Debido a un protocolo interno, LGWR debe escribir a disco todos los registros de redo que afectan a un bloque antes de que DBWR descargue dicho bloque a disco. Por ello, si DBWR descubre que quedan registros por escribir, solicita a LGWR que realice la escritura a disco y sólo entonces descarga el bloque a disco de forma definitiva. Cuando un usuario confirma una transacción mediante COMMIT, el sistema le asigna un número de modificación del sistema (SCN). LGWR escribe este número en el fichero de redo junto con las entradas de redo asociadas a la transacción. Esto se hace para que las operaciones de recuperación puedan realizarse de forma sincronizada.
CKPT (checkpoint) Es el responsable de advertir al proceso DBWR de efectuar un proceso de actualización en el disco de los datos mantenidos en memoria, incluyendo los ficheros de datos y control (para registrar el checkpoint). (ver Figura 8). A determinados intervalos, todos los bloques modificados de la BBDD se escriben al tiempo en los ficheros de datos (tarea de la que se encarga el DBWR). Además este proceso actualiza los ficheros de datos y de control de la BBDD para indicar el punto de comprobación más reciente. Cualquier tarea de recuperación toma como referencia estos puntos de sincronía. En principio, una recuperación de instancia sólo recupera a partir del último checkpoint realizado, ya que en ese momento todos los datos se encontrarán almacenados en disco. Igualmente, todas las tareas de recuperación culminan en un checkpoint, que garantizan que la BBDD puede abrirse con garantías de coherencia.
SMON (system monitor) Levanta la instancia y recupera la BBDD después de un fallo. Limpia los segmentos temporales que han dejado de utilizarse y recupera las transacciones que pudieran haberse interrumpido debido a un fallo del sistema.
Cuando el
sistema se vuelve a recuperar SMON recupera estas transacciones. Además disminuye la fragmentación del sistema agrupando aquellas extensiones libres que existen dentro de la BBDD. Para ello se encarga de localizar extensiones vacías contiguas, es decir que físicamente se encuentren una junto a la otra, y las convierte en una única extensión más grande. Gracias a esto la asignación de espacio por parte del SGBD es más sencilla.
PMON (process monitor) Su misión es monitorizar los procesos del usuario y tomar acciones correctivas cuando alguno de ellos se interrumpe en forma repentina y no controlada, limpiando la caché y liberando los posibles recursos que pudieran estar
asignados
en
ese
momento.
También
es
responsable
por
el
restablecimiento de aquel proceso que se ha interrumpido bruscamente. Este proceso restaura las transacciones no validadas de los procesos de usuario que se abortan, liberando los bloqueos y los recursos de la SGA. Asume la identidad del usuario que ha fallado, liberando todos los recursos de la BBDD que estuviera utilizando, y anula la transacción cancelada. Tanto SMON como PMON se activan cada cierto tiempo para comprobar si se les necesita, y cualquier otro proceso puede invocarlos para que desempeñen su labor.
ARCH (archiver) La función de este proceso opcional es la de respaldar o copiar en otro destino la información almacenada en los archivos redo log cuando éstos se llenan o si existe una conmutación explícita (cambio forzado del fichero de redo utilizado). Este proceso está siempre activo cuando se ha establecido el modo ARCHIVELOG. Si el sistema no está operando en este modo se hace más difícil recuperar el sistema sin problemas después de un fallo general. (ver Figura 8). Pueden existir varios de estos procesos y aparecerían numerados de forma secuencia: ARC0, ARC1,… LGWR se encarga de lanzar un nuevo proceso ARCH cada vez que los procesos existentes no bastan para cubrir la demanda e informa de ello en el fichero de alerta. Si se conoce a priori que se va a producir una fuerte demanda de ficheros archivados, se pueden iniciar varios procesos mediante el parámetro de inicio log_archive_maxyrocesses o de forma dinámica con el comando ALTER SYSTEM. Sin embargo, esto último no es necesario ya que el sistema calcula automáticamente cuántos procesos ARCn necesita y los arranca a medida que la demanda lo exige.
RECO (recoverer) Este proceso opcional es usado en entornos de BBDD distribuidas. Su función es la de resolver transacciones distribuidas que están pendientes debido a un fallo de red o de sistema. Mediante intervalos de tiempo, el proceso RECO local intenta conectarse a las BBDD remotas y completar automáticamente el COMMIT o el ROLLBACK de transacciones distribuidas pendientes. Este proceso sólo se crea cuando la instancia permite transacciones distribuidas y el parámetro de inicio distributed_transactions es mayor que cero. En caso contrario, RECO no se arranca con la instancia.
Conclusión En esta lección se han explicado de forma detallada las estructuras físicas que componen la BBDD de Oracle 10g: ficheros de datos, control y redo. Además se han comentado las relaciones de las mismas con las estructuras lógicas de almacenamiento del SGBD. Por último se ha explicado la interacción existente con la instancia de Oracle, tanto con las zonas de memoria como los procesos. Para ampliar las ideas incluidas en esta lección, se recomienda consultar la bibliografía propuesta para esta unidad didáctica.
Lección 4
Base de Datos
Índice 4. Base de Datos 4.1.
Base de Datos
4.2.
Ficheros de Datos
4.3.
Ficheros de control
4.4.
Ficheros de Redo o Undo
Introducción En esta lección se detallarán las estructuras físicas que componen la BBDD de Oracle 10g: ficheros de datos, control y redo; así como su relación con las estructuras lógicas de almacenamiento y la instancia de Oracle. Al finalizar se incluyen una serie de ejercicios de auto evaluación para comprobar los conocimientos aprendidos.
Objetivos En esta lección aprenderás: -
Descripción detallada del concepto de BBDD en Oracle 10g.
-
Estructuras físicas dentro del SGBD y la relación existente con estructuras lógicas.
-
Interacción con la instancia de Oracle.
-
Utilización de los ficheros de datos dentro del SGBD.
-
Utilización del fichero de control dentro del SGBD.
-
Utilización de los ficheros de redo dentro del SGBD.
Apartado 4.1: Base de Datos Toda BBDD de Oracle 10g consta de una serie de estructuras físicas donde se almacenan los datos que debe consultar la instancia. Estas estructuras físicas, al igual los ficheros del sistema operativo, están almacenados en dispositivos "hardware" tangibles (cintas, discos duros y flexibles, etc...). Es el administrador de la BBDD el que se ocupa de gestionar este tipo de estructuras (añadir nuevos ficheros cuando se agota el espacio, etc), aunque los usuarios tendrán que tenerlas también en cuenta a la hora de optimizar el rendimiento de sus aplicaciones. En la Figura 9 pueden observarse los diferentes tipos de estructuras físicas que utiliza el SGBD Oracle.
Figura 9. Distribución de estructuras físicas en una base de datos Oracle 10g
Las estructuras lógicas se corresponden también con unidades de espacio, pero sus límites son independientes de la asignación de espacio física. Una tabla puede estar almacenada en varios ficheros distintos del sistema operativo. En esta unidad se tratarán las estructuras físicas, en las sucesivas las lógicas.
Apartado 4.2: Ficheros de Datos Un fichero de datos o datafile es la representación física de un espacio de tablas o tablespace (estructura lógica utilizada por Oracle para el almacenamiento de la información). Es en estos ficheros de datos donde se almacena físicamente la información del servidor Oracle 10g. Estos pueden tener cualquier nombre y extensión (siempre dentro de las limitaciones del sistema operativo), y puede estar localizado en cualquier directorio del disco duro, aunque su localización típica suele ser $ORACLE_HOME/Database. Es importante resaltar que toda BBDD Oracle debe tener asociado uno o más ficheros de datos. Además cada uno de estos sólo puede pertenecer a una BBDD. Oracle lee en estos ficheros de datos cuando es necesario, y deposita la información en el área de memoria destinada al efecto. Es decir, cuando se solicitan unos datos, estos se buscan en primer lugar en memoria por ser su acceso más rápido. Si no consigue localizarlos allí, se extraen de los ficheros de datos y se almacenan en memoria. Al modificar los datos, éstos no se escriben directamente en disco. Para reducir el impacto en el rendimiento que supondría acceder permanentemente al disco, los datos se almacenan en memoria y, posteriormente, se depositan de nuevo en sus ficheros correspondientes de una sola vez. Éste comportamiento se conoce como Escritura Diferida en la Base de Datos.
1. Identificación de los ficheros El sistema identifica los ficheros de datos mediante
dos
números,
uno
absoluto y otro relativo. El número absoluto de fichero es el número que identifica el fichero en el sistema. El número relativo de fichero es el número que identifica al fichero en el tablespace al que pertenece. Suele coincidir con el número absoluto, pero en sistemas con un número muy elevado de ficheros (a partir de 1023), el número relativo es distinto al absoluto. Ambos números pueden consultarse a través de la vista del DD: V$DATAFILE.
2. Número de ficheros El número de ficheros que pueden estar asociados a una sola BBDD Oracle viene limitado por el parámetro db_files. Este parámetro se especifica durante la creación de una BBDD y se almacena en el fichero init.ora. Este límite puede cambiarse posteriormente pero exige la detención de la instancia. Si se elige un valor muy reducido, no se podrán añadir nuevos ficheros sin tener que detener la instancia, mientras que si se asigna un valor muy elevado consumiremos memoria innecesariamente. Esto es debido a que el SGBD reserva espacio en memoria para almacenar información sobre los ficheros de datos. El valor mínimo que admite es 1, y el máximo depende del Sistema Operativo
(SO) sobre el que se ejecuta el SGBD. Esto es debido a que, a
menudo, los SO restringen el número de ficheros que un proceso puede mantener abiertos al mismo tiempo. Asimismo, también tienen límites en el número y magnitud de los mismos.
3.
Dimensiones de los ficheros de datos Inicialmente el tamaño de los ficheros de datos puede configurarse con las
dimensiones que se deseen, pero hay que tener en cuenta que una elección incorrecta de sus dimensiones puede afectar negativamente al rendimiento. Cuando se crea un datafile, este ocupará tanto espacio en disco como se haya indicado en su creación, aunque internamente esté vacío. Oracle hace esto para reservar espacio continuo en disco y evitar así la fragmentación. Conforme se vayan creando objetos en el tablespace al que pertenece ese fichero, se irá ocupando el espacio que creó inicialmente. Una opción a remarcar dentro de Oracle 10 g, es que los ficheros de datos pueden
configurarse
para
que
adquieran
espacio
(autoexténsibles) cuando la BBDD se queda sin espacio.
dinámicamente
Apartado 4.3: Ficheros de Control Toda BBDD Oracle 10g dispone de un fichero de control que contiene la información necesaria para validar la estructura de los ficheros que componen la misma y guiar su puesta en funcionamiento. Cada vez que se arranca la instancia, el fichero de control se utiliza para identificar la BBDD y los ficheros de redo que tienen que abrirse para poder utilizarla. Por tanto su existencia es fundamental ya que guía la operación de arranque de la BBDD. Si la configuración física se ha modificado, el fichero de control impide que se abra, ya que no puede garantizar que su contenido sea fiable. Sin embargo, esto no impide que se realicen cambios a la estructura de la BBDD; cada vez que se cambia su configuración básica mediante las sentencias administrativas apropiadas, Oracle modifica automáticamente el fichero de control. Las características principales de un fichero de control son: •
Son ficheros binarios asociados a una única BBDD que se crean al crear la BBDD y se abren cuando se arranca una instancia.
•
Abren la BBDD y permiten de esta forma el acceso.
•
Contiene el nombre y ubicación de los ficheros de datos y de redo o undo, el nombre, fecha de creación y última actualización de la BBDD.
•
Especifica el fichero de redo sobre el que se estaba escribiendo al cerrar la BBDD. Gracias a esto se conocen los cambios que quedan por aplicar para que los ficheros de datos se encuentren sincronizados.
No es editable y debe estar siempre accesible ya que el SGBD Oracle lo actualiza constantemente.
Finalmente comentar que se puede recuperar una BBDD después de un error sin contar con los ficheros de redo (aunque esto implicaría perder datos no sincronizados). Sin embargo no se podrá abrir sin un fichero de control, por esto resulta decisivo multiplexar este tipo de ficheros.
1.
Nombre y número de ficheros de control Debido a su importancia, es recomendable tener como mínimo dos ficheros
de control multiplexados, separadas las copias en varios discos para minimizar los riesgos de perdida. Esto presenta un problema asociado, la posible pérdida de rendimiento motivada por la actualización de todos los ficheros de control existentes al crearse los puntos de control (checkpoint). Los nombres de los ficheros de control y su ruta están especificados en el parámetro control_files del fichero init.ora. Para añadir un fichero de control nuevo se debe cerrar la BBDD, copiar el antiguo en el nuevo y añadir el nombre del nuevo fichero en el init.ora. Al arrancarla de nuevo estaremos ya trabajando con el añadido también.
Apartado 4.4: Ficheros de Redo o Undo Toda BBDD Oracle 10g debe disponer al menos de dos redo logs, también conocidos como ficheros de rehacer o ficheros de undo. Estos ficheros almacenan registros de redo (un grupo de registros que describen los cambios realizados en la BBDD). La función de los ficheros de redo es la de registrar todos los cambios aplicados a los datos. Si un fallo del sistema impidiera que los cambios realizados quedasen plasmados en los datafiles, estos cambios podrían reproducirse consultando los ficheros de rehacer, y no se perdería la información. Si los cambios se escribieran directamente en disco (con la consiguiente pérdida de rendimiento) y el soporte físico jamás sufriera deterioros, los ficheros de redo no serían necesarios. Sin embargo debido a que el entorno sobre el que se ejecuta el SGBD está sujeto a posibles fallos, se necesitan este tipo de estructuras para conseguir recuperar la BBDD frente a posibles fallos. Para que estos ficheros se encuentren protegidos a su vez, se recomienda multiplexarlos,
es
decir
escribir
la
información
en
varias
ubicaciones
simultáneamente.
1.
Comportamiento de los ficheros de redo Como ya se ha comentado, los ficheros de redo, almacenan registros de
redo (también llamados entradas de redo). Estos registran los datos necesarios para realizar el proceso de recuperación, reconstruyendo los cambios realizados sobre la BBDD.
Las entradas de redo se escriben primero en una zona específica de la memoria y, a medida que ésta se llena, el proceso LGWR se dedica a volcar la información en los ficheros de redo de forma secuencial. Cada vez que una transacción se confirma, todos los cambios asociados a ella se marcan con un número llamado número de modificación del sistema o SCN. En ocasiones, el buffer se llena antes de que se pueda confirmar transacción. En ese caso, las entradas de redo se vuelcan a disco transitoriamente y, si se descartan, es necesario borrarlas del disco. La BBDD necesita al menos dos ficheros de redo para asegurarse de que, aunque uno esté ocupado, el otro puede escribir la información de redo. Una vez escritos todos los ficheros, el sistema los recicla de forma circular. Es decir: cuando el fichero de redo actual se llena, el proceso de escritura de logs (LGWR) comienza a escribir en el siguiente fichero y, cuando el último se llena, regresa al primero y borra toda la información que contuviera. El proceso de escritura en los ficheros de redo se ilustra a continuación:
Figura 10. Comportamiento de los ficheros de redo Cuando se cambia de fichero en el que se escribe se produce una conmutación de fichero. Esta puede ser también realizada de forma explícita, forzando esta conmutación mediante la instrucción ALTER SYSTEM SWITCH LOGFILE. Por otro lado cuando se comienza a escribir en un fichero el SGBD le asigna un número secuencial ascendente conocido como secuencia. Este es útil durante el proceso de recuperación para conseguir realizar una reparación ordenada de la información.
2.
Modos de funcionamiento de los ficheros de redo Oracle 10g sólo escribe en un fichero de redo cada vez. El fichero en el
que se escribe en cada momento se conoce como el fichero de redo actual. Los ficheros que se necesitarían para una recuperación de instancia se llaman ficheros de redo activos mientras los que ya no son necesarios se llaman ficheros de redo inactivos. Los ficheros de redo dentro de una BBDD Oracle se pueden utilizar de dos formas: •
Modo archivelog: Se almacenan los ficheros de redo cuando se llenan. En este modo el SBGD no puede sobrescribir los ficheros de redo activos hasta que han sido archivados.
•
Modo noarchivelog: Cuando se llena el último fichero de redo el sistema sobrescribe el primer fichero activo disponible. Es decir se reescriben los ficheros sin realizar copia alguna en otro sitio. En este modo la recuperación de la BBDD tras un fallo puede no ser total debido a que es posible que se hayan perdido cierta información acerca de los cambios realizados.
Multiplexación La multiplexación consiste en generar varias copias de los ficheros de redo donde se escribe al mismo tiempo. Oracle recomienda esta estrategia, ya que aumenta la protección de la BBDD frente a fallos. Los ficheros idénticos que se escriben al mismo tiempo forman grupos de redo en los cuales cada fichero es un miembro del mismo. Todos los miembros de un grupo comparten las mismas características de tamaño, se escribe en ellos al mismo tiempo y se encuentran activos simultáneamente. El proceso LGWR nunca escribe simultáneamente en miembros de grupos distintos.
Figura 11. Ficheros redo log multplexados Cada grupo de redo se define por un número secuencial, grupo 1, grupo, y así sucesivamente. En la Figura 11, los ficheros Log 1 y Log 3, pertenecen al grupo 1, mientras que Log 2 y Log 4 son miembros del grupo 4. Recordar que cada miembro de un grupo tiene que tener el mismo tamaño. Si el proceso de escritura en los ficheros de redo detecta un problema en los ficheros, siempre escribe un error en el fichero de traza del proceso y en el fichero
de
alerta
de
la
BBDD
(ambos
ubicados
en
el
directorio
admin\SID\bdump), pero su reacción depende del tipo fallo. Si se puede escribir al menos en uno de los miembros del grupo, LGWR continúa con normalidad, ignorando a los miembros no disponibles. Sin embargo, si LGWR no puede pasar al siguiente grupo porque éste todavía no se archivado, la BBDD no sigue realizando cambios hasta que se termina de archivar grupo y vuelve a disponer de él. Finalmente, si todos los miembros de un grupo están dañados y quedan inaccesibles, Oracle 10g detiene la instancia y procede a la recuperación de la BBDD.
Ubicación de los ficheros de redo Para aumentar la funcionalidad de la multiplexación se recomienda que, si se dispone varios discos duros, cada miembro de un grupo se almacene en un disco diferente. De es modo, si falla un disco sólo queda inaccesible un miembro del grupo y LGWR continua funcionando. Asimismo, si se activa el modo de archivado se debe intentar que no exista contención entre el proceso LGWR (que escribe en los ficheros) y el proceso ARCn (que lee los ficheros), por lo que se debería guardar los archivados en otro disco distinto. Igualmente se recomienda que los ficheros de redo se coloquen en un disco distinto de los ficheros datos por dos motivos. Por un lado, para reducir la contención de escritura, ya que escriben bloques de datos y entradas de redo al mismo tiempo. Por otro lado, porque si daña el disco que contiene los datos necesitaremos unos ficheros de redo en perfecto estado para recuperar los datos.
Número y dimensiones de los ficheros de redo Al planificar las dimensiones de los ficheros de redo, se deben tener en cuenta varios aspectos. Uno de ellos es si se van a archivar copias de los ficheros de redo (modo archivelog). Si es así, los ficheros deben tener unas dimensiones adecuadas para aprovechar el espacio disponible en el destino que se dé a sus copias (esto es especialmente importante si se envía los archivados a dispositivos de cinta). Si se multiplexan los ficheros de redo, todos los miembros de un grupo tienen el mismo tamaño y, aunque es posible, no es razonable que los ficheros de grupos distintos tengan dimensiones diferentes, ya que las conmutaciones se producirían de forma imprevisible. Respecto al número de grupos y ficheros, es algo que debe sopesarse y probarse. Por lo general, es preferible tener el menor número posible de grupos, pero es recomendable consultar con frecuencia el fichero de traza de LGWR para comprobar si es habitual que espere a un grupo porque no se ha producido un checkpoint o un archivado. Si es así, hay que añadir grupos.
El límite de grupos para la BBDD y el límite de miembros para cada grupo se
establece
con
la
cláusula
MAXLOGFILES
y
MAXLOGMEMBERS
respectivamente de la sentencia CREATE DATABASE (es decir, el límite hay que evaluarlo antes de crear la BBDD). Para eliminar este límite se tendría que volver a crear la BBDD o su fichero de control.
Información de estado de los ficheros de redo Para conocer las propiedades y estado de un fichero de redo, se puede consultar la vista V$LOGFILE. Ésta muestra los grupos y miembros de cada grupo de redo. La columna STATUS muestra el estado en que se encuentra el miembro en cuestión. Si el valor es INVALID, Oracle 10g no puede acceder a él, mientras que STALE significa que el SBGD sospecha que pueda no estar completo o correcto (volverá a ser válido la próxima vez que se active el grupo). Si el valor es nulo (aparece en blanco), el fichero de redo se está utilizando en este momento.
Figura 12. Ejemplo de consulta a la vista V$LOGFILE Para consultar la información sobre ficheros de redo que guarda el fichero de control, se puede consultar la vista V$LOG, que facilita información como, por ejemplo, los SCN que contiene cada fichero, fechas de modificación, etc.
Figura 13. Ejemplo de consulta a la vista V$LOG
Por último, para conocer la historia de las conmutaciones que se han producido en el sistema (información que utilizará el propio SGBD durante la recuperación del medio físico), se puede utilizar la vista V$LOG_HISTORY.
Figura 14. Ejemplo de consulta a la vista V$LOG_HISTORY
En resumen las características principales de los ficheros de Redo son: •
Permite proteger la BBDD ante caídas del sistema o fallos de los dispositivos.
•
Almacena cambios si no se han escrito en los ficheros de la BBDD para realizar recuperaciones.
•
Deben existir dos o más ficheros (uno debe estar disponible para escritura mientras que se va guardando el otro). Al llenarse uno se tiene que abrir el otro (conmutación de log).
•
Siempre tiene que haber un fichero accesible para escritura, si no es así la BBDD se parará y devolverá error.
Conclusión En esta lección se han explicado de forma detallada las estructuras físicas que componen la BBDD de Oracle 10g: ficheros de datos, control y redo. Además se han comentado las relaciones de las mismas con las estructuras lógicas de almacenamiento del SGBD. Por último se ha explicado la interacción existente con la instancia de Oracle, tanto con las zonas de memoria como los procesos. Para ampliar las ideas incluidas en esta lección, se recomienda consultar la bibliografía propuesta para esta unidad didáctica.
Lección 5
Diccionario de Datos
Índice 5.1. Diccionario 5.2. Uso del Diccionario de datos 5.3. Tipos de vistas en el Diccionario de Datos 5.4. Tablas dinámicas de rendimiento 5.5. Actualización de la información del diccionario de datos
Introducción En esta lección se da a conocer el concepto de Diccionario de Datos. Se detallará su composición, funcionamiento y las ventajas que aporta al SGBD. Al finalizar se incluyen una serie de ejercicios de auto evaluación para comprobar los conocimientos aprendidos.
Objetivos En esta lección aprenderás: -
Descripción y utilización del Diccionario de Datos (DD).
-
Tipos de Vistas dentro del DD.
-
Descripción y utilización de las tablas dinámicas de rendimiento.
Apartado 5.1: 5.1: Diccionario Oracle cuenta con una serie de tabla y vistas, de solo lectura, que conforman una estructura denominada catálogo o diccionario de datos (DD). EL DD es generado automáticamente cuando la BBDD es creada. Para reflejar con exactitud el estado de la BBDD en todo momento, el diccionario es actualizado por Oracle, de forma transparente para el usuario, en respuesta a acciones específicas. El proceso de creación del diccionario puede resumirse en los siguientes puntos: •
Se define el tablespace SYSTEM
•
Se definen las tablas del DD.
•
Se cargan los datos en las tablas del diccionario.
•
Se crean las vistas del DD.
•
Se crean los sinónimos.
•
Se le concede al usuario PUBLIC acceso sobre los sinónimos.
La principal función del catálogo de Oracle es almacenar toda la información
de
la
estructura
lógica
y
física
de
la
BBDD,
es
decir,
almacena definiciones de todos los esquemas existentes en la BBD (tablas, índices, vistas, clusters, sinónimos, secuencias, procedimientos, funciones, paquetes, triggers,etc). De forma más detallada la información que aporta el DD al SGBD es la siguiente: •
Objetos de la BBBD (tablas, vistas, agrupamientos, sinónimos, etc...).
•
Espacio asignado y actualmente ocupado por un esquema u objeto.
•
Usuarios de la BBDD.
•
Privilegios y roles que cada usuario tiene sobre los objetos.
•
Información sobre quienes han accedido y actualizado esquemas.
•
Información general de la BBDD.
Apartado 5.2: Uso del Diccionario de Datos Tanto los usuarios como el administrador pueden consultar información en el DD, utilizando para ello la sentencia SELECT con cualquiera de sus opciones. Sin embargo el administrador no debe modificar nunca ninguna tabla mediante el lenguaje de manipulación de datos (INSERT, UPDATE, DELETE) puesto que podrían aparecer errores fatales (sólo podrá modificar filas de la tabla de auditoría). El DD reside en el espacio de tablas SYSTEM y estará disponible siempre que la BBDD lo esté. El SGBDR es el que se encarga de actualizar el diccionario de datos cuando se ejecuta una sentencia de definición de datos, de control de datos o de manipulación de datos que implique la asignación de una nueva extensión (estructura lógica de almacenamiento de Oracle 10g). El diccionario se almacena en memoria principal (SGA) para que el sistema lo pueda consultar con mayor rapidez y aumentar de esta forma el rendimiento. Los parámetros de almacenamiento del diccionario están indicados en el fichero init.ora y comienzan todos por DC_*. Cuando no hay espacio para todos los objetos del diccionario en memoria principal se traspasarán a memoria secundaria los que lleven más tiempo sin ser referenciados (algoritmo conocido LRU o Least Recently Used).
Apartado Apartado 5.3: Tipos de vistas en el Diccionario de Datos Las vistas del DD se dividen en cuatro grandes grupos según el prefijo que lleven, lo que aporta una pequeña indicación del tipo de información contenida en cada una: •
USER_* : Se refieren a los objetos creados por un usuario en concreto o los privilegios concedidos por él.
•
ALL_* : Se refieren a los objetos creados por el usuario y a los que puede acceder porque se le han concedido privilegios de acceso.
•
DBA_* : Sólo las puede consultar los usuarios con privilegios de administrador puesto que contienen información general de la BBDD.
•
V_$ ó V$: Vistas dinámicas sobre datos de rendimiento.
El usuario SYS es propietario de las tablas del DD, en las que se almacena información sobre el resto de las estructuras de la BBDD. Existe una tabla de catálogo para cada tipo de objeto posible. Su nombre aparecerá en plural TABLES, VIEWS, SEQUENCES, TABLESPACES, etc. Algunos ejemplos son: •
DBA_TABLES: Información para administradores de las tablas en BBDD.
•
USER_VIEWS: Información de las vistas creadas por el usuario desde el que accedemos.
•
ALL_SEQUENCES: Información de todas las secuencias existentes en BBDD.
•
DBA_TABLESPACES:
Información
de
administración
sobre
los
tablespaces. •
USER_TAB_COLUMNS: Todas las columnas de tabla en el usuario activo.
•
DICTIONARY y DICT_COLUMNS: Proporcionan información sobre las tablas y vistas del DD de Oracle.
Las vistas del diccionario se crean en base a las tablas evitando así que las tablas sean accedidas directamente por los usuarios, que podrán obtener información del diccionario a través de las vistas. El usuario SYS es el propietario de las vistas del diccionario de datos que se crean durante la instalación y sobre las cuales se les concede derecho de acceso al usuario PUBLIC.
Apartado 5.4 Tablas dinámicas de rendimiento Registran la actividad de la BBDD y se visualizan con la herramienta del administrador MONITOR. Se utilizan para controlar y ajustar la BBDD, No son tablas reales y por ello no deberían ser utilizadas por ningún usuario que no sea DBA. Los administradores podrán crear vistas a su medida para visualizar el rendimiento del sistema en un instante determinado. Pertenecen al usuario SYS, y las tablas contienen el prefijo V_$ y las vistas el prefijo V$.
Apartado 5.5: Actualización de la información del Diccionario de Datos Al llegar a este punto es lógico pensar que ciertos datos del catálogo de Oracle son continuamente actualizados, debido a la frecuencia de las operaciones que modificar el contenido del DD. Por ejemplo en las vistas dinámicas, sus datos no se almacenan en disco, sino que son tablas sobre datos contenidos en la memoria del servidor, por lo que almacenan datos actualizados en tiempo real. Sin embargo, otros datos como el número de registros de una tabla, tamaño de los objetos, etc, no pueden actualizarse de esta forma porque reducirían el rendimiento de la BBDD. Si se quiere actualizar el catálogo de este tipo de datos, es posible hacerlo utilizando la sentencia especial: ANALYZE[TABLE|INDEX]nombre[COMPUTE|ESTIMATE|DELETE] STATISTICS; Esta sentencia se encarga de volcar la información recopilada al catálogo. Sus opciones son las siguientes: •
Compute: Hace un cálculo exacto de la estadísticas.
•
Estimate: Realiza una estimación partiendo del anterior valor calculado y de un posible factor de variación y la cláusula.
•
Delete: Borra las anteriores estadísticas.
Conclusión En esta lección se ha comentado el concepto de Diccionario de Datos, su composición, funcionamiento y las ventajas que aporta al SGBD. Para ampliar las ideas incluidas en esta lección, se recomienda consultar la bibliografía propuesta para esta unidad didáctica.
Conclusión General General Al finalizar esta unidad didáctica has debido
comprender aspectos
fundamentales relativos al modelo físico de un SGBD Oracle 10g. Los puntos más importantes tratados han sido: •
Descripción de la arquitectura Oracle 10g.
•
Componentes de una Instancia de Oracle.
•
Componentes de una BBDD.
•
Descripción y utilización del Diccionario de Datos (DD).
Los ejercicios resueltos y de autoevaluación incluidos en esta unidad te habrán ayudado a poner en práctica los conocimientos aprendidos. En caso de querer ampliar las ideas tratadas, se recomienda consultar la bibliografía propuesta para esta unidad.
Glosario de términos ARCH
Archiver.
BBDD
Base de Datos.
CKPT
CheckPoint.
DBWR
Database Writer.
DD
Diccionario de Datos.
IPC
InterProcess Communication.
LGWR
Log Writer.
LMD
Lenguaje Manipulación de Datos.
LRU
Least Recently Used (Menos Usado Recientemente)
PGA
Program Global Area (Aea Global de Programas).
PMON
Process Monitor.
RAC
Real Application Cluster.
RECO
Recoverer.
SCN
System Change Number (Número de Modificación del Sistema)
SGA
System Global Area (Áreal Global del Sistema).
SGBD
Sistema de Gestión de Base de Datos.
SMON
System Monitor.
SO
Sistema Operativo.
SQL
Structured Query Language (Lenguaje de Consulta Estructurado)
Bibliografía •
[Abramson, I., 2004]. Oracle database 10g : guía de aprendizaje. Capítulo 1.
•
[Arun Kumar R., 2005]. Oracle® Database 10g Insider Solutions. Sams Publishing. Capítulo 1.
•
[Dawes,C. & Bryla, B., 2004] OCA: Oracle 10g Administration I Study Guide. Sybex. Capítulo 1.
•
[Greenwald, R. & Stackowiak, R., 2004]. Oracle Essentials, 3e: Oracle Database 10g. Capítulo 2, 4 & 11.
•
[Kreines, D. C., 2003]. Oracle Data Dictionary, Pocket Reference.
•
[Kyte, T., 2005]. Expert Oracle Database Architecture: 9i and 10g Programming Techniques and Solutions. Apress. Capítulo 2, 3, 4, 5.
•
[Loney, K., 2004]. Oracle Database 10g: The Complete Reference. Capítulo 1.
•
[Oracle, 10g
2006].
Release
2
Oracle® (10.2).
Database Parte
I
&
Administrator's II.
(url:
Guide
http://download-
uk.oracle.com/docs/cd/B19306_01/server.102/b14231/toc.htm) •
[Oracle, 2006]. Oracle® Database Concepts 10g Release 2 (10.2). (url: http://download-uk.oracle.com/docs/cd/B19306_01/server.102/b14220/toc.htm ).
•
[Perez, C., 2005]. Oracle 10g: administración y análisis de bases de datos. Capítulo 14.
