Arquitectura bsica de Oracle 10G

ARQUITECTURA BSICA DE ORACLE

Notas Generales
Arquitectura bsica:
1 Instancia => 1 Base de Datos
Instancia => Estructuras en memoria + Procesos
Una instancia se crea y se destruye al levantar o cerrar una base de datos.
Una base de datos consiste en una serie de ficheros en disco que existen aunque no exista la
instancia.
Los procesos son conocidos como procesos Background porque siempre se estn ejecutando en
segundo plano mientras la instancia est activa. Son en su mayor parte auto-administrables el
DBA siempre puede actuar sobre ellos).
Las estructuras de memoria se implementa en segmentos de memoria del Sistema operativo. La
ms importante es el SGA (System Global Area). La SGA es asignada y liberada cunado se
levanta o se cierra la instancia. A partir del Oracle 11G se puede redimensionar en tiempo de
ejecucin y es posible gestionarla de forma automtica.
Una sesin de usuario consiste en un proceso de usuario conectado mediante Oracle Net a un
proceso servidor. El proceso de usuario lanza consultas SQL y el proceso servidor las recoge y se
encarga de realizar las operaciones necesarias para ejecutarlos.
La forma ms simple:
1 Proceso Usuario => 1 Proceso Servidor
Cada proceso servidor tiene un rea privada de memoria llamada PGA (Program Global Area). El
tamao de la PGA vara de acuerdo con las necesidades y el DBA es el encargado de definir su
lmite mximo.
La gestin de la memoria poder ser totalmente automatizada en 11G, el DBA solo tendra que
especificar la memoria total para el SGA y PGA y Oracle la gestionara.
La estructura fsica que conforma Oracle:
o Datafiles.
o Redo log.
o Control Files.
Oracle garantiza una abstraccin lgica de la estructura fsica de la base de datos. El usuario no
puede determinar dnde est fsicamente su informacin, asimismo el administrador de sistemas
no puede ver el contenido de los ficheros fsicos, solo el DBA ve ambas partes de la base de datos
(estructura lgica y fsica).
Los datos se guarda en Datafiles. No hay limitacin en el nmero y tamao de ellos. La
abstraccin lgica permite que los Datafiles puedan ser movidos, redimensionados, borrados,
aadidos son que los usuarios sean conscientes de ello.
La relacin entre la estructura fsica y su abstraccin lgica se almacena en el diccionario de
datos.
Uno de los requerimientos de todos los RDBMS es que no puede haber prdida de informacin.
Oracle soluciona esto capturando cualquier cambio que se produzca en la base de datos y lo
almacena, para en el caso de ser necesario ser capaz de reconstruir los datos perdidos o daados,
estos registros se almacenan en ficheros llamados Redo Log. Un Redo Log no es ms que un
fichero de registros secuenciales de todos los vectores de cambio aplicados a los datos.
Los Controlfiles. Son ficheros donde se almacenan detalles de la estructura fsica y lgica de la
Base de datos, son el punto de arranque de una instancia.

Sistemas de arquitecturas distribuidas

Principalmente tenemos 3 a estacar:
1. RAC (Real Application cluster). Se caracteriza por tener muchas instancias trabajando contra una
sola base de datos.
 Proporciona un alto rendimiento, tolerancia a fallos, escalabilidad e integrada dentro de la
arquitectura Grid.
Las instancias pueden fallar, pararse y el usuario no lo notar, se pueden aadir nuevas
instancias.
El rendimiento es ms notable durante las ejecuciones de Querys paralelas.
2. Streams. Se caracteriza porque varios servidores de Oracle propagan transacciones entre ellos.
Existen varias razones por las que querer trnasferir transacciones entre servidores:
Tolerancia a fallos: Se pueden tener 2 servidores en lugares diferentes y usuarios trabajando en
cada uno de ellos, contenindolos mismos datos (mediante transferencias de uno a otro) y de esta
manera se pueden usar como respaldo el mutuo.
Tuning: Se pueden tener 2 bases de datos trabajando conjuntamente pero realizando funciones
diferentes; una con como servidor OLTP y la otra un DataWarehouse que se nutre de la anterior.
3. Data Guard. Bsicamente se puede describir como una base de datos primaria y una o varias
secundarias como respaldo. Existe una base de datos primaria y una o ms bases de datos
secundarias usadas como resplado o incluso para soporte en grandes consultas. Las secundarias
pueden ser de dos formas:
Replicas byte a byte: Son idnticas a las primarias. Copia se seguridad completa. Cero perdidas.
Lgicas: Contienen los mismos datos que la principal pero con una estructura de datos diferentes.

