Unidad Didctica 2

Introduccin al Modelo Fsico

del SGBD Oracle 10g
 UNIDAD
Introduccin al Modelo Fsico del SGBD Oracle
DIDCTICA 2
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 dinmicas de rendimiento
5.5. Actualizacin de la informacin del diccionario de datos
Esquema de contenidos:
Introduccin

El servidor Oracle 10g es un Sistema Gestor de Base de Datos (SGBD)

objeto-relacional que permite administrar la informacin que almacena de manera
sencilla y completa.

El modelo fsico 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. Adems se describir el concepto de Diccionario de Datos en Oracle 10g,
as como su funcin dentro del SGBD.

Al finalizar cada leccin se plantearn una serie de ejercicios prcticos que

inciden en los conceptos presentados y refuerzan su aprendizaje, intentar su
resolucin y trabajarlos es primordial para conseguir los objetivos fijados en esta
unidad.
Objetivos

En esta unidad aprenders:

- 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

- Descripcin y utilizacin del Diccionario de Datos (DD).

Leccin 1 Arquitectura de Oracle 10g

ndice

1.1. Arquitectura
1.2. Bases de datos en varias instancias
1.3. Las transacciones

Introduccin

En esta leccin se describe la arquitectura de un SGBD Oracle 10g. En

segundo lugar se introducen los componentes ms importantes de la misma, se
explica la posible utilizacin compartida de las instancias y se describe el
concepto de transaccin.

Al finalizar se incluyen una serie de ejercicios de auto evaluacin para

comprobar los conocimientos aprendidos.

Objetivos

En esta leccin aprenders:

- La arquitectura del SGBD Oracle 10g.

- Los componentes principales de cada parte de la arquitectura.

o Descripcin del concepto de BBDD en Oracle 10g

o Descripcin del concepto instancia en Oracle 10g

- La utilizacin compartida de las instancias.

- El concepto de transaccin.
Apartado 1.1: Definicin 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 informacin. La BBDD se compone de estructuras
lgicas (tablespaces, segmentos, extensiones y bloques) y fsicas
(ficheros de datos, control y redo). Ambas se gestionan por
separado, por lo que el aspecto fsico puede manipularse sin
afectar al acceso a las estructuras lgicas.

Instancia: Cada vez que se desea facilitar el acceso a una BBDD,

se reserva una porcin 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 gestin
de una BBDD conforman la instancia de Oracle 10g.

Figura 1. Visin 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 interaccin de los diferentes
componentes se explicar a lo largo de esta unidad.

Figura 2. Visin 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 ejecucin est siempre asociada con una
instancia. Sin embargo Oracle tambin permite que varias instancias estn
asociadas a una misma BBDD (ver Figura 3).

Esto se consigue con la opcin Real Application Cluster (RAC) que

incorpora Oracle 10g, la cual aprovecha las arquitecturas cluster y permite que
varias instancias compartan una nica BBDD fsica. De este modo, los usuarios
de varias mquinas 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 fsicas de almacenamiento. Estas
modificaciones son tomadas como provisionales hasta que el SGBD recibe la
instruccin de hacerlas definitivas.

En Oracle esto se consigue gracias a la utilizacin de transacciones. El

trmino transaccin describe a una unidad lgica de trabajo que est
compuesta de una o ms sentencias SQL, que deben terminar con una
instruccin commit (validacin) o rollback (vuelta atrs). En ese instante, una
nueva transaccin dar comienzo y estar activa hasta que se ejecute alguno
de esos dos comandos otra vez.

Esta validacin o vuelta atrs puede ser explicita, expresada por el

usuario, o implcita, realizada por Oracle.

Oracle admite adems el uso de puntos de ruptura (checkpoints) para

almacenar valores intermedios y volver a cualquier de ellos si interesa.

La utilizacin de las transacciones permite maximizar la productividad, ya que

controla el acceso concurrente por parte de varios usuarios a la informacin
almacenada en la BBDD.
Conclusin
En esta leccin se ha descrito la arquitectura de un Sistema Gestor de
Base de Datos (SGBD) Oracle 10g, comentando los componentes ms
importantes de la misma.

Adems se ha comentado la utilizacin compartida de las instancias para

un misma BBDD y el concepto de transaccin dentro de Oracle 10g.

Para ampliar las ideas incluidas en esta leccin, se recomienda consultar la

bibliografa propuesta para esta unidad didctica.
Leccin 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)

Introduccin
Una instancia de Oracle 10g est compuesta por diversas zonas de
memoria compartida y una serie de procesos.

Esta leccin 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 evaluacin para

comprobar los conocimientos aprendidos.

Objetivos

En esta leccin aprenders:

- Descripcin del rea Global de Programas o PGA

- Componentes de la PGA.

- Descripcin 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 cdigo del programa que se est
ejecutando o datos que pueden compartir los usuarios.

Las estructuras bsicas de memoria que utiliza una instancia Oracle son
(ver Figura 4):

reas Globales del Programa (PGA): Estructura de memoria que

contiene datos e informacin de control de un proceso servidor.
Asociadas en cierto grado a ellas, existen unas zonas que
proporcionan una funcionalidad adicional para operaciones
especficas. Se trata de las reas de Ordenamiento.

rea Global del Sistema (SGA): Conjunto de estructuras de memoria

compartida que contienen datos e informacin 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 informacin 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 informacin que
contiene es estrictamente privada y no se comparte. Por tanto, las PGA pueden
considerarse compartimentos estancos.

El tamao y la informacin que almacena esta rea depende de la

configuracin que se haya elegido para la instancia, pero, en general puede
clasificarse en dos categoras: el rea SQL privada y la memoria de sesin. (ver
Figura 5)

Figura 5. Estructura rea de memoria PGA

Apartado 2.3: rea SQL privada
Esta zona contiene informacin de las sentencias SQL que envan las
sesiones cliente. A su vez, esta zona se divide en el rea permanente (que
contiene informacin de variables y slo se libera al cerrar el cursor asociado a la
sentencia) y el rea de tiempo de ejecucin, que se elimina cuando se finaliza la
ejecucin de la sentencia.

Esta rea se crea como primer paso en una solicitud de ejecucin. Cuando
se trata de una sentencia INSERT, UPDATE o DELETE, Oracle libera esta rea
al terminar la ejecucin 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 porcin 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 sesin
sta es la memoria asignada para almacenar variables de una sesin tales
como la informacin de conexin, y otra informacin asociada a la sesin. En el
caso de los servidores compartidos, la memoria de sesin no es de tipo privado,
sino que se almacena como informacin compartida.

2. reas de Trabajo de SQL

Ciertas aplicaciones realizan tareas con alto coste computacional, como
lecturas de mltiples filas para su posterior agrupacin, ordenacin y listado.
Estas operaciones (explcitas o implcitas) 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 clusulas
ORDER BY y GROUP BY, la palabra clave DISTINCT para eliminar registros
duplicados, la creacin de ndices con CREATE INDEX y, en general, cualquier
operacin que implique la ordenacin de datos, como las combinaciones de
tablas (que, segn 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 informacin de control de una instancia de Oracle. La SGA se
distingue de otras estructuras de memoria en que la informacin que contiene se
encuentra a disposicin 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 automticamente 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 fsica disponible y sin
restarle memoria al sistema sobre el que se ejecuta, ya que cuanta ms cantidad
almacene, ms se reduce la lectura/escritura en disco.

El tamao del SGA es uno de los puntos ms crticos a la hora de mejorar

el rendimiento de una BBDD, ya que, cuanto ms memoria se reserve (mientras
no sea memoria virtual), ms rpidas se realizarn ciertas operaciones. Por
ejemplo, las ordenaciones (una de las operaciones que ms rpido deben
hacerse) se realizan en el SGA si hay espacio suficiente. En caso contrario, se
realizarn directamente en el disco, utilizando segmentos temporales.

Los valores utilizados en los siguientes parmetros son los que tienen un
mayor impacto en el tamao 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 informacin 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 continuacin (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 fsico de redo tan rpido 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 cdigo SQL compartido e informacin interna del diccionario. Una
cantidad insuficiente de espacio asignado a esta rea podra 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 cdigo SQL compartido. Aqu se manejan los
rboles de parsing utilizados para analizar las sentencias SQL y el plan de
ejecucin 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.
Conclusin
En esta leccin se ha descrito el primero de los elementos principales de
la instancia de Oracle, las estructuras de memoria. Adems se ha detallado cada
uno de los componentes en lo que se desglosan estas zonas.

Para ampliar las ideas incluidas en esta leccin, se recomienda consultar

la bibliografa propuesta para esta unidad didctica.
Leccin 3 La instancia Oracle (II)

ndice

3.1. Los procesos

3.2. Procesos de Usuario (cliente)
3.3. Procesos de Oracle
Introduccin
Introduccin

Una instancia de Oracle 10g est compuesta por diversas zonas de

memoria compartida y una serie de procesos.

Esta leccin 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 evaluacin para

comprobar los conocimientos aprendidos.

Objetivos

En esta leccin aprenders:

- Definicin e importancia de los procesos de usuario dentro del

SGBD.

- Definicin 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 mltiples
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 ms que comparten varios usuarios). Gracias a esta
especializacin de los procesos, los servidores Oracle 10g permiten que se
conecten al mismo tiempo mltiples usuarios y aplicaciones sin prdida de
rendimiento.

En funcin 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 cdigo
generado por una aplicacin externa al SGBD, o de una herramienta Oracle
(como el Oracle Enterprise Manager).

Cuando un usuario establece una conexin, est abriendo una va de

comunicacin entre su proceso de usuario y la instancia Oracle. (ver Figura 7).

Si la aplicacin cliente se encuentra en el mismo equipo que la instancia (es

decir, se produce una conexin local), esta va de comunicaciones se genera
mediante mecanismos de comunicacin entre procesos o IPC. Si el equipo en el
que se ejecuta la aplicacin es distinto del servidor en el que reside la instancia, la
comunicacin se establece a travs del software de red.

Una vez establecida una conexin, se crea una sesin. sta puede
definirse como la conexin que establece un usuario con una instancia Oracle a
travs de un proceso de usuario, facilitando para ello credenciales de seguridad.
La sesin dura desde el momento de la conexin hasta que el proceso de usuario
deja de atenderla, y un nico usuario puede establecer mltiples 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
continuacin se describen los distintos tipos de procesos existentes en Oracle 10g
y las funciones que desempean.

1. Procesos de servidor
Oracle crea procesos de servidor para atender las peticiones de los
procesos de usuarios que establecen una conexin con la instancia. Los procesos
de servidor se comunican con el proceso de usuario, e interactan con Oracle
para desempear la tarea que les ha encargado el proceso de usuario
correspondiente.

Figura 7. Comunicacin entre proceso de usuario y proceso de servidor

Aunque lo ms 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
configuracin de servidor compartido, o si los procesos de usuario y de servidor
se ejecutan en distintas mquinas, estn obligados a existir por separado. Los
sistemas cliente/servidor separan los procesos de usuario y los de servidor y los
ejecutan en distintas mquinas.
 La misin de los procesos de servidor consiste en compilar y ejecutar
sentencias SQL que enva la aplicacin, trasladar los bloques de disco a memoria
y devolver los resultados de la sentencia a la aplicacin 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 desempear funciones que, de otro modo,
habra 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 asncrona, supervisando los dems procesos de Oracle.

A continuacin, se enumeran y explican los distintos procesos en segundo

plano que componen una instancia de Oracle.

Figura 8. Interaccin de los procesos de servidor con las estructuras

fsicas de la arquitectura
 DBWR (Database writer)
Es el responsable de la escritura en disco de toda la informacin
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. Adems 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 nmero de

buffers libres disminuye, por lo que si esta tendencia se prolongase finalmente los
procesos de usuario no seran 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 ms antiguos,
intentando as que no haya que volver a cargarlos en poco tiempo.

En la mayora de los sistemas, basta con un nico proceso escritor, pero se

pueden configurar ms si se modifican datos con mucha frecuencia (aunque
resultan poco eficientes en equipos con un solo procesador). El parmetro que
controla el nmero de procesos de escritura a disco es db_writer-processes.

LGWR (log writer)

Es el responsable de escribir informacin 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
continuacin:

Cuando se confirma una transaccin con COMMIT.

Cuando un tercio del buffer de redo est lleno.

 Cuando el buffer de redo almacena ms 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 slo entonces descarga el
bloque a disco de forma definitiva.

Cuando un usuario confirma una transaccin mediante COMMIT, el sistema

le asigna un nmero de modificacin del sistema (SCN). LGWR escribe este
nmero en el fichero de redo junto con las entradas de redo asociadas a la
transaccin. Esto se hace para que las operaciones de recuperacin puedan
realizarse de forma sincronizada.

CKPT (checkpoint)
Es el responsable de advertir al proceso DBWR de efectuar un proceso de
actualizacin 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).
Adems este proceso actualiza los ficheros de datos y de control de la BBDD para
indicar el punto de comprobacin ms reciente.

Cualquier tarea de recuperacin toma como referencia estos puntos de

sincrona. En principio, una recuperacin de instancia slo recupera a partir del
ltimo checkpoint realizado, ya que en ese momento todos los datos se
encontrarn almacenados en disco. Igualmente, todas las tareas de recuperacin
culminan en un checkpoint, que garantizan que la BBDD puede abrirse con
garantas de coherencia.
 SMON (system monitor)
Levanta la instancia y recupera la BBDD despus 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.

Adems disminuye la fragmentacin del sistema agrupando aquellas

extensiones libres que existen dentro de la BBDD. Para ello se encarga de
localizar extensiones vacas contiguas, es decir que fsicamente se encuentren
una junto a la otra, y las convierte en una nica extensin ms grande. Gracias a
esto la asignacin de espacio por parte del SGBD es ms sencilla.

PMON (process monitor)

Su misin 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. Tambin 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 transaccin cancelada.

Tanto SMON como PMON se activan cada cierto tiempo para comprobar si
se les necesita, y cualquier otro proceso puede invocarlos para que desempeen
su labor.
 ARCH (archiver)
La funcin de este proceso opcional es la de respaldar o copiar en otro
destino la informacin almacenada en los archivos redo log cuando stos se
llenan o si existe una conmutacin explcita (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 ms difcil
recuperar el sistema sin problemas despus de un fallo general. (ver Figura 8).

Pueden existir varios de estos procesos y apareceran 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 parmetro
de inicio log_archive_maxyrocesses o de forma dinmica con el comando ALTER
SYSTEM. Sin embargo, esto ltimo no es necesario ya que el sistema calcula
automticamente cuntos 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
funcin es la de resolver transacciones distribuidas que estn 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 automticamente el
COMMIT o el ROLLBACK de transacciones distribuidas pendientes.

Este proceso slo se crea cuando la instancia permite transacciones

distribuidas y el parmetro de inicio distributed_transactions es mayor
que cero. En caso contrario, RECO no se arranca con la instancia.
Conclusin
En esta leccin se han explicado de forma detallada las estructuras fsicas que
componen la BBDD de Oracle 10g: ficheros de datos, control y redo.

Adems se han comentado las relaciones de las mismas con las estructuras
lgicas de almacenamiento del SGBD.

Por ltimo se ha explicado la interaccin existente con la instancia de Oracle,

tanto con las zonas de memoria como los procesos.

Para ampliar las ideas incluidas en esta leccin, se recomienda consultar la

bibliografa propuesta para esta unidad didctica.
Leccin 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
Introduccin

En esta leccin se detallarn las estructuras fsicas que componen la BBDD

de Oracle 10g: ficheros de datos, control y redo; as como su relacin con las
estructuras lgicas de almacenamiento y la instancia de Oracle.

Al finalizar se incluyen una serie de ejercicios de auto evaluacin para

comprobar los conocimientos aprendidos.

Objetivos

En esta leccin aprenders:

- Descripcin detallada del concepto de BBDD en Oracle 10g.

- Estructuras fsicas dentro del SGBD y la relacin existente con

estructuras lgicas.

- Interaccin con la instancia de Oracle.

- Utilizacin de los ficheros de datos dentro del SGBD.

- Utilizacin del fichero de control dentro del SGBD.

- Utilizacin 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 fsicas donde
se almacenan los datos que debe consultar la instancia.

Estas estructuras fsicas, al igual los ficheros del sistema operativo, estn
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 (aadir nuevos ficheros cuando se agota el espacio, etc), aunque los
usuarios tendrn que tenerlas tambin en cuenta a la hora de optimizar el
rendimiento de sus aplicaciones.

En la Figura 9 pueden observarse los diferentes tipos de estructuras fsicas

que utiliza el SGBD Oracle.

Figura 9. Distribucin de estructuras fsicas en una base de datos Oracle

10g

Las estructuras lgicas se corresponden tambin con unidades de espacio,

pero sus lmites son independientes de la asignacin de espacio fsica. Una tabla
puede estar almacenada en varios ficheros distintos del sistema operativo.

En esta unidad se tratarn las estructuras fsicas, en las sucesivas las

lgicas.
Apartado 4.2: Ficheros de Datos
Un fichero de datos o datafile es la representacin fsica de un espacio de
tablas o tablespace (estructura lgica utilizada por Oracle para el almacenamiento
de la informacin). Es en estos ficheros de datos donde se almacena fsicamente
la informacin del servidor Oracle 10g. Estos pueden tener cualquier nombre y
extensin (siempre dentro de las limitaciones del sistema operativo), y puede
estar localizado en cualquier directorio del disco duro, aunque su localizacin
tpica suele ser $ORACLE_HOME/Database.

Es importante resaltar que toda BBDD Oracle debe tener asociado uno o
ms ficheros de datos. Adems cada uno de estos slo puede pertenecer a una
BBDD.

Oracle lee en estos ficheros de datos cuando es necesario, y deposita la

informacin 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 ms rpido. 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 supondra 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. Identificacin de los ficheros

El sistema identifica los ficheros de datos mediante dos nmeros, uno
absoluto y otro relativo. El nmero absoluto de fichero es el nmero que identifica
el fichero en el sistema. El nmero relativo de fichero es el nmero que identifica
al fichero en el tablespace al que pertenece. Suele coincidir con el nmero
absoluto, pero en sistemas con un nmero muy elevado de ficheros (a partir de
1023), el nmero relativo es distinto al absoluto. Ambos nmeros pueden
consultarse a travs de la vista del DD: V$DATAFILE.
2. Nmero de ficheros
El nmero de ficheros que pueden estar asociados a una sola BBDD
Oracle viene limitado por el parmetro db_files. Este parmetro se especifica
durante la creacin de una BBDD y se almacena en el fichero init.ora. Este
lmite puede cambiarse posteriormente pero exige la detencin de la instancia.

Si se elige un valor muy reducido, no se podrn aadir 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 informacin sobre los ficheros de
datos.

El valor mnimo que admite es 1, y el mximo depende del Sistema

Operativo (SO) sobre el que se ejecuta el SGBD. Esto es debido a que, a
menudo, los SO restringen el nmero de ficheros que un proceso puede
mantener abiertos al mismo tiempo. Asimismo, tambin tienen lmites en el
nmero y magnitud de los mismos.

3. Dimensiones de los ficheros de datos

Inicialmente el tamao de los ficheros de datos puede configurarse con las
dimensiones que se deseen, pero hay que tener en cuenta que una eleccin
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 creacin, aunque internamente est vaco. Oracle hace esto
para reservar espacio continuo en disco y evitar as la fragmentacin. Conforme
se vayan creando objetos en el tablespace al que pertenece ese fichero, se ir
ocupando el espacio que cre inicialmente.

Una opcin a remarcar dentro de Oracle 10 g, es que los ficheros de datos

pueden configurarse para que adquieran espacio dinmicamente
(autoextnsibles) cuando la BBDD se queda sin espacio.
Apartado 4.3: Ficheros de Control
Toda BBDD Oracle 10g dispone de un fichero de control que contiene la
informacin 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 gua la operacin de
arranque de la BBDD.

Si la configuracin fsica 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 configuracin bsica mediante las sentencias administrativas
apropiadas, Oracle modifica automticamente el fichero de control.

Las caractersticas 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 ubicacin de los ficheros de datos y de redo o

undo, el nombre, fecha de creacin y ltima actualizacin 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 despus de un
error sin contar con los ficheros de redo (aunque esto implicara 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 nmero de ficheros de control

Debido a su importancia, es recomendable tener como mnimo dos ficheros
de control multiplexados, separadas las copias en varios discos para minimizar los
riesgos de perdida. Esto presenta un problema asociado, la posible prdida de
rendimiento motivada por la actualizacin de todos los ficheros de control
existentes al crearse los puntos de control (checkpoint).

Los nombres de los ficheros de control y su ruta estn especificados en el

parmetro control_files del fichero init.ora.

Para aadir un fichero de control nuevo se debe cerrar la BBDD, copiar el

antiguo en el nuevo y aadir el nombre del nuevo fichero en el init.ora. Al
arrancarla de nuevo estaremos ya trabajando con el aadido tambin.
Apartado 4.4: Ficheros de Redo o Undo
Toda BBDD Oracle 10g debe disponer al menos de dos redo logs, tambin
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 funcin 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 podran reproducirse
consultando los ficheros de rehacer, y no se perdera la informacin.

Si los cambios se escribieran directamente en disco (con la consiguiente

prdida de rendimiento) y el soporte fsico jams sufriera deterioros, los ficheros
de redo no seran 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 informacin en varias ubicaciones
simultneamente.

1. Comportamiento de los ficheros de redo

Como ya se ha comentado, los ficheros de redo, almacenan registros de
redo (tambin llamados entradas de redo). Estos registran los datos necesarios
para realizar el proceso de recuperacin, reconstruyendo los cambios realizados
sobre la BBDD.
 Las entradas de redo se escriben primero en una zona especfica de la
memoria y, a medida que sta se llena, el proceso LGWR se dedica a volcar la
informacin en los ficheros de redo de forma secuencial. Cada vez que una
transaccin se confirma, todos los cambios asociados a ella se marcan con un
nmero llamado nmero de modificacin del sistema o SCN. En ocasiones, el
buffer se llena antes de que se pueda confirmar transaccin. 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 informacin 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 informacin que contuviera. El proceso de escritura en los
ficheros de redo se ilustra a continuacin:

Figura 10. Comportamiento de los ficheros de redo

Cuando se cambia de fichero en el que se escribe se produce una

conmutacin de fichero. Esta puede ser tambin realizada de forma explcita,
forzando esta conmutacin mediante la instruccin ALTER SYSTEM SWITCH
LOGFILE.

Por otro lado cuando se comienza a escribir en un fichero el SGBD le

asigna un nmero secuencial ascendente conocido como secuencia. Este es til
durante el proceso de recuperacin para conseguir realizar una reparacin
ordenada de la informacin.
2. Modos de funcionamiento de los ficheros de redo
Oracle 10g slo 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 necesitaran para una recuperacin 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 recuperacin de la BBDD tras un fallo puede no

ser total debido a que es posible que se hayan perdido cierta
informacin acerca de los cambios realizados.

Multiplexacin
La multiplexacin consiste en generar varias copias de los ficheros de redo
donde se escribe al mismo tiempo. Oracle recomienda esta estrategia, ya que
aumenta la proteccin de la BBDD frente a fallos. Los ficheros idnticos 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
caractersticas de tamao, se escribe en ellos al mismo tiempo y se encuentran
activos simultneamente. El proceso LGWR nunca escribe simultneamente en
miembros de grupos distintos.
 Figura 11. Ficheros redo log multplexados

Cada grupo de redo se define por un nmero 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 tamao.

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 reaccin depende del tipo fallo. Si se puede escribir
al menos en uno de los miembros del grupo, LGWR contina con normalidad,
ignorando a los miembros no disponibles.

Sin embargo, si LGWR no puede pasar al siguiente grupo porque ste

todava 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 estn daados y quedan inaccesibles, Oracle 10g detiene
la instancia y procede a la recuperacin de la BBDD.
 Ubicacin de los ficheros de redo
Para aumentar la funcionalidad de la multiplexacin 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 slo queda inaccesible un miembro
del grupo y LGWR continua funcionando. Asimismo, si se activa el modo de
archivado se debe intentar que no exista contencin entre el proceso LGWR (que
escribe en los ficheros) y el proceso ARCn (que lee los ficheros), por lo que se
debera 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 contencin de escritura, ya que escriben
bloques de datos y entradas de redo al mismo tiempo. Por otro lado, porque si
daa el disco que contiene los datos necesitaremos unos ficheros de redo en
perfecto estado para recuperar los datos.

Nmero 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 enva los archivados a
dispositivos de cinta). Si se multiplexan los ficheros de redo, todos los miembros
de un grupo tienen el mismo tamao y, aunque es posible, no es razonable que
los ficheros de grupos distintos tengan dimensiones diferentes, ya que las
conmutaciones se produciran de forma imprevisible.

Respecto al nmero de grupos y ficheros, es algo que debe sopesarse y

probarse. Por lo general, es preferible tener el menor nmero 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 aadir grupos.
 El lmite de grupos para la BBDD y el lmite de miembros para cada grupo
se establece con la clusula MAXLOGFILES y MAXLOGMEMBERS
respectivamente de la sentencia CREATE DATABASE (es decir, el lmite hay que
evaluarlo antes de crear la BBDD). Para eliminar este lmite se tendra que volver
a crear la BBDD o su fichero de control.

Informacin 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 cuestin. 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 vlido la prxima 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 informacin sobre ficheros de redo que guarda el fichero
de control, se puede consultar la vista V$LOG, que facilita informacin como, por
ejemplo, los SCN que contiene cada fichero, fechas de modificacin, 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 (informacin que utilizar el propio SGBD durante la
recuperacin del medio fsico), se puede utilizar la vista V$LOG_HISTORY.

Figura 14. Ejemplo de consulta a la vista V$LOG_HISTORY

En resumen las caractersticas principales de los ficheros de Redo son:

Permite proteger la BBDD ante cadas 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 ms ficheros (uno debe estar disponible para escrit-
ura mientras que se va guardando el otro). Al llenarse uno se tiene que
abrir el otro (conmutacin de log).

Siempre tiene que haber un fichero accesible para escritura, si no es as

la BBDD se parar y devolver error.
Conclusin
En esta leccin se han explicado de forma detallada las estructuras fsicas que
componen la BBDD de Oracle 10g: ficheros de datos, control y redo.

Adems se han comentado las relaciones de las mismas con las estructuras
lgicas de almacenamiento del SGBD.

Por ltimo se ha explicado la interaccin existente con la instancia de Oracle,

tanto con las zonas de memoria como los procesos.

Para ampliar las ideas incluidas en esta leccin, se recomienda consultar la

bibliografa propuesta para esta unidad didctica.
Leccin 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 dinmicas de rendimiento
5.5. Actualizacin de la informacin del diccionario de datos

Introduccin

En esta leccin se da a conocer el concepto de Diccionario de Datos. Se

detallar su composicin, funcionamiento y las ventajas que aporta al SGBD.

Al finalizar se incluyen una serie de ejercicios de auto evaluacin para

comprobar los conocimientos aprendidos.

Objetivos

En esta leccin aprenders:

- Descripcin y utilizacin del Diccionario de Datos (DD).

- Tipos de Vistas dentro del DD.

- Descripcin y utilizacin de las tablas dinmicas 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 catlogo o diccionario de datos (DD).

EL DD es generado automticamente 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 especficas.

El proceso de creacin 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 sinnimos.

Se le concede al usuario PUBLIC acceso sobre los sinnimos.

La principal funcin del catlogo de Oracle es almacenar toda la

informacin de la estructura lgica y fsica de la BBDD, es decir,
almacena definiciones de todos los esquemas existentes en la BBD (tablas,
ndices, vistas, clusters, sinnimos, secuencias, procedimientos, funciones,
paquetes, triggers,etc).

De forma ms detallada la informacin que aporta el DD al SGBD es la

siguiente:

Objetos de la BBBD (tablas, vistas, agrupamientos, sinnimos, 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.

Informacin sobre quienes han accedido y actualizado esquemas.

Informacin general de la BBDD.

Apartado 5.2: Uso del Diccionario de Datos
Tanto los usuarios como el administrador pueden consultar informacin 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 manipulacin de datos (INSERT, UPDATE, DELETE)
puesto que podran aparecer errores fatales (slo podr modificar filas de la tabla
de auditora).

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 definicin de datos, de control de datos o de
manipulacin de datos que implique la asignacin de una nueva extensin
(estructura lgica 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 parmetros de almacenamiento del diccionario estn 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 traspasarn a memoria secundaria
los que lleven ms 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 segn el prefijo que
lleven, lo que aporta una pequea indicacin del tipo de informacin 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_* : Slo las puede consultar los usuarios con privilegios de

administrador puesto que contienen informacin general de la BBDD.

V_$ V$: Vistas dinmicas sobre datos de rendimiento.

El usuario SYS es propietario de las tablas del DD, en las que se almacena
informacin sobre el resto de las estructuras de la BBDD.

Existe una tabla de catlogo para cada tipo de objeto posible. Su nombre
aparecer en plural TABLES, VIEWS, SEQUENCES, TABLESPACES, etc.
Algunos ejemplos son:

DBA_TABLES: Informacin para administradores de las tablas en

BBDD.

USER_VIEWS: Informacin de las vistas creadas por el usuario desde

el que accedemos.

ALL_SEQUENCES: Informacin de todas las secuencias existentes en

BBDD.

DBA_TABLESPACES: Informacin de administracin sobre los

tablespaces.

USER_TAB_COLUMNS: Todas las columnas de tabla en el usuario

activo.
 DICTIONARY y DICT_COLUMNS: Proporcionan informacin 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 podrn obtener
informacin del diccionario a travs de las vistas. El usuario SYS es el propietario
de las vistas del diccionario de datos que se crean durante la instalacin y sobre
las cuales se les concede derecho de acceso al usuario PUBLIC.

Apartado 5.4 Tablas dinmicas 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 deberan ser utilizadas por ningn usuario
que no sea DBA. Los administradores podrn 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: Actualizacin de la informacin del Diccionario de
Datos
Al llegar a este punto es lgico pensar que ciertos datos del catlogo de
Oracle son continuamente actualizados, debido a la frecuencia de las operaciones
que modificar el contenido del DD. Por ejemplo en las vistas dinmicas, 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 nmero de registros de una tabla,

tamao de los objetos, etc, no pueden actualizarse de esta forma porque
reduciran el rendimiento de la BBDD.

Si se quiere actualizar el catlogo 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 informacin recopilada al catlogo.

Sus opciones son las siguientes:

Compute: Hace un clculo exacto de la estadsticas.

Estimate: Realiza una estimacin partiendo del anterior valor calculado

y de un posible factor de variacin y la clusula.

Delete: Borra las anteriores estadsticas.

Conclusin
En esta leccin se ha comentado el concepto de Diccionario de Datos, su
composicin, funcionamiento y las ventajas que aporta al SGBD.

Para ampliar las ideas incluidas en esta leccin, se recomienda consultar la

bibliografa propuesta para esta unidad didctica.
Conclusin General
General

Al finalizar esta unidad didctica has debido comprender aspectos

fundamentales relativos al modelo fsico de un SGBD Oracle 10g.

Los puntos ms importantes tratados han sido:

Descripcin de la arquitectura Oracle 10g.

Componentes de una Instancia de Oracle.

Componentes de una BBDD.

Descripcin y utilizacin del Diccionario de Datos (DD).

Los ejercicios resueltos y de autoevaluacin incluidos en esta unidad te

habrn ayudado a poner en prctica los conocimientos aprendidos. En caso de
querer ampliar las ideas tratadas, se recomienda consultar la bibliografa
propuesta para esta unidad.
Glosario de trminos

ARCH Archiver.

BBDD Base de Datos.

CKPT CheckPoint.

DBWR Database Writer.

DD Diccionario de Datos.

IPC InterProcess Communication.

LGWR Log Writer.

LMD Lenguaje Manipulacin 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 (Nmero de Modificacin del Sistema)

SGA System Global Area (real Global del Sistema).

SGBD Sistema de Gestin de Base de Datos.

SMON System Monitor.

SO Sistema Operativo.

SQL Structured Query Language (Lenguaje de Consulta Estructurado)

Bibliografa

[Abramson, I., 2004]. Oracle database 10g : gua de aprendizaje. Captulo

1.

[Arun Kumar R., 2005]. Oracle Database 10g Insider Solutions. Sams
Publishing. Captulo 1.

[Dawes,C. & Bryla, B., 2004] OCA: Oracle 10g Administration I Study
Guide. Sybex. Captulo 1.

[Greenwald, R. & Stackowiak, R., 2004]. Oracle Essentials, 3e: Oracle

Database 10g. Captulo 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. Captulo 2, 3, 4, 5.

[Loney, K., 2004]. Oracle Database 10g: The Complete Reference.

Captulo 1.

[Oracle, 2006]. Oracle Database Administrator's Guide

10g Release 2 (10.2). Parte I & II. (url: 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: administracin y anlisis de bases de datos.

Captulo 14.