Arquitectura básica de Oracle 11G

ARQUITECTURA BÁSICA DE ORACLE

Notas Generales

·         Arquitectura básica:

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 están 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 más 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 ejecución y es posible gestionarla de forma automática.

·         Una sesión  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 más simple:

1 Proceso Usuario => 1 Proceso Servidor

·         Cada proceso servidor tiene un área privada de memoria llamada PGA (Program Global Area). El tamaño de  la PGA  varía de acuerdo con las necesidades y el DBA es el encargado de definir su límite máximo.

·         La gestión de la memoria poder ser totalmente automatizada en 11G, el DBA solo tendría que especificar la memoria total para el SGA y PGA y Oracle la gestionaría.

·         La estructura física que conforma Oracle:

o   Datafiles.

o   Redo log.

o   Control Files.

·         Oracle garantiza una abstracción lógica de la estructura física de la base de datos. El usuario no puede determinar dónde está físicamente su información, asimismo el administrador de sistemas no puede ver el contenido de los ficheros físicos, solo el DBA ve ambas partes de la base de datos (estructura lógica y física).

·         Los datos se guarda en Datafiles. No hay limitación en el número y tamaño de ellos. La abstracción lógica permite que los Datafiles puedan ser movidos, redimensionados, borrados, añadidos son que los usuarios sean conscientes de ello.

·         La relación entre la estructura física y su abstracción lógica se almacena en el diccionario de datos.

·         Uno de los requerimientos de todos los RDBMS es que no puede haber pérdida de información. 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 dañados, estos registros se almacenan en ficheros llamados Redo Log. Un Redo Log no es más 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 física y lógica 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 añadir nuevas instancias.

·         El rendimiento es más 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, conteniéndolos 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. Básicamente 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 más 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 idénticas a las primarias. Copia se seguridad completa. Cero perdidas.

·         Lógicas: 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 información 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 más 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 bibliografía 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 tamaño de este Buffer es crítico para el rendimiento:

o   Si es muy pequeño 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 operación se tendría que repetir muy a menudo.

o   Si es muy grande. A priori no es malo, pero cuando arranca la instancia se tarde más en asignar la memoria al SGA.

·         La memoria para el Database Buffer Cache es asignada al arrancar la instancia, se puede redimensionar dinámicamente y gestionar automáticamente

·         Log Buffer.

·         Es un área de memoria relativamente pequeña,  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 tendrían 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 supondría mucho tiempo de espera al ejecutar sentencias DML, por eso se escriben en el Log Buffer y se escribirán posteriormente de forma Batch.

·         La escritura de los Log  Buffer en los Online Redo Logs se realizan a través de un proceso llamado LGWR.

·         Como se indicó el tamaño no es muy grande, normalmente de unos poco Megas, si fuese muy grande al realizar el volcado en los Online Redo Logs se tardaría mucho e incidiría sobre el rendimiento. El tamaño por defecto lo determina Oracle y está basado en el número de CPS´s por nodo, si se cambia a un tamaño menor Oracle lo vuelve a poner al tamaños por defecto mínimo.

·         La garantía 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 después 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 también 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 operación DML más rápido 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 más compleja del SGA, está formada por decenas de otras estructuras gestionadas por el servidor Oracle.

·         Se puede gestionar automáticamente, y puede redimensionarse  dinámicamente.

·         Las estructuras más importantes que contiene son:

                                                               i.      Library cache. Área de memoria que almacena el código ejecutado más recientemente ya parseado. De esta forma se puede reusar dicho código 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 más veces si es necesario (no es más que una cache).

                                                           iv.      SQL query y PL/SQL Cache de resultados. La cache de resultados se usa a partir de la versión 11G, guarda los resultados de las últimas consultas por si se reejecutan sentencias y son datos que se pueden aprovechar. Esta opción por defecto está desactivada.

·         El Shared Pool se puede redimensionar dinámicamente y gestionar automáticamente.

·         Large Pool.

·         Es opcional, se usa automáticamente por varios procesos que de otra manera tomarían 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).

·         Tamaño dinámico y puede ser gestionado automáticamente.

·         Java pool.

·         Se usa cuando existen procedimientos java almacenados en la base de datos que se ejecutan.

·         Tamaño dinámico y puede ser gestionado automáticamente.

·         Streams  Pool.

·         Usado con Oracle Streams en configuraciones distribuidas.

·         Tamaño dinámico y puede ser gestionado automáticamente.

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 después abre la base de dtos localizando y validando los Datafiles y los Online Redo Logs.

o   También 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 sesión, libera la memoria PGA,  hace RollBack de transacciones incompletas…

·         DBWn

o   Escriben bloques de datos del Buffer Cache a disco.

o   Hay un máximo 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 estén disponibles para los nuevos traídos de disco.

2.       Hay muchos bloques Dirty en el Buffer Cache. Cuando esto ocurre se lanza una petición y los DBWn vuelva en disco los menos recientemente usados y que estén 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 están 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 actúe:

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 versión 8i se  hacen Checkpoint parciales, es más 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 petición o cuando se para la base de datos.

·         MMON

o   Introducido en la versión 10G.

o   Ayuda a la auto monitorización y auto tunnig de la base de datos.

o   La instancia recopila muchas estadísticas sobre la actividad y rendimiento de la base de datos, estos datos se almacenan en la SGA. MMON recopila estas estadísticas 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 información estadística 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 planificación de MMON no es suficiente salta este proceso para ayudar a recopilar la información estadística.

·         MMAN

o   Memory Manager.

o   Permite la gestión automática 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 línea para que se guarden permanentemente.

·         RECO

o   Recoverer process.

o   Una transacción distribuida implica varias bases de datos, si alguna falla RECO se encarga de realizar un rollback ordenado.

·         Otros procesos:

o   CCJQ0, J000: Planificación de trabajos.

o   D000: Gestor de procesos que envía 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 abstracción lógica de la estructura física.

·         El almacenamiento lógico se realiza en segmentos.

·         Los segmentos están almacenados en los Datafiles.

Abstracción lógica de la estructura física

         ESTRUCTURA LÓGICA                                     ESTRUCTURA FÍSICA

 Estructura física

·         Existen 3 tipos de ficheros físicos principales:

1.       ControlFiles.

§  Existe un Controlfile y varias copias de él (como norma). Deba haber como mínimo 1 y como máximo 8.

§  Es de pequeño tamaño pero vital.

§  Contiene “punteros” hacia:

·         Localización de los Online Redo Logs Files.

·         Localización de los Datafiles.

·         Los Archives más recientes.

·         Varias secuencias numéricas 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 cíclica (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 mínimo hay dos Datafiles:

·         SYSTEM: Almacena el diccionario de datos.

·         SYSAUX: Auxiliar para el diccionario de datos.

§  Son el repositorio de los datos.

§  Su número y tamaño es prácticamente ilimitado.

§  Son la estructura física visibles para el administrador del sistema.

§  Pueden ser renombrados, movidos, añadir 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:

·         Sección cabecera. Datos del número de resgistros, lugar donde se encuentran…

·         Área de datos.  Contienen los datos del bloque.

·         Espacio libre.

§  Cuando una sesión 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 física:

§  Instance Parameter File. Contiene parámetros de iniciación  para el SGA y los procesos. Hay literalmente cientos de parámetros,  uno de los más 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 pequeño número de registros.

§  Alert Log y Trace Files.

·         Alert Log: Almacena mensajes críticos 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 lógica

Mencionar brevemente el diccionario de datos:

·         Contiene le matada datos.

·         Describe la base de datos tanto física como lógicamente.

·         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.