Estructuras de memoria
Una instancia contiene 2 estructuras principales: SGA y PGA
SGA:
o Database Buffer Cache (Obligatoria).
o Log Buffer (Obligatoria).
o Shared Pool (Obligatoria).
Library cache.
Data Dictionary Cache.
Pl/Sql Area.
SQL Query y Pl/Sql function result Cache.
o Large Pool
o Java Pool
o Stream Pool

Database Buffer Cache.

Es el rea principal de trabajo de Oracle.
Los usuarios no acceden directamente al disco, en vez de esto el bloque de datos que contiene la
informacin requerida se trae y copia en esta rea, en un bloque del Database Buffer Cache.
Cualquier cambio de los datos se realiza en el bloque en la cache y permanece en ella para que
puede ser usada ms veces y no se tengan que realizar muchas lecturas al disco, el bloque se
copiar a disco cuando ser necesario.
Lo normal es que un bloque que est en la cache y uno que est en el disco no tengan los mismos
datos, en mucha bibliografa se dice que es un bloque dirty (sucio). Son estos bloques los que al
final se terminan grabando en el disco para sincronizar el contenido del disco con los datos
contenidos en la cache.
El tamao de este Buffer es crtico para el rendimiento:
o Si es muy pequeo el rendimiento degenera puesto que hay que leer y escribir mucho entre el Buffer
y el disco, como hay poco espacio un bloque se usa y se escribe otra vez en disco, esta operacin
se tendra que repetir muy a menudo.
o Si es muy grande. A priori no es malo, pero cuando arranca la instancia se tarde ms en asignar la
memoria al SGA.
La memoria para el Database Buffer Cache es asignada al arrancar la instancia, se puede
redimensionar dinmicamente y gestionar automticamente
 Log Buffer.

Es un rea de memoria relativamente pequea, puesto que los vectores de cambio que en ella se
escriben se vuelcan muy a menudo en Online Redo Logs.
Los vectores de cambio son las modificaciones aplicadas a los datos, este vector se escribe
primeramente en los Log Buffer y posteriormente se vuelcan en los OnLine Redo Log para que no
se pierda, de esta forma se garantiza que no se pierden datos y si ocurre algo sobre un Datafile
solo se tendran que recuperar una copia del Datafile y aplicar sobre ella los vectores de cambio
almacenados en los Online Redo Logs.
Los vectores de cambio no se escriben directamente en los Online Redo Logs porque supondra
mucho tiempo de espera al ejecutar sentencias DML, por eso se escriben en el Log Buffer y se
escribirn posteriormente de forma Batch.
La escritura de los Log Buffer en los Online Redo Logs se realizan a travs de un proceso llamado
LGWR.
Como se indic el tamao no es muy grande, normalmente de unos poco Megas, si fuese muy
grande al realizar el volcado en los Online Redo Logs se tardara mucho e incidira sobre el
rendimiento. El tamao por defecto lo determina Oracle y est basado en el nmero de CPSs por
nodo, si se cambia a un tamao menor Oracle lo vuelve a poner al tamaos por defecto mnimo.
La garanta de que durante una sentencia de COMMIT no se pierden datos es porque: primero se
guarda el bloque de datos de la cache que se ha cambiado a disco y despus se guardan los
vectores de cambio de los Log buffer a los Online redo Logs, solo si se ejecutan bien las dos tareas
se considera un xito el COMMIT, en caso contrario se deshacen las operaciones.
El Log Buffer se asigna el arrancar la instancia y no se puede redimensionar sin tener que reiniciar
tambin la instancia.
La escritura del Log Buffer a los Online Redo Logs es el ltimo cuello de botella que existe en
Oracle, no se puede realizar una operacin DML ms rpido que el proceso de escribir de los
vectores de cambio por el LGWR.
La nica forma de aumetar el rendimiento es con RAC, cada instancia tiene su propio Log Buffer y
su propio proceso LGWR.

Shared Pool.
Es la estructura ms compleja del SGA, est formada por decenas de otras estructuras
gestionadas por el servidor Oracle.
Se puede gestionar automticamente, y puede redimensionarse dinmicamente.
Las estructuras ms importantes que contiene son:
i. Library cache. rea de memoria que almacena el cdigo ejecutado ms recientemente ya
parseado. De esta forma se puede reusar dicho cdigo sin necesidad de volverlo a parsear.
ii. Data Dictionary Cache. Almacena definiciones de objetos recientemente usados como
descripciones de tablas, de campos, de ndices, permisos sobre objetos, metadata
iii. PL/SQL Area: Almacena objetos PL/SQL (funciones, procedimientos, paquetes, trigger,
variables). Estos objetos se almacenan en el diccionario de datos tanto en su formato fuente
como parseado, cuando se necesita se trae del diccionario y se almacena en esta rea para ser
usado ms veces si es necesario (no es ms que una cache).
iv. SQL query y PL/SQL Cache de resultados. La cache de resultados se usa a partir de la versin
11G, guarda los resultados de las ltimas consultas por si se reejecutan sentencias y son datos
que se pueden aprovechar. Esta opcin por defecto est desactivada.
El Shared Pool se puede redimensionar dinmicamente y gestionar automticamente.

Large Pool.

Es opcional, se usa automticamente por varios procesos que de otra manera tomaran memoria
del Shared Pool.
Se usa sobre todo cuando se configura el servidor Oracle con Procesos de Servidor compartidos
(varios procesos de usuario comparten un nico proceso de servidor).
Tamao dinmico y puede ser gestionado automticamente.
 Java pool.

Se usa cuando existen procedimientos java almacenados en la base de datos que se ejecutan.
Tamao dinmico y puede ser gestionado automticamente.

Streams Pool.

Usado con Oracle Streams en configuraciones distribuidas.

Tamao dinmico y puede ser gestionado automticamente.

Estructura de procesos
Hay 5 procesos principales:
o SMON (System Monitor)
o PMON (Process Monitor)
o DBWn (DataBase Writer)
o LGWR (Log Writer)
o CKPT (CheckPoint)
Otros procesos secundarios:
o MMON (Manegeability Monitor)
o MMML (Manegeability Monitor Ligth)
o MMAN (Memory Manager)
o ARCn (Archiver)
o RECO (Recover)

SMON
o Su principal cometido es montar y abrir la base de datos. Monta la base de datos localizando y
validando los fichero ControlFiles y despus abre la base de dtos localizando y validando los
Datafiles y los Online Redo Logs.
o Tambin se encarga de otras tareas como cotejar el espacio libre de los DataFiles.
PMON
o Se encarga de controlar sesiones de usuario que no terminen de forma ordenada, para ello
destruyen el proceso del servidor asociado a la sesin, libera la memoria PGA, hace RollBack de
transacciones incompletas
DBWn
o Escriben bloques de datos del Buffer Cache a disco.
o Hay un mximo de 20 procesos por instancia: DBW0, DBW1, DBW2,
o Los motivos por los cuales los bloques dirty se escriben del Buffer a disco pueden ser 4:
1. No hay bloques libres en el Buffer Cache. Si un proceso necesita llevar datos al buffer y este se
encuentra lleno se realiza una llamada al DBWn para que escriba algunos bloques de la cache al
disco y limpia esos bloques para que estn disponibles para los nuevos trados de disco.
2. Hay muchos bloques Dirty en el Buffer Cache. Cuando esto ocurre se lanza una peticin y los
DBWn vuelva en disco los menos recientemente usados y que estn Dirty.
3. Cada 3 segundos. Cada 3 segundos los procesos DBWn vualcan a disco bloques Dirty.
4. En respuesta a un CheckPoint. Durante un CheckPoint todos los bloques Dirty se vuelcan a disco,
todo y no solo unos cuantos. Durante el CheckPoint se sincronizan los Buffer Cache y los
DataFiles.
LGWR
o Escribe el contenido del Log Buffer en los Online Redo Logs Files que estn en disco.
o Casi se escriben en tiempo real y si se realiza un COMMIT si se hace en tiempo real.
o Es el ltimo cuello de botella de Oracle.
o Hay 3 motivos fundamentales para que el proceso LGWR acte:
1. Se lanza un COMMIT. LGWR guarda el Log Buffer a los Online Redo Logs, solo cuando acaba
esta escritura se considera acabado el COMMIT.
2. El Log Buffer est a 1/3 lleno. LGWR guarda los Log Buffer cuando estos llegan a 1/3 de su
capacidad.
3. Cuando el proceso DBWn escribe bloques dirty a los Datafiles lanza una llamada al LGWR para
que guarde los Log Buffer.
CKPT
o Desde la versin 8i se hacen Checkpoint parciales, es ms productivo y mejora el rendimiento.
o Durante un checkpoint se vuelca a memoria tanto el Buffer Cache como los Log Buffer.
o Solo se hace un checkPoint total a peticin o cuando se para la base de datos.
MMON
o Introducido en la versin 10G.
o Ayuda a la auto monitorizacin y auto tunnig de la base de datos.
o La instancia recopila muchas estadsticas sobre la actividad y rendimiento de la base de datos, estos
datos se almacenan en la SGA. MMON recopila estas estadsticas del SGA y las almacena en el
diccionario de datos.
o Cuando almacena uno de estos snapshot (conjunto de datos) por el MMON llama al ADDM, que es
una herramienta que analiza los dos ltimos snapshot con informacin estadstica y por medio de
un sistema inteligente realiza observaciones y recomendaciones para que aumente el rendimiento
de la base de datos.
MMML
o Es un proceso light que ayuda al MMON.
o Si la planificacin de MMON no es suficiente salta este proceso para ayudar a recopilar la
informacin estadstica.
MMAN
o Memory Manager.
o Permite la gestin automtica de la memoria.
o Solamente hay que especificar la memoria que se usar y el proceso asigna y gestiona esa memoria
entre la SGA y PGA.
ARCn
o Archiver
o Es opcional.
o Pueden existir hasta 13: ARC0, ARC1
o Los online Redo Log file se llenan, se usan de forma circular por lo que solo almacenan un espacio
de tiempo deteminado. ARCn realiza una copia de estos ficheros en otros fuera de lnea para que
se guarden permanentemente.
RECO
o Recoverer process.
o Una transaccin distribuida implica varias bases de datos, si alguna falla RECO se encarga de
realizar un rollback ordenado.
Otros procesos:
o CCJQ0, J000: Planificacin de trabajos.
o D000: Gestor de procesos que enva SQLs a servidos de procesos compartidos.
o DBRM: Gestor de recursos de la BD.
o DIA0: Responsable de detectar y resolver casos de bloqueos (deadLock).
o DIAG
o FBAR
o PSP0
o QMNC, Q000
o SHAD
o SMCO,W000
o VKTM
 Estructura de almacenamiento
Existe una abstraccin lgica de la estructura fsica.
El almacenamiento lgico se realiza en segmentos.
Los segmentos estn almacenados en los Datafiles.

Abstraccin lgica de la estructura fsica

ESTRUCTURA LGICA ESTRUCTURA FSICA

Estructura fsica
Existen 3 tipos de ficheros fsicos principales:
1. ControlFiles.
Existe un Controlfile y varias copias de l (como norma). Deba haber como mnimo 1 y como mximo
8.
Es de pequeo tamao pero vital.
Contiene punteros hacia:
Localizacin de los Online Redo Logs Files.
Localizacin de los Datafiles.
Los Archives ms recientes.
Varias secuencias numricas y de fechas.

2. Online Redo Logs Files.

Guardan en cadena los vectores de cambio.
Cada base de datos tiene al menos 2 ficheros Online Redo Log.
Cada uno de estos ficheros contienen grupos de ficheros, cada fichero se conoce como miembro.
Oracle requiere dos grupos con al menos 1 fichero cada grupo.
Uno de los grupos es el actual y sobre el que se escriben los vectores del Log Buffer, cuando se llena
se pasa al otro grupo y as sucesivamente de forma cclica (se reescriben).
Si la base de datos est configurada para ARCn se hacen copias de los ficheros Online Redos Logs
para que no se pierdan al sobreescribirlos.
3. DataFile.
Como mnimo hay dos Datafiles:
SYSTEM: Almacena el diccionario de datos.
SYSAUX: Auxiliar para el diccionario de datos.
Son el repositorio de los datos.
Su nmero y tamao es prcticamente ilimitado.
Son la estructura fsica visibles para el administrador del sistema.
Pueden ser renombrados, movidos, aadir nuevos, redimensionados o borrados.
A nivel se Sistema Operativo son un conjunto de bloques (2 KB a 64 KB por bloque).
Dentro de cada uno de los bloques que forman un Datafile tenemos:
 Seccin cabecera. Datos del nmero de resgistros, lugar donde se encuentran
rea de datos. Contienen los datos del bloque.
Espacio libre.
Cuando una sesin necesita datos, se leen del Datafile correspondiente y se llevan al Buffer Cache, y
cuando sea necesario ese bloque en el Buffer Cache es volcado al Datafile por el proceso LGWR.
4. Otros ficheros de la estructura fsica:
Instance Parameter File. Contiene parmetros de iniciacin para el SGA y los procesos. Hay
literalmente cientos de parmetros, uno de los ms importantes y obligatorio es DB_NAME que
contiene el nombre de la base de datos.
Password File. Lo normal es que los usuario y passwords se almacenen en el diccionario de datos,
pero cuando no est disponible (por ejemplo al inicio del arranque) se usa este fichero para leerlos.
Contiene un pequeo nmero de registros.
Alert Log y Trace Files.
Alert Log: Almacena mensajes crticos sobre la instancia y sobre la base de datos que se
producen en cualquier momento.
Trace Files: son trazas que generan los procesos de las instancias.

Estructura lgica
Mencionar brevemente el diccionario de datos:
Contiene le matada datos.
Describe la base de datos tanto fsica como lgicamente.
Se almacena en segmento de los TableSpace SYSTEM y SYSAUX.
Contiene una serie de tablas y vistan con todos los datos administrativos de la base de datos y de
todos los objetos de la misma. Muchas de estas vistas y tablas contienen 3 prefijos que tienen un
significado especial:
o DBA_ => Datos a los que el DBA tiene acceso, a todo.
o USER_ => Datos del usuario.
o ALL => Datos a los que el usuario puede acceder.