Capìtulo 2 - Explorando la Arquitectura.

Capìtulo 2

Explorando la Arquitectura.

Objetivos de Certificación

1. Describir la Arquitectura de Instancia Única.

2. Explicar la Estructura en Memoria.

3. Describir la Estructura de los Procesos.

4. Resumir las estructuras de almacenamiento.

Un servidor Oracle se compone de dos entidades: La instancia y la Base de Datos. La instancia son estructuras en memoria y procesos; la base de datos son archivos en disco. Están separadas pero conectadas. Durante el proceso de creación, la instancia se creó por primera vez, y luego la base de datos durante el proceso de inicio. Primero se inicia la instancia y luego la base de datos es abierta. En un típico entorno de single-instance. La relación de instancia a base de datos es de uno a uno. Una single instance está conectada a una single Database. Pero siempre tenga en mente que hay más posibilidades en entornos distribuidos.

En el Servidor Oracle, no es la abstracción completa de almacenamiento lógico del almacenamiento físico. Los programadores ven estructuras lógicas y no están relacionados directamente con las estructuras físicas que los administradores si ven. La relación entre las dos es gestionada por estructuras internas los controlfiles y diccionario de datos.

OBJETIVOS DE CERTIFICACION 2.01. 

DESCRIBIENDO LA ARQUITECTURA SINGLE-INSTANCE.

En su mayor parte en este libro, se ocupara con los entornos de base de datos más comunes: una instancia en un equipo, abrir una base de datos almacenada en un disco local. Para arquitecturas distribuidas con la participación de varias instancias y bases de datos múltiples, están fuera del alcance del examen OCP.

ARQUITECTURA DE BASE DE DATOS: SINGLE-INSTANCE.

La instancia consiste en estructuras de memoria y procesos. Su existencia es transitoria en la RAM de su CPU. Al apagar la instancia en ejecución, todo rastro existente desaparece al mismo tiempo. La base de datos consiste en archivos físicos en disco. Ya sea en marcha o parado. Así, el curso de vida de la instancia es solo durante la existencia de la memoria RAM(volátil). Usted puede iniciar y parar. Por el contrario, la base de datos una vez creada persiste indefinidamente, hasta que elimina los archivos asociados a la base de datos.

Los procesos que conforman la instancia se conocen como procesos background, por que están presentes y corriendo en todo momento mientras que la instancia esta activa. Estos procesos son en su mayor parte por completo de administración autónoma. Aun que en algunos casos es posible para el DBA influir el numero de ellos y su funcionamiento.

Las estructuras de memoria, que se implementan en los segmentos de memoria compartida provista por el sistema operativo. Se conoce como el System Global Area o SGA. Esta es asignada con el inicio de la instancia y liberada con la parada de esta. Dentro de ciertos límites. La SGA en la instancia de 11g y los componentes dentro de ella pueden cambiar el tamaño, mientras que la instancia se está ejecutando, o en automático o en respuesta de instrucciones a instrucciones del DBA.

Una sesión de usuario consiste de un proceso de usuario que se ejecuta localmente en la maquina usuario que se conecta a un proceso de servidor que ejecuta localmente en la instancia del servidor. La técnica para poner en marcha los procesos de servidor, que se inician en demanda de cada sesión, es tratada en el capítulo 6. La conexión entre procesos de usuarios y procesos de servidor suelen ser atraves de una red de área local y utiliza el protocolo Oracle Net ubicado en la capa superior de la industria estándar (usualmente TCP). Los procesos de usuario a procesos de servidor implementa la arquitectura cliente servidor: Proceso de usuario genera SQL, procesos de servidor ejecuta SQL. Los procesos de servidor son algunas veces procesos foreground, en contraste con los procesos background que conforman la instancia. Asociado con cada proceso de servidor hay una área de memoria nonshareable, llamada el Program Global Area o PGA. Esta es privada para la sesión, a diferencia de la System Global Área SGA, que está disponible para todos los procesos foreground y procesos background. Tenga en cuenta que los procesos background también tienen una PGA. El tamaño de las sesiones en PGA variara acorde a las necesidades de memoria de la sesión en un momento dado; el dba puede definir el límite superior para el total de todas las PGAs y Oracle administra la asignación e estas sesiones dinámicamente.

EN EL TRABAJO.

A veces se oye el término Process Shadow. Tenga cuidado para usar esto. Algunas personas lo utilizan para referirse a los procesos Foreground, otros lo utilizan para procesos Background. No importa pero asegúrate de lo que están hablando.

El manejo de memoria en 11g puede ser totalmente automáticamente: El DBA no necesita hacer nada más que especificar una asignación de memoria en general, tanto para el SGA y la PGA y dejar que oracle gestione la memoria. Por otra parte, el DBA puede controlar las asignaciones de memoria. Donde el DBA define ciertos límites en que la gestión automática puede hacer.

EXAMEN

La memoria SGA se comparte entre todos los procesos background y foreground; La memoria PGA solo puede ser accesada solo por procesos foreground de la sesión a la que ha sido asignada. Ambas memorias SGA y PGA pueden ser administradas automáticamente.

Las estructuras físicas que conforman una base de datos de oracle son los DataFiles, los redo log y los ControlFiles. Dentro de las estructuras físicas de la base de datos, que los administradores pueden ver, son las estructuras lógicas que nosotros y usuarios ven. La Arquitectura Oracle garantiza la abstracción de la Lógica de la Física: No hay forma que un programador puede determinar dónde, físicamente, un bit de datos se encuentra. El trata solamente las estructuras lógicas, tales como Tablas. Similarmente, es imposible para un Administrador de Sistema saber que bits de datos esta en cual Estructura Física. Todo lo que él puede ver son los archivos de sistema operativo, no lo que está dentro de ello. Es solo usted, el administrador de Base de Datos, quien está permitido ver ambos lados de la historia.

La abstracción del almacenamiento Lógico del Almacenamiento físico es parte del standard RDBMS. Si fuera posible para un programador para determinar la ubicación física de un registro, entonces la ejecución con éxito del código sería totalmente dependiente en el medio para el que fue escrito. Cualquier cambio de plataforma, movimiento de DataFiles, o incluso renombrar un archivo rompería la aplicación. Es de hecho posible determinar donde esta una tabla (e incluso una fila dentro de una tabla) realmente, pero no con el SQL. El lenguaje no lo permite. Existen las herramientas producidas para el uso del administrador de la Base de Datos para hacer esto, si fuera necesario.

Los Datos son almacenados en DataFiles. No hay un límite práctico para el número o tamaño de los DataFiles. Y la abstracción de almacenamiento lógico del almacenamiento físico significa que los DataFiles pueden ser movidos o cambiar de tamaño y más DataFiles puede ser agregado sin que los desarrolladores estén conscientes de esto. La relación entre estructuras físicas y lógicas se mantiene y documenta en el Diccionario de Datos, que contiene Metadatos que describen toda la Base de Datos. Al consultar ciertas vistas en el Diccionario de Datos, el DBA puede determinar con precisión donde esta cada parte de cada tabla.

El Diccionario de Datos es un conjunto de Tablas almacenadas dentro de la Base de Datos: Hay un problema recurrente aquí: La instancia necesita estar consciente de la estructura física y lógica de la Base de Datos. Pero la información que describe esto en sí mismo, está dentro de la Base de Datos. La solución a este problema se encuentra en el proceso de inicio, que es detallado en el Capitulo 5.

Un requerimiento del estándar de RDBMS es que la Base de Datos no debe perder datos. Esto significa que esto debe ser respaldado, y, además, que cualquier cambio realizado a los datos entre los respaldos debe ser capturado de tal manera que pueden aplicarse a una restauración de un Backup. Este es el proceso de recuperación hacia adelante. Oracle implementa la captura de cambios atraves de los redo log. El Redo Log es un registro secuencial de todos los cambios vectors (change vectors) aplicado a los datos. Un cambio vector es la alteración hecha por una sentencia DML (Data Manipulation Language: INSERT, UPDATE, o DELETE). Cuando una sesión de usuario hace cualquier cambio. los datos si mismos en el bloque de datos se cambian y el vector del cambio es escrito a los lados del redo log, en una forma que hace que sea repetible. Luego, en el caso de daño a un DataFiles, un Backup del archivo puede ser restaurado y Oracle extraerá los vectores change vectors relevantes del Redo Log y aplicarlos luego a los Bloques de Datos dentro del Archivo. Esto asegura que el trabajo nunca se perderá, a menos que el daño a la Base de Datos están extensa como para perder no solo uno o más ficheros, pero también sus respaldos o el redo log.

Los ControlFiles almacenan los detalles de la estructura física de la Base de Datos y es el punto de partida para vincular con las estructuras lógicas. Cuando una instancia abre una Base de Datos, hace la primera lectura de ControlFiles. Dentro de los ControlFiles está la información que la Instancia puede entonces utilizar para conectar con el resto de la Base de Datos, y el diccionario de datos dentro de ella.

La arquitectura de una Base de Datos de Single-Instance puede ser resumida como un conjunto de cuatro componentes que interactúan entre sí.

- Un usuario interactúa con un Proceso de Usuario.

- Un Proceso de usuario interactúa con un Proceso de Servidor.

- Un Proceso de Servidor interactúa con una instancia.

- Una Instancia interactúa con una Base de Datos.

Es absolutamente imposible para cualquier proceso cliente tenga cualquier contacto con la Base de Datos: todo acceso debe ser mediante procesos de servidor. La división de cliente-servidor se encuentra entre el proceso de usuario (lo que genera SQL) y el proceso del servidor (que se ejecuta).

ARQUITECTURA DE SISTEMAS DISTRIBUIDOS.

En el entorno de Single-Instance, una instancia abre una Base de Datos, en un entorno distribuido, hay varias posibilidades para agrupar instancia y bases de datos.

Principalmente:

- Real Application Clusters (RAC), donde múltiples instancias abren una Base de Datos.

- Streams, donde multiples Servidores Oracle propagan transacciones entre sí.

- Data Guard. Donde una Base de Datos primaria actualiza una Base de Datos en espera.

REAL APPLICATION CLUSTER (RAC).

RAC ofrece impresionantes capacidades de rendimiento, tolerancia a fallos y escalabilidad (y posiblemente, ahorro de costos) y es integral a los conceptos de Oracle Grid. Con versiones previas, RAC (o su precursor, Oracle Parallel Server) era una opción adicionada costosa, pero del lanzamiento 10g de la base de datos hacia adelante, RAC se lía con la licencia de la edición estándar. Esta es una indicación de cómo quiere Oracle Corporation para empujar a usuarios hacia el ambiente de RAC. Edición Estándar RAC se limita a un cierto número de computadoras y un cierto número de procesadores y núcleos por ordenador, pero incluso dentro de estas limitaciones se accede a un entorno extraordinariamente poderoso. RAC es una opción con costo adicional para la edición Enterprise, donde la escalabilidad sea realmente ilimitado: limitada sólo por la capacidad de agrupamiento del sistema operativo subyacente y el hardware.

Una base de datos RAC puede ser configurado para el tiempo de actividad del 100 por ciento. Una instancia puede estar abajo(a sea para mantenimiento planificado, o quizás porque el equipo en el que se está ejecutando accidentes) y la Base de Datos permanecerá accesible atraves de otra instancia en otro equipo. Las sesiones establecidas contra una instancia que ha fallado pueden ser restablecidas contra una instancia que este arriba sin que el usuario final se percate de esto.

La transparente escalabilidad proviene de la capacidad para agregar instancias, ejecutándose en diferentes maquinas, a un RAC dinámicamente. Tomará automáticamente algo de la carga de trabajo sin que los usuarios se percaten de que hay más instancias disponibles.

Algunas aplicaciones tendrán un rendimiento de ejecutarse en un RAC. Pero no todas. El procesamiento en paralelo puede mejorar el rendimiento de algunos trabajos, tal como ejecución de grandes consultas y actualizaciones de grandes lotes. En una Base de Datos Single-Instance, asignando múltiples servidores para ejecución en paralelo para tales trabajos ayudará-pero todos estarán ejecutándose en una instancia en una maquina. En una Base de Datos en RAC, los servidores de ejecución en paralelo pueden ejecutarse en diferentes instancias, que pueden superar algunos de los cuellos de botella inherentes de la arquitectura Single-Instance. Otros trabajos. Tales como procesamiento de gran numero de pequeñas transacciones encontradas típicamente en un sistema OLTP (online transaction processing) no obtendrá una ventaja en rendimiento.

EN EL TRABAJO.

No convierta a RAC solo porque es posible. Usted necesita estar seguro de lo que usted quiere lograr antes de embarcarse en lo que es un gran ejercicio que suele no ser necesario.

STREAMS.

Hay varias circunstancias que hacen deseable la transferencia de datos de una a otra Base de Datos. Tolerancia a fallos es una: si una organización tiene dos (o más) Bases de Datos separadas geográficamente. Ambas contienes datos idénticos y ambas disponibles en todo momento para usuarios. Entonces no importa que va mal en un sitio. El trabajo debe ser capaz de continuar sin interrupciones en el otro. Otra razón es el tunning(ajuste): Las dos Bases de Datos pueden estar configuradas para diferentes tipos de trabajo, tales como una base de datos para Procesamiento de Transacciones y una para Warehouse.

Mantener las Bases de Datos sincronizadas tendrá que ser completamente automático, y todo cambio hecho en cualquier sitio necesitará ser propagado en tiempo real o casi real a los otros sitios. Otra razón podría ser mantenimiento de un Data Warehouse. Conjuntos de datos mantenidos por una Base de Datos necesitarán ser propagados a la Base de Datos Warehouse, y posteriormente, estas copias necesitarán periódicamente refrescarse los cambios. Los datos puede ser empujados hacia afuera, tal vez a una serie de data marts cada uno con un subconjunto de la bodega. Streams son una facilidad para capturar cambios hechos a tablas y aplicarlos luego a copias remotas de las tablas que pueden llenar estos requisitos.

Streams puede ser Bidireccional: Tablas idénticas en dos o más sitios, con todas las transacciones de usuarios ejecutadas en cada sitio y aplicadas en los otros sitios. Este es el modelo Streaming necesario para tolerancia a fallos. Un modelo alternativo es el utilizado en el ejemplo del Data Warehouse donde los conjuntos de datos (y los cambios subsiguientes que se les hace) son extraídos de las tablas en una base de datos y metidos a las tablas en otra Base de Datos.

En este modelo, el flujo de información es más probable que sea unidireccional, y las estructuras de las tablas pueden no ser idénticas en los lugares intermedios (downstream).

Streams puede también ser utilizado para tolerancia a fallos. No es infrecuente fluir una base de datos entera entre los casos múltiples, con los usuarios finales trabajando en ambos lados de la corriente, Streams propagará cambios entre ellas, bidireccionalmente, para mantener las dos bases de datos sincronizadas. Si un Servidor de Base de Datos falla, el trabajo puede continuar con el Servidor de base de datos sobreviviente. Cuando el servidor fallado no se trae de nuevo en línea, será puesto al día con todos los cambios hechos en contra de su pareja mientras ella no estaba disponible.

Esta también posible para una sesión contra una instancia, atraves de Database Links, para conectarse a múltiples bases de datos mediante programación. Programadores pueden escribir código que permita a una sesión contra un servidor para leer y actualizar datos en otras Bases de Datos através de Database Links; existe un sistema totalmente automatizado de dos fases mecanismo para garantizar la coherencia transaccional en estas circunstancias.

DATA GUARD.

Los Sistemas Data Guard tienen una Base de Datos primaria contra la que las transacciones son ejecutadas, y una o más en espera utilizadas para tolerancia a fallas o para procesar consultas. Las Bases de Datos en espera son instanciadas de un respaldo de la primaria y actualizada (posiblemente en tiempo real) con todos los cambios aplicados a la primaria.

Los Standbys vienen en dos formas. Un Standby Físico es byte a byte idéntica con la primaria, para propósitos de cero perdida de Datos. Incluso si la primaria es totalmente destruida, todos los datos estarán disponibles en la Standby. Los change vectors aplicados a la primaria son propagados a el Standby Fisico en la forma de redo records, y aplicado como si una Base de Datos de Backup restaurada era recuperada(and applied as though a restored backup database were being recovered.). un Standby Lógico contiene los mismos datos como la primaria, pero posiblemente con diferentes Estructuras de Datos. Esto es para procesar consultas: La Base de Datos primaria tendrá estructuras de Datos optimizadas para procesamiento de transacciones; El Standby lógico tendrá estructuras optimizadas para trabajos tipo Data Warehouse.Las diferencias típicas estarían en la indexación. Change vectors son propagados en la forma de sentencias SQL, usando el mecanismo de Straeams.

EJERCICIO 2-1.

DETERMINANDO SI LA BASE DE DATOS ES SINGLE INSTANCE O PARTE DE UN SISTEMA DISTRIBUIDOR.

En este ejercicio, usted ejecutará consultas para determinar si la Base de Datos es un sistema autónomo, o si es parte de un entorno distribuido más grande.

1.Conéctese a la Base de Datos como usuario SYSTEM.

2.Determine si la instancia es parte de un RAC Database:

select parallel from v$instance;

Este retornará No si esta es una Base de Datos Single-Instance.

3.Determine si la Base de Datos está protegida contra perdida de datos por una Base de Datos en Espera.

select protection_level from v$database;

Esta retornará UNPROTECTED si la Base de Datos esta desprotegida.

4.Determine si Streams ha sido configurado en la Base de Datos.

select * from dba_streams_administrator;

Este retornará ningún registro, Si Stream nunca ha sido configurado.

OBJETIVO DE CERTIFICACIÓN 2.02.

EXPLICANDO LAS ESTRUCTURAS DE MEMORIA.

Una Instancia Oracle consiste de un bloque de memoria compartida conocida como la System Global Area, o SGA, y una serie de Procesos Background. Como mínimo, la SGA contendrá tres estructuras de datos:

- El Database Buffer Cache.

- El Log Buffer.

- El Shared Pool.

Puede, opcionalmente, también contener.

- Un Large Pool.

- Un Java Pool.

- Un Streams Pool.

Sesiones de usuario también necesitan memoria del lado de servidor. Esta es no compartida y es conocida como el Program Global Area, o PGA. Cada sesión tendrá su propia PGA privada.

EXAMEN

¿Qué estructuras SGA son requeridas y cuales son opcionales? El Database Buffer Cache, Log Buffer y Shared Pool son requeridas; El Large Pool, Java Pool, y Streams Pool son opcionales.

Administrar el tamaño de estas estructuras puede ser en gran parte automáticamente, o el DBA puede controlar el tamaño de las mismas. Es generalmente buena práctica utilizar la administración automática.

EL DATABASE BUFFER CACHE.

El Database Buffer Cache es el área de trabajo para ejecución de SQL. Cuando la actualización de datos, sesiones de usuarios no actualizan directamente los datos en el disco. Los bloques de datos que contienen los datos de interés son primeramente copiados en el Database Buffer Cache. Cambios (tales como inserción de nuevos registros y borrado o modificación de registros existentes) son aplicados a estas copias de los bloques de datos en el Database Buffer Cache. Los bloques permanecerán en el Cache por algún tiempo después, hasta que el buffer que ocupan es necesario para caching otro bloque.

Cuando consultas datos, los datos también van vía Cache. La sesión resuelve que los bloques contienen las filas de interés y los copia al Database Buffer Cache; los registros relevantes entonces se transfieren al PGA de la sesión para futuros procesamientos. Y otra vez, los bloques permanecerán en el Database Buffer Cache por algún tiempo después.

Tome nota del término Block. Los DataFiles son formateados en bloques de tamaño fijo. Filas de las Tablas, y otros objetos de datos tales como Index Keys, son almacenados en estos bloques. El Database Buffer Cache es formateado en buffers de memoria cada tamaño para mantener un bloque. A diferencia de los bloques, las filas son longitud variable; la longitud de una fila dependerá sobre el número de columnas definidas para la tabla, si las columnas tienen nada en ellos, y si es así, qué. Dependiendo del tamaño de los bloques (que es elegido por el DBA) y el tamaño de los registros (que depende de la tabla y su uso), puede haber varias filas por bloques o posiblemente una fila puede estar en varios bloques, la estructura de los Bloques de Datos será descrita en la sección de “DataFiles”.

Idealmente, todos los bloques contienen datos que son accesados frecuentemente estarán en el Database Buffer Cache, por lo tanto minimiza la necesidad de Disco. Como un uso típico del Database Buffer Cache, considere un usuario final recuperando un registro de empleado y su actualización, con estas declaraciones:

select last_name, salary, job_id from employees where employee_id=100;

update employees set salary=salary * 1.1 where employee_id=100;

commit;

El proceso usuario solicitará el empleado por el numero de empleado y construyo la instrucción SELECT. El SELECT recuperará algunos detalles para ser enviados al Proceso de usuario, donde serán formateados para desplegarlo. Para ejecutar esta instrucción, el proceso servidor de las sesiones leerá el Bloque da Datos que contiene las filas relevantes de un DataFiles en un Buffer. El proceso de usuario entonces iniciará una pantalla de dialogo para solicitar algún cambio que serán hechos y verificados, a continuación la instrucción UPDATE y la instrucción COMMIT serán construidas y enviadas a el Proceso Servidor para su ejecución. Previsto que un periodo excesivo de tiempo no ha transcurrido, El Bloque con el registro todavía estará disponible en el Cache cuando la instrucción es ejecutada. En este ejemplo, La Tasa de aciertos del Buffer Cache será de 50 porciento (%): Dos accesos de un Bloque en el Cache, pero solo una lectura del bloque al disco. El Database Buffer Cache bien afinado puede resultar en un cache con un porcentaje de aciertos de más del 90 por ciento.

Un Buffer almacenando un Block cuya imagen en el Cache no es lo mismo como la imagen sobre el disco a menudo es referido como un Buffer sucio. Un Buffer será limpio cuando un bloque primero se copia en él; en este punto; la Imagen del Bloque en el Buffer es lo mismo como la imagen del bloque sobre el disco. El buffer llegara a ser sucio cuando el block en el es actualizado. Eventualmente, los Buffers sucios se deben escribir de nuevo a los DataFiles, momento en el que el Buffer será limpio otra vez, incluso después de ser escrito en el Disco, el bloque permanece en memoria; es posible que el Buffer no será sobrescrito con otro bloque por algún tiempo.

Observe que no existe una correlación entre la frecuencia de actualizaciones a un Buffer(o el número de COMMITS) y cuando consigue escribir de nuevo en los DataFiles. El escribir a los DataFiles es hecho por el Proceso Background Database Writer (Database Writer Background Process).

El tamaño del Database Buffer Cache es crítico para el rendimiento. El cache debe ser del tamaño adecuado para almacenar todos los bloques accedidos frecuentemente (ya sea limpio o sucio) pero no tan grande que cachea bloques que son realmente necesarios. Un cache de tamaño inferior resultará en una excesiva actividad de disco, como los bloques de acceso frecuente son continuamente leídos de disco, utilizados, sobrescritos por otros bloques, y entonces leídos desde disco otra vez. Un cache de gran tamaño no es tan malo (siempre y cuando no es tan grande que el sistema operativo está teniendo que intercambiar las páginas de la memoria virtual dentro y fuera de memoria verdadera) pero puede causar problemas, por ejemplo, el Inicio de una instancia es más lento si se trata de un Database Buffer Cache masivo.

EXAMEN.

El tamaño del Database Buffer Cache puede ser ajustado dinámicamente, y puede ser administrado automáticamente.

EN EL TRABAJO.

La determinación del tamaño óptimo del Database Buffer Cache es una aplicación específica y un asunto ajuste de rendimiento. Es imposible dar otra cosa que una vaga directrices sin hacer observaciones, pero es probable que sea cierto que la mayoría de las bases de datos funcionará bien con una caché de tamaño en cientos de megabytes hasta unos pocos gigabytes. Muy pocas aplicaciones rendirán bien con un cache pequeño que estos, y no muchos necesitarán un cache de centenares de gigabytes.

El Database Buffer Cache es asignado en el momento de inicio de la instancia. Antes de la versión 9i de la base de datos no era posible cambiar el tamaño del Database Buffer Cache sin reiniciar la instancia de Base de Datos, pero desde 9i en adelante esta puede ser ajustada en cualquier momento.

Este cambio de tamaño puede ser manual, o (desde la versión 10g en adelante) automático en función de la carga de trabajo, si el mecanismo automático ha sido habilitado.

EL LOG BUFFER.

El Log Buffer es una pequeña área, a corto plazo de parada para los change vectors antes de que se escriban en el Redo Log en Disco. Un change Vector es una modificación aplicada a algo; Ejecutando instrucciones DML genera change vectors aplicados a los a datos. El Redo Log es la garantía de la Base de Datos que los datos nunca se perderán: cada vez que un Bloque de Datos es cambiado, los change vectors aplicados al Block son escritos al Redo Log, desde donde pueden ser extraídos y aplicados a los respaldos de los DataFiles si fuera necesario para restaurar un DataFile.

Redo no escribe directamente a los Archivos Redo Log por Procesos de Servidor de la sesión. Si lo fuera, Las sesiones tendrían que esperar operaciones de entrada-salida del disco a completarse siempre que se ejecute una instrucción DML. En lugar, las sesiones escriben el Redo al Log Buffer, en memoria. Esto es mucho más rápido que escribir en el disco. El Log Buffer se escribe a los archivos de Redo Log. Una escritura del Log Buffer a disco puede por lo tanto ser un proceso en lote de muchos change vectors de muchas transacciones. Sin embargo, los change vectors en el Log Buffer son escritos a disco en tiempo casi real-y cuando una sesión emite una sentencia COMMIT, el Log Buffer (Que pueden contener vectores cambio de muchas sesiones, intercalados entre sí) escribe realmente lo que hace en tiempo real. Las escrituras son hechas por el Proceso Background Log Writer, el LGWR.

El Log Buffer es pequeño (en comparación con otras Estructuras de Memoria) porque es un área de almacenamiento a muy corto plazo. Los Change Vectors se insertan en él y fluyen a disco en casi tiempo real.

No hay necesidad para que sea más que unos pocos megabytes a lo mucho, y de hecho haciendo esto mucho más grande que el valor por default puede ser seriamente malo para el rendimiento. El Valor por default es determinado por el Servidor Oracle y es basado en el número de CPUS en el nodo de Servidor.

No es posible crear un Log Buffer más pequeño que el valor por default. Si usted intenta, esto será establecido al tamaño por default de todos modos. Es posible crear un Log Buffer más grande que el Valor por default, pero esto no es una buena idea. El problema es que cuando una sentencia COMMIT es emitida, parte del procesamiento del commit implica escribir el contenido del Log Buffer a los archivos Redo Log en Disco. Esta escritura se produce en tiempo real, y mientras esta en progreso, la sesión que emita el COMMIT se colgará. Procesamiento Commit es una parte crítica de la Arquitectura Oracle. La garantía que una transacción committed nunca será perdida está basada en esto: El mensaje de commit completado no se devuelve a la sesión hasta que los Block de Datos en el Cache se han cambiado (que significa que la transacción ha sido completada) y los change vectors han sido escritos al Redo Log en Disco (y por lo tanto la transacción podría ser recuperada si es necesario). Un Log Buffer grande significa que potencialmente hay mas para escribir cuando es emitida una sentencia COMMIT, y por lo tanto esto puede tomar más tiempo antes de que el mensaje commit complete pueda ser enviado, y la sesión pueda reanudar el trabajo.

EN EL TRABAJO.

Aumentar el tamaño al Log Buffer arriba del valor por default puede ser necesario para algunas aplicaciones, pero como una regla inicie ajustando el Log Buffer en default.

El Log Buffer se asigna durante el inicio de la Instancia, y este nunca puede ser cambiado de tamaño subsecuentemente sin reiniciar la instancia. Este es un buffer circular. Como procesos de servidor escriben Change Vectors a este, la dirección actual de escritura se mueve alrededor(As server processes write change vectors to it, the current write address moves around. - Como servidor de los procesos de escribir vectores modificación de la misma, la escritura actual dirección se mueve alrededor.). El proceso Log Writer escribe los Vectors en lotes, y como lo hace, el espacio que ocuparon llega a estar disponible y se pueden sobre escribir más change vectors. Es posible que en momento de máxima actividad, change vectors se generaran más rápido que el proceso Log Writter pueda escribirlos. Si esto sucede, toda la actividad DML cesará (por unos pocos milisegundos), mientras que el Log Writer limpie el buffer. El proceso de limpiar el Log Buffer a disco es uno de los últimos cuellos de botella en la Arquitectura de Oracle. No puede hacerse más rápida las DML que el LGWR pueda vaciar los change vectors a los archivos Online Redo Log.

EN EL TRABAJO.

Si la generación de Redo es el factor limitante en el rendimiento de una Base de Datos. La única opción es ir a RAC. En una Base de Datos RAC, cada su instancia tiene su propio Log Buffer, y su propio LGWR. Esta es la única manera para Paralelizar la escritura de Datos Redo a Disco.

EXAMEN.

El tamaño del Log Buffer es estático, fijado en el inicio de la instancia. Este no puede ser administrado automáticamente.

EL SHARED POOL.

El Shared Pool es la más compleja de las estructuras de SGA. Está dividida en decenas de subestructura, todos los cuales son administrados por el Servidor Oracle. Esta discusión de la arquitectura mencionará solamente cuatro de los componentes del Shared Pool, y estos solamente brevemente.

- Library Cache.

- Data Dictionary Cache.

- PL/SQL Area.

- SQL query y PL/SQL function result cache.

Algunas otras estructuras serán descritas en capítulos posteriores. Todas las estructuras dentro del Shared Pool son administradas automáticamente. El tamaño será acorde al patrón de actividad contra la instancia, dentro del tamaño total de la Shared Pool. La Shared Pool en si mismo puede cambiar de tamaño de forma dinámica, o en respuesta a las instrucciones del DBA o por haber gestionado automáticamente.

EXAMEN.

El tamaño del Shared Pool es dinámico y puede ser gestionado automáticamente.

LIBRARY CACHE.

El Library Cache es un Área de Memoria para almacenar el código recientemente ejecutado, en su forma analizada. Analizar es la conversión de código escrito por programadores en algo ejecutable, y es un proceso que Oracle hace en demanda. Almacenar código analizado en el Shared Pool para poderlo reutilizar sin reanalizar, el rendimiento puede mejorar mucho. Analizar código SQL toma tiempo. Considere una simple instrucción SQL.

select * from employees where last_name='KING';.

Antes que esta instrucción pueda ser ejecutada, El Servidor Oracle tiene que resolver que significa, y como ejecutarlo. Para comenzar, que es employees? Es una tabla, un sinónimo, o una vista? Incluso existe? Entonces el “*” - ¿Cuáles son las columna que conforman la tabla employees (si esta es una tabla)? El usuario tiene permisos para ver la tabla? Las respuestas a estas preguntas y muchas otras tienen que ser encontradas en el Diccionario de Datos.

EN EL TRABAJO.

El algoritmo utilizado para buscar instrucciones SQL en el Library Cache está basado sobre los valores ASCII de los caracteres que componen la instrucción. La menor diferencia (incluso algo tan trivial como SELECT en lugar de select) significa que la declaración no coincide, sino que se va a analizar de nuevo.

Resolviendo lo que significa la declaración realmente, el servidor tiene que decidir la mejor manera de ejecutarlo. Hay un índice sobre la columna last_name? Si es así, serie más rápido usar el índice para localizar la fila, o para explorar toda la tabla. Más consultas contra el diccionario de datos… es muy posible que una simple consulta de una línea contra una tabla de usuario genere decenas de consultas contra el diccionario de datos, y para el análisis de una instrucción tome muchas veces más largo que el tiempo de ejecución. El propósito del Library Cache del Shared Pool es almacenar declaraciones en su forma analizada, lista para su ejecución. La primera vez que la instrucción es emitida, esta será analizada antes de su ejecución. La segunda vez, esta puede ser ejecutada inmediatamente. En una aplicación bien diseñada, es posible que las declaraciones se puedan analizar de una vez ejecutada millones de veces. Esto ahorra una gran cantidad de tiempo

DATA DICTIONARY CACHE.

El Data Dictionary Cache es algunas veces se refiriere a el Row Cache. Sea cual sea el término que usted prefiera, almacena las definiciones de objetos recientemente utilizados: descripciones de tablas, índices, usuarios, y otras definiciones de metadatos. Manteniendo tales definiciones en la memoria SGA, donde son inmediatamente accesibles a todas las sesiones, en lugar que cada sesión tenga que leer varias veces el diccionario de datos desde el disco, mejora el rendimiento del análisis.

El Data Dictionary Cache almacena definiciones de objetos de modo que cuando las instrucciones tienen que ser analizadas, pueden ser analizadas rápidamente – sin tener que consultar el diccionario de datos. Considere que ocurre si estas sentencias son emitidas consecutivamente:

select sum(salary) from employees;.

select * from employees where last_name='KING';.

Ambas declaraciones deben ser analizadas porque son declaraciones diferentes-pero analizar la primera instrucción SELECT habrá cargado la definición de la tabla Employees y de sus columnas en el Data Dictionary Cache, para analizar la segunda instrucción será más rápido de lo que debiera haber sido, porque no será necesario acceder al Diccionario de Datos.

EN EL TRABAJO.

La afinación de Shared Pool es por lo general orientados hacia asegurar que El Library Cache es del tamaño correcto. Esto es porque los Algoritmos de Oracle para asignar memoria en la SGA utilizan algoritmos diseñados a favor del Dictionary Cache, Así que si Library Cache es correcto, entonces el Dictionary Cache ya será correcto.

PL/SQL AREA.

Los objetos almacenados de PL/SQL son Procedimientos, Funciones, paquetes de procedimientos y funciones, definiciones de tipos de objetos, y Triggers. Todos estos son almacenados en el Diccionario de Datos, como el código fuente y también en su forma compilada. Cuando un objeto PL/SQL almacenado es invocado por una sesión, este debe ser leído del Diccionario de Datos, para prevenir repetir la lectura, los objetos son entonces guardados (Cached) en el PL/SQL Area de la Shared Pool.

La primera vez que un objeto PL/SQL es utilizado, este debe ser leído desde las tablas del Diccionario de Datos en disco, pero las invocaciones subsecuentes serán mucho más rápido, porque el objeto estará disponible en el PL/SQL Area de la Shared Pool.

EN EL TRABAJO.

PL/SQL pueden ser emitidos desde procesos de usuario, en lugar de ser almacenados en el Diccionario de Datos. Estos son llamados PL/SQL anónimos. PL/SQL anónimos no pueden ser guardados (Cached) y ser reutilizados, pero debe compilarlo dinámicamente. Por lo tanto, siempre se comportará peor que almacenado PL/SQL. Desarrolladores deberían se alentados a convertir todos los PL/SQL anónimos a PL/SQL Almacenados.

SQL QUERY Y PL/SQL FUNCTION RESULT CACHE.

El Result Cache es una nueva característica en la versión 11g. En muchas aplicaciones, la misma consulta es ejecutada muchas veces, ya sea por la misma sesión o muchas sesiones diferentes. Creando un Result Cache permite al Servidor Oracle almacenar los resultados de tales querys en memoria. La siguiente vez que la consulta es emitida, en lugar de ejecutar la consulta el servidor puede recuperar los resultados guardados en el cache (Cached). El mecanismo de Result Cache es los suficientemente inteligente para rastrear si las tablas contra la que la consulta fue ejecutada han sido actualizadas. Si esto ha sucedido, el resultado de la consulta serán invalidados y la siguiente vez la consulta emitida, esta será ejecutada nuevamente. Por lo tanto, no hay peligro de alguna vez recibir un Result Cache fuera de fecha.

El PL/SQL Result Cache utiliza un mecanismo similar, cuando una función PL/SQL es ejecutada. Este valor retornado puede ser almacenado preparado para la siguiente vez que la función es ejecutada. Si los parámetros pasados a la función, o las tablas que la función consulta, son diferentes, la función será recalculada, pero por lo contrario, El valor almacenado será el retornado.

Por default, el SQL Query y el PL/SQL Function Result Cache esta deshabilitado, pero si habilita este programáticamente, usted puede obtener mejoras drásticas en el rendimiento. El cache esta dentro del Shared Pool: a diferencia de as otras áreas de memoria descritas previamente, esto permite hacer al DBA algún control; él puede especificar el tamaño máximo.

TAMAÑO DEL SHARED POOL.

El tamaño del Shared Pool es crítico para el rendimiento. Este debe ser suficientemente grande para almacenar (cache) todo el código ejecutado frecuentemente y definiciones de objetos frecuentemente necesarias (en el Library Cache y el Data Dictionary Cache) pero no tan grande que almacene instrucciones que solo sean ejecutadas solamente una vez. Un tamaño menor del Shared Pool deteriora el rendimiento porque las sesiones de servidor tienen que tomar repetidas ocasiones el espacio para analizar sus instrucciones, que luego son sobrescritas por otras instrucciones y por lo tanto tiene que ser analizadas nuevamente cuando son re ejecutadas. Un Shared Pool de gran tamaño puede impactar negativamente sobre el rendimiento ya que necesita demasiado tiempo para buscar. Si el Shared Pool es menor que el tamaño optimo, el rendimiento se degradará. Pero hay un tamaño mínimo debajo del cual las declaraciones fallarán.

La memoria en el Shared Pool es asignada acorde al Algoritmo LRU(Lo menos Recientemente Utilizado – Least Recently Used). Cuando el Servidor Oracle necesita espacio en el Shared Pool, este sobrescribirá los objetos que no han sido utilizados por largo tiempo. Si el objeto es mas tarde necesario nuevamente. Este tiene que ser recargado – posiblemente sobrescribiendo otro objeto.

El Shared Pool es asignado en el momento de inicio de la instancia. Anteriores versiones a 9i de la Base de Datos no era posible cambiar el tamaño del Shared Pool sin reiniciar la Instancia de Base de Datos. Pero desde la 9i en adelante puede ser cambiada de tamaño arriba o abajo en cualquier momento. Este cambio de tamaño puede ser manual(desde la versión 10g en adelante) o automático en función de la carga de trabajo, si el mecanismo ha sido habilitado.

EXAMEN.

El Tamaño del Shared Pool es dinámico y puede ser administrado automáticamente.

EN EL TRABAJO.

Determinar el tamaño óptimo es un asunto de ajuste de rendimiento, pero es probablemente seguro decir que la mayoría de Bases de Datos necesitarán un Shared Pool de varios cientos de megabytes. Algunas aplicaciones necesitarán una o más que un gigabytes, y muy pocos se desempeñaran adecuadamente con menos que un ciento de megabytes.

EL LARGE POOL.

El Large Pool es un área opcional, será utilizado automáticamente por varios procesos que de otra manera tomarían del Shared Pool. Uno de los usos principales del Large Pool es por Procesos Shared Server (Servidor compartido), que se describe en el capítulo 6 en la discusión del Shared Server (Servidor Compartido) Servidores de ejecución Paralela también utilizan el Large Pool, si hay uno. En la ausencia de un Large Pool, estos procesos usaran memoria en la Shared Pool. Esto puede causan mala contención para el Shared Pool. Si Shared Server (Servidor Compartido) o Servidores paralelos se están utilizando, un Large Pool debería siempre ser creado. Algunos procesos I/O pueden también hacer uso del Large Pool, tales como el Procesos utilizado por el Recovery Manager cuando está realizando un respaldo a un dispositivo de cinta.

El tamaño del Large Pool no es asunto de rendimiento. Si un proceso necesita memoria del Large Pool, fallará con un error si esa memoria no está disponible. Asignando más memoria que sea necesaria no hará las instrucciones más rápidas, además, si existe una Large Pool, esta será utilizado: no es posible para una declaración iniciar usando la Large Pool, y luego volver a la Shared Pool si la Large Pool es demasiado pequeña.

Desde 9i release 2 en adelante es posible crear y cambiar el tamaño al Large Pool después de iniciar la instancia, con versiones anteriores, tenía que ser definido en el inicio y era de tamaño fijo. Desde la versión 10g en adelante, la creación y el tamaño del Large Pool puede ser completamente automático.

EXAMEN.

El Tamaño del Large Pool es dinámico y puede ser gestionado automáticamente.

JAVA POOL.

El Java Pool solo es requerido si su aplicación va a ejecutar Store-Procedures Java en la Base de Datos: es utilizado por el espacio Heap para instanciar los objetos Java. Sin embargo, una serie de opciones Oracle son escritas e Java, lo que la Java Pool es considerada standard en la actualidad. Tenga en cuenta que código Java no es almacenado (cache) en el Java Pool. Es almacenado en el Shared Pool, en la misma manera que el código PL/SQL está depositado.

El tamaño óptimo de la Java Pool depende de la Aplicación Java, y cuantas sesiones están ejecutándose. Cada sesión requiere espacio en el Heap para sus objetos. Si el Java Pool es de tamaño inferior, el rendimiento puede degradarse debido a la necesidad de reclamar continuamente el espacio. En una aplicación EJB(Enterprise JavaBean), un objeto tal como un bean de sesión sin estado puede ser instanciado y utilizado, y entonces permanecerá en la memoria en caso de que se vuelva a usar: Como un objeto puede ser reutilizado inmediatamente. Pero si el Servidor Oracle ha tenido que destruir el Bean para espacio para otro, entonces tendrá que ser reinstanciado la próxima vez que sea necesario. Si el Java Pool es crónicamente inferior de tamaño, entonces las aplicaciones pueden fallar.

Desde 10g en adelante es posible crear y cambiar de tamaño el Large Pool después de iniciar la instancia; esta creación y tamaño del Large Pool pueden ser completamente automáticos. Con versiones anteriores, tenía que ser definido en el inicio y era de tamaño fijo.

EXAMEN.

El tamaño de Java Pool es dinámico y puede ser gestionado automáticamente.

EL STREAM POOL.

El Streams Pool es utilizado por el Oracle Streams. Esta es una herramienta avanzado que esta mas allá del alcance del Examen OCP o este libro. El mecanismo utilizado por Streams es extraer Change Vectors desde el Redo Log de desde este reconstruir las declaraciones que fueron ejecutadas-o declaraciones que tendrían el mismo efecto. Estas declaraciones son ejecutadas en la Base de Datos Remota. Los procesos que extraen Changes Vectors desde el Redo Log y los procesos que aplican los Changes Vectors necesitan memoria: Esta memoria es el Streams Pool. Desde la base de datos 10g es posible crear y cambiar de tamaño el Streams Pool después de iniciar la Instancia; esta creación y tamaño pueden ser completamente automáticos. Con versiones anteriores se había que definir en el inicio y era de tamaño fijo.

EXAMEN.

El tamaño del Streams Pool es dinámico y puede ser gestionado automáticamente.

EJERCICIO 2-2.

Investigar las Estructuras de Memoria de la Instancia.

En este ejercicio, usted ejecutara consultas para determinar eñ tamaño actual de varias estructuras de memoria que constituyen la instancia.

1.Conéctese a la Base de Datos con el usuario SYSTEM.

2.Muestre tamaños máximos y mínimos de los componentes de la SGA que pueden ser cambiados de tamaño dinámicamente.

select COMPONENT,CURRENT_SIZE,MIN_SIZE,MAX_SIZE from v$sga_dynamic_components;

La ilustración muestra el resultado sobre una Base de Datos de ejemplo.

El ejemplo muestra una Instancia sin Streams, por lo tanto un Streams Pool de tamaño cero. Ni la Large Pool ni la Java Pool ha cambiado desde el inicio desde la instancia. Pero ha habido cambios hechos a el tamaño del Shared Pool y el Database Buffer Cache. Solo el Dafault Pool del Database Buffer Cache ha sido configurado, esto es usual, excepto en bases de datos muy ajustadas.

3.Determinar la cantidad de memoria, actual y asignada a la Program Global Area.

select name,value from v$pgastat where name in ('maximum PGA allocated','total PGA allocated');

OBJETIVO DE CERTIFICACIÓN 2.03.

DESCRIBIR LAS ESTRUCTURAS DE PROCESOS.

Los procesos Background de la Instancia son los procesos que son lanzados cuando la instancia es iniciada y se ejecutan hasta que esta es terminada. Hay cinco procesos Background que tienen una gran historia con Oracle; estos son los cinco primeros descritos en la sección que sigue: System Monitor (SMON), Process Monitor (PMON), Database Writer (DBWn), Log Writer (LGWR), Checkpoint Process (CKPT). Una serie de otros han sido introducidos con las versiones más recientes; entre ellos se destacan: Manageability Monitor (MMON), Memory Manager (MMAN). Hay también algunos que no son esenciales pero existen en la mayoría de las instancias. Estos incluyen a: Archiver (ARCn), Recoverer (RECO).

Otras existen solo si ciertas opciones han sido habilitadas, este último grupo incluye los procesos requeridos para RAC y Streams. Adicionalmente, existen algunos procesos que no están debidamente documentados. Hay una variación de plataforma que debe ser aclarado antes de discutir los procesos. Sobre Linux y Unix, todos los procesos Oracle son procesos separados del sistema operativo, cada uno con un número de proceso único. Sobre Windows, hay un solo proceso del Sistema Operativo (llamado ORACLE.EXE) para toda la instancia: los procesos Oracle se ejecutan como hilos separados dentro de este proceso.

SMON, EL SYSTEM MONITOR.

SMON tiene inicialmente la tarea del montaje y de abrir una Base de Datos, los pasos involucrados en esto son descritos en detalle en el Capitulo 5. En resumen, SMON monta una Base de Datos localizando y validando el Database ControlFile (ControlFile de la Base de Datos). Y luego abre una Base de Datos localizando y validando todos los DataFiles y Online Log Files. Una vez que la Base de Datos es Abierta y en uso, SMON es responsable de varias tareas de mantenimiento, tales como recopilación de espacio libre en DataFiles.

PMON, EL PROCESS MONITOR.

Una sesión de usuario es un Proceso de Usuario que está conectado a un Proceso Servidor. El proceso servidor es lanzado cuando la sesión es creada y destruido cuando la sesión es finalizada. Una salida ordenada de una sesión implica que el usuario cierra la sesión. Cuando esto ocurre, cualquier trabajo que estaba haciendo se completará de manera ordenada, y el proceso servidor será terminado. Si la sesión es terminada de una manera desordenada (quizás porque la PC es reiniciada), entonces la sesión será dejada en un estado que debe ser aclarado. PMON monitorea todos los procesos de servidor y detecta cualquier problema con las sesiones. Si una sesión es terminada anormalmente, PMON destruirá los procesos servidor, regresa su memoria PGA al Pool de memoria libre del Sistema operativo, y regresar cualquier transacción incompleta que puede haber estado en progreso.

EXAMEN.

Si una sesión es terminada anormalmente, que sucederá a una transacción activa? Será regresado (Roll Back) , por el proceso Background PMON.

DBWn, EL DATABASE WRITER.

Recuerde siempre que las sesiones como regla general no escriben a disco. Ellas escriben los datos a los búferes en el Database Buffer Cache. Es el Database Write que posteriormente escribe los búferes a Disco. Es posible para una instancia tener varios Database Writer (hasta un máximo de veinte (20)), que se llamarán DBW0, DBW1, y así en adelante: Por lo tanto el uso del término DBWn para referir al Database Write. El número predeterminado es un Database Writer por ocho CPU, reunidos.

EN EL TRABAJO.

Cuantos Database Writers usted necesita? El número predeterminado puede ser correcto. Agregar más puede ayudar al rendimiento, pero por lo general usted debería buscar ajustar primero la memoria. Como una regla, antes de que usted optimice la I/O en disco, preguntar porque existe alguna necesidad de disco I/O.

DBWn escribe Dirty Buffer (buffers sucios) Del Database Buffer Cache a los DataFiles-pero no escribe los buffers cuando se ensucien. Por el contrario: escribe buffers como pocos, Como se puede llegar lejos. La idea general es que la entrada-salida del disco es mala para el rendimiento, así que no hacerlo menos que realmente es necesario. Si un bloque en un Buffer ha sido escrito por una sesión, hay una posibilidad razonable que será escrito otra vez por esa sesión, u otra. ¿Por qué escribir el Buffer al Disco, si bien pueden ser ensuciados de nuevo en un futuro? El algoritmo utiliza DBwn para seleccionar dirty buffers para escribir a disco (cuál los limpiará) seleccionará solamente los buffers que no han sido usados recientemente. Así que si un buffer está muy ocupado, porque las sesiones son varias veces la lectura o escritura, DBWn no lo escribirá a disco. Podría haber cientos o miles de escrituras a un buffer antes de que DBWn lo limpie. Podría ser que un Buffer Cache de un millón de buffers, cientos miles de ellos son sucios-pero DBWn sólo podría escribir unos cuantos cientos de ellos en el disco a la vez. Estos serán los pocos cientos que ninguna sesión se ha interesado por algún tiempo.

EXAMEN.

¿Qué hará a DBRw a escribir? No hay Buffers Libres, buffers Demas sucios, tiempos de esperas de 3 segundos o un Checkpoint.

DBWn escribe según un algoritmo muy perezoso: lo menos posible, tan raramente como sea posible. Hay cuatro circunstancias que causarán a DBWn a escribir: No hay Buffers libres, buffers demás sucios, tiempos de esperas de 3 segundos y cuando hay un check point.

Primero, cuando no hay Buffers libres. Si un proceso servidor necesita para copiar un Block en el Database Buffer Cache, este debe encontrar un Buffer Libre. Un Buffer libre es un Buffer que no es ni sucio (actualizado, y que aun no vuelven a escribir a disco) ni fijado-cubierto (Un Buffer Fijado es uno que está siendo utilizado por otra sesión ese mismo momento). Un Buffer sucio no debe ser sobrescrito porque si fuera cambiado, los datos se perderían, y un Buffer fijado no puede ser sobrescrito porque los mecanismos del sistema operativo de protección de memoria no se permiten. Si un proceso servidor toma demasiado tiempo (Que es demasiado tiempo-largo. Esto es determinado internamente por Oracle) para encontrar un Buffer libre, señala el DBWn para escribir algunos Buffer Sucios a disco. Una vez hecho esto, serán limpios-por lo tanto libre, y disponible para su uso.

Segundo, puede haber demasiados Buffers sucios-“Demasiados” siendo otro umbral interno. Ningún proceso de servidor pudo haber tenido un problema el encontrar un Buffer Libre, pero total, podría haber una gran cantidad de Buffer sucios: esto hará que DBWn para escribir algunos de ellos a disco.

Tercero, hay tres-segundos de tiempo de espera: cada tres segundos, DBWn limpiará algunos Buffers. En la práctica, este evento puede no ser significativo en un sistema de producción porque las dos circunstancias previas descritas forzarán a escribir, pero el tiempo de espera incluso si el sistema está inactivo. En Database Buffer Cache eventualmente será limpiado.

Cuarto, puede haber un Checkpoint solicitado-requerido. Las tres razones ya dadas harán al DBWn escribir un número limitado de Buffers sucios a los DataFiles. Cuando ocurre un CheckPoint, todos los Buffer sucios son escritos. Esto podría significar cientos de miles de ellos. Durante un CheckPoint, las entrada salidas a disco llegaran a tope, el uso del CPU puede irse al 100%, sesiones de usuario final experimentarán una degradación de rendimiento, y la gente empezará a quejarse. Entonces cual el CheckPoint se ha completado (que puede tomar varios minutos) el rendimiento regresara a normal. Asi porque tener CheckPoints? La respuesta corta es, no los tiene a menos que usted tenga que.

EXAMEN

Que hace DBWn cuando una transacción es confirmada-commit? No hace absolutamente nada.

El único momento cuando un CheckPoint es absolutamente necesario es cuando la Base de Datos está cerrada y la instancia es apagada. Una secuencia de CheckPoint en el Capitulo 5. Un CheckPoint escribe todos los Buffers Sucios a disco: esto sincroniza el Buffer Cache con los DataFiles, la instancia con la Base de Datos. En ejecución normal, los DataFiles están siempre fuera de fecha: pueden ser cambios que faltan (committed y un committed). Esto no importa, porque las copias de los Block en el Buffer Cache esta a la fecha, y es estos en las cuales las sesiones trabajan. Pero en un Shutdown, es necesario escribir todo a disco. CheckPoint Automático solo se producen en el Shutdown. Pero un CheckPoint puede ser forzado en cualquier momento con esta declaración:

alter system checkpoint;

Observe que desde la versión 8i en adelante, los CheckPoint no ocurren en el Log Switch. El CheckPoint descrito hasta ahora es un CheckPoint Full. CheckPoint Parciales que forzar a escribir todos los Buffer Sucios que contienen Block apenas de uno o más DataFiles en vez de la Base de Datos completa, ocurren con mucho más frecuencia: cuando un DataFile o un Tablespace se toma fuera de línea; cuando un Tablespace se pone en modo Backup; cuando un Tablespace es hecho Read-Only. Estos son menos drásticos que un CheckPoint Full, y ocurren automáticamente siempre que suceda el acontecimiento relevante.

Para concluir, El DBWn escribe en un algoritmo muy perezoso: lo menos posible, tan raramente como sea posible-excepto cuando un CheckPoint ocurre, cuando todos los Buffer sucios son escritos a disco, lo más rápido posible.

LGWR, EL LOG WRITER.

El LGWR escribe el contenido del Log Buffer a los Online Log Files en disco. Una escritura del Log Buffer a los Online Redo Log Files es a menudo referida como vaciar (limpiar) el Log Buffer. Cuando una sesión realiza cualquier cambio (INSERT, UPDATE o DELETE) a los Blocks en el Database Buffer Cache, antes de aplicar el cambio en el Block este escribe el Change Vector que está cerca de aplicarse al Log Buffer. Para no perder ningún trabajo, estos Change Vectors deben ser escritos a disco con el mínimo tiempo de retardo. Con este fin, el LGWR vuelca el contenido del Log Buffer a los Online Redo Log Files en disco en casi tiempo real. Y cuando una sesión emite un COMMIT, el LGWR escribe en tiempo real: La sesión se bloquea, mientras LGWR escribe el Buffer a Disco. Solo hasta entonces la transacción guardada es Confirmada (commited), y por lo tanto no reversible.

LGWR es uno de los últimos cuellos de botella en la Arquitectura Oracle. Es imposible hacer DML más rápidas que LGWR pueda escribir los Change Vectors a disco. Hay tres circunstancias que causaran a LGWR vaciar (volcar) el Log Buffer: si una sesión emite un COMMIT, si el Log Buffer esta a una tercera parte de lleno; si DBWn esta apunto de escribir Buffer sucios.

Primero, Escribir un Commit. Para procesar un COMMIT, el proceso servidor inserta un registro confirmado (commit record) en el Log Buffer. Y a continuación se bloqueará, mientras LGWR vacía el Log Buffer a Disco. Solo cuando esta escritura se ha completado un mensaje de Commit-complete es regresado a la sesión. Y el proceso servidor puede continuar trabajando. Esta es la garantía que las transacciones nunca se perderán: cada Change Vector para una transacción confirmada (transaction committed) estará disponible en el Redo Log en disco y por lo tanto ser aplicado a los Respaldos de DataFiles. Por lo tanto, si la Base de Datos es alguna vez dañada, puede ser restaurada desde un Backup y todo el trabajo hecho desde el Backup puede ser recuperado.

Segundo, cuando el Log Buffer esta a una tercera parte de lleno, LGWR vaciará a disco. Se trata de rendimiento. Si el Log Buffer es pequeño (usualmente debería ser) esta tercera parte de lleno (trigger) forzara a LGWR a escribir el Buffer a disco en casi tiempo real, incluso si no hay transacciones para confirmar. El Log Buffer para muchas aplicaciones será de tamaño óptimo de solo unos pocos megabytes. Las aplicaciones generaran suficiente Redo para llenar una tercera parte es una fracción de segundo, así LGWR será forzado a fluir los Change Vectors a disco continuamente, en casi tiempo real. Entonces, cuando una sesión hace COMMIT, probablemente no haya nada que escribir, así el COMMIT completará casi instantáneamente.

Tercero, cuando DBWn necesita escribir Buffers Sucios del Database buffer Cache a los DataFiles, antes de hacerlo, así señalara a LGWR para vaciar el Log Buffer a los Online Redo Log Files. Esto es para asegurar que siempre será posible revertir una transacción sin confirmar. El mecanismo de Transaction Rollback se explica completamente en el Capitulo 11. Por ahora, es necesario saber que es perfectamente posible que DBWn escribir una transacción sin confirmar a los DataFiles. Esto está muy bien. Siempre y cuando el Undo Data necesario para reversar la transacción se garantizar estar disponible. La generación de Undo Data también genera Change Vectors: pues estos estarán en los Redo Log Files antes que de los DataFiles sean actualizados, entonces el Undo Data necesario para regresar la transacción (si esto es necesario) puede ser reconstruido si es necesario.

Tenga en cuenta que se puede decir que hay un tiempo de Tres Segundos de espera que causa a LGWR escribir. De hecho, el tiempo de espera esta en DBWR-pero porque LGWR siempre escribirá justo antes de DBWn. En efecto, hay tres segundos de tiempo de espera sobre LGWR también.

EXAMEN

Cuando el LGWR vaciará el Log Buffer a disco? En un COMMIT, cuando el Log Buffer esta a una tercera parte de lleno, justo antes de que DBWn escriba.

EN EL TRABAJO.

De hecho, es posible prevenir el LGWR escribir-on-commit. Si se hace esto, las sesiones no tendrán que esperar a que LGWR cuando hay COMMIT: ellos emiten el comando y luego seguir trabajando. Esto mejorará el rendimiento pero también puede significar que el trabajo puede perderse. Llega a ser posible para una sesión a COMMIT, entonces, para la instancia halla un fallo antes de que LGWR guarde los Change Vectors. Habilite esto con cuidado! Es peligroso, y casi nunca es necesario. Hay solo unas pocas aplicaciones donde el rendimiento es más importante que la perdida de datos.

CKPT, EL PROCESO CHECKPOINT.

El propósito de CKPT cambio dramáticamente entre la versión 8 y la versión 8i de la Base de Datos Oracle. En la versión 8 y anteriores, CheckPoints fueron necesarios en intervalos regulares para asegurarse que en caso de un fallo (Por ejemplo, si el equipo servidor debe ser reiniciado) en la instancia de la Base de Datos podría ser recuperada rápidamente. Estos CheckPoints fueron iniciados por CKPT. El proceso de recuperación está reparando el daño hecho por el fallo en la Instancia. Esto es completamente descrito en el Capitulo 15.

En resumen, después de un accidente, todos los Change Vectors de referencia a los Buffers sucios (Buffers que no había sido escrito a disco por DBWn en el momento del fallo) deben ser extraídos del Redo Log, y aplicado a los Data Block. Este es el proceso de recuperación. CheckPoints Frecuentes se aseguraría que los Buffers Sucios fueran escritos a discos rápidamente, por lo tanto, reduciendo la cantidad de Redo que tendría que aplicarse después de un accidente y por lo tanto reducir el tiempo tomado para recuperar la Base de Datos. CKPT fue responsable de señalizar los CheckPoints regulares.

Desde la versión 8i en adelante, el mecanismo de CheckPoints a cambiado. En lugar de dejar que DBWN obtener un trayecto por detrás y luego un CheckPoint de señalización desde 8i en adelante el DBWn hace CheckPoint Incrementales (que forzara a DBWn a ponerse al día y hacerlo bien hasta la fecha, con una caída en el rendimiento mientras esto sucede) en lugar de CheckPoint completos. El mecanismo de CheckPoints incrementales instruye a DBWn a escribir Buffers sucios en un ritmo constante, de modo que siempre hay una brecha predecible entre DBWn (que escribe Blocks con un Algoritmo perezoso) y LGWR (que escribe Change Vectors en tiempo casi real). CheckPoints incrementales resulta en un rendimiento mucho más suave y tiempos de recuperación más fiables que el viejo mecanismo de CheckPoint completo.

El CKPT ya no tiene para señalar los CheckPoint Completos, pero tiene que hacer un seguimiento de donde en el Flujo del Redo esta la posición del CheckPoint Incremental (pero tiene que hacer un seguimiento del lugar de la corriente de hacer de nuevo la posición de punto de control incremental), y si es necesario dar instrucciones al DBWn para escribir algunos Buffers Sucios con el fin de impulsar la posición del CheckPoint hacia adelante. La posición actual del CheckPoint también conocida como el RBA (El Redo Byte Address), es el punto en el Flujo del Redo en la cual la recuperación debe iniciar en caso de un accidente en la instancia. CKPT continuamente actualiza el ControlFile con la posición actual del CheckPoint.

EXAMEN

¿Cuando ocurre un CheckPoint Completo? Solo a petición, o como parte de una parada de la Base de Datos ordenadamente.

EN EL TRABAJO.

Cuanto más rápido los avances del CheckPoint Incremental, la recuperación será más rápida después de un fallo. Pero el rendimiento se deteriorará debido a la carga extra en disco de Entrada/Salida, como DBWn a escribir Buffer Sucios más rápidamente. Este es un conflicto entre el tiempo de inactividad mínimo y maximizar el rendimiento.

MMON, EL MANAGEABILITY MONITOR.

MMON es un proceso que se introdujo con la Base de Datos Versión 10g y es el proceso que permite el auto-monitoreo y capacidades de auto-tuning de la Base de Datos. La instancia de la Base de Datos recopila una vasta cantidad de estadísticas sobre la actividad y rendimiento. Estas estadísticas son acumuladas en la SGA, y sus valores actuales pueden ser interrogados mediante la emisión de consultas. Para el ajuste de rendimiento y también para el análisis de tendencias e informes históricos, es necesario guardar estas estadísticas en almacenamiento a largo plazo. MMON regularmente (por defecto, cada hora) captura estadísticas de la SGA y escribe luego al Diccionario de Datos, donde se pueden almacenar por tiempo indefinido (aunque por defecto, se mantiene por solo ocho días).

Cada momento que MMON recopila un conjunto de estadísticas (conocido como snapshot-instantaneas), también lanza el Automatic Database Diagnostic Monitor, el ADDM. El ADDM es una herramienta que analiza la actividad de la Base de Datos mediante un sistema experto desarrollado durante muchos años por muchos DBAs. Se observa dos snapshots (por default, el actual y previo snapshot) y se hacen observaciones y recomendaciones con respecto al rendimiento. En el Capitulo 13 se describe el uso del ADDM (y otras herramientas) para desarrollar ajustes.

Así como la recopilación de snapshots, MMON continuamente monitorea la Base de Datos y la instancia para comprobar si alguna alerta debería elevarse. El uso de Alert System está cubierto para el segundo examen OCP. Algunas condiciones de alerta (tales como advertencias cuando los limites en almacenamiento son alcanzados) están habilitados por default; otros pueden ser configurados por el DBA.

EXAMEN.

Por defecto, MMON recopila un snapshot y la lanza el ADDM cada hora.

MMNL, EL MANAGEABILITY MONITOR LIGTH

El MMNL es un proceso que apoya al MMON. Hay momentos en que la actividad programada MMON no es suficiente. Por ejemplo, MMON vuelva la información estadística acumulada en la SGA a la base de datos de acuerdo a una programación: por default cada hora. Si los buffers de memoria utilizados para acumular esta información antes de llenar MMON se debe encarga de descargar, MMNL se encargará de volcar los datos.

MMAN, EL MEMORY MANAGER.

MMAN es un proceso que fue introducido con la Base de Datos versión 10g. Este permite la gestión automática de las asignaciones de memoria.

Antes de la versión 9i de la base de datos, la gestión de memoria en el entorno Oracle estaba lejos de ser satisfactoria. La memoria PGA asociada con procesos de servidor de sesión era intransferible: un proceso servidor tomaría la memoria del Pool de memoria libre del sistema operativo y nunca regresarla. A pesar de que solo podría haber sido necesaria por un corto tiempo. Las estructuras de memoria SGA eran estáticas: definidas en el momento de inicio de la instancia, e incambiable a menos que la instancia fuera reiniciada.

La versión 9i cambio eso: la PGA puede crecer y disminuir, con el servidor pasando memoria a las sesiones bajo demanda mientras asegura que la memoria total de PGA asignada se mantiene dentro de ciertos límites. La SGA y los componentes dentro de ella (con la notable excepción del Log Buffer) pueden ser cambiados de tamaño dentro de ciertos límites. La versión 10g automatiza el cambio de tamaño de la SGA: MMAN monitorea la demanda de Estructuras de memoria SGA y puede cambiar el tamaño según sea necesario.

La versión 11g lleva la administración de memoria un paso más allá: toda la necesidad del DBA es fijar un total para el uso de memoria, y MMAN observara la demanda de memoria PGA y memoria SGA, y asignara memoria a las sesiones y estructuras SGA como sea necesario, mientras se mantiene la memoria total asignada dentro de ciertos límites establecido por el DBA.

EN EL TRABAJO

La automatización de la gestión de memoria es uno de los mayores avances técnicos de los últimas versiones, la automatización de una gran parte del trabajo del DBA y dando enormes beneficios en el rendimiento y utilización de recursos. MMAN lo hace mejor que tú.

ARCn, EL ARCHIVER.

Este es un proceso opcional en cuanto a la Base de Datos se refiere, pero generalmente un proceso requerido para el negocio. Sin uno o más procesos ARCn (puede haber desde uno a treinta, llamados ARC0, ARC1, y así sucesivamente) es posible perder datos. El proceso y propósito de iniciar ARCn para crear Archive Log Files es descrito a detalle en el capítulo 15. Por ahora, solo un resumen que se necesita.

Todos los Change Vectors aplicados a los Data Blocks se ponen en escrito al Log Buffer (por las sesiones que realizan los cambios) y luego al Online Redo Log Files (por el LGWR). Los Online Redo Log Files son de tamaño fijo y número: una vez que se han llenado, LGWR los sobrescribirá con más datos Redo. El tiempo que debe transcurrir antes que estos suceda depende del tamaño y número de Online Log Files, y la cantidad de Actividad DML (y por lo tanto la cantidad de Redo Generado) contra la Base de Datos. Esto significa que el Online Redo Log solo almacena Chance Vectors de reciente actividad. Con el fin de preservar la historia completa de todos los cambios aplicados a los datos, los Online Log Files debe ser copiado, ya que se llena y antes de que sean reutilizados. El ARCn es responsable de hacer esto. A condición de que estas copias, conocidos como Archive Redo Log Files, están disponibles, siempre será posible recuperarse de cualquier daño a la Base de Datos mediante la restauración de copias de seguridad de los DataFiles y la aplicación de Change Vectors a los extraídos desde todos los Archive Log Files generados desde los Backups que fueron hechos. A continuación la recuperación final, para traer hasta la fecha vendrá de los Online Redo Log Files. La mayoría de las Bases de Datos Transaccionales en producción se ejecutaran en Modo Archive Log, lo que significa que ARCn se inicia automáticamente y que LGWR no se le permite sobrescribir un Online Log File hasta que ARCn ha archivado con éxito a un Archive Log File.

EXAMEN.

LGWR escribe los Online Log Files, ARCn los lee. En funcionamiento normal, ningún otro proceso los toca en absoluto.

EN EL TRABAJO.

El progreso de los Procesos ARCn y el estado de las destinaciones a las cuales son escritas deben ser monitoreados. Si archivado falla, la Base de Datos finalmente se colgara. Este monitoreo se puede hacer a través del sistema de alerta.

RECO, EL PROCESO RECOVERER.

Una transacción distribuida es una transacción que implica cambios a dos o más Bases de Datos. Las transacciones distribuidas son diseñadas por los programadores y operan atraves de database Links. Considere este ejemplo:

update employees set salary=salary * 1.1 where employee_id=1000;

update employees@dev set salary=salary * 1.1 where employee_id=1000;

commit;

La primera actualización se aplica a una fila en la Base de Datos Local; la segunda se aplica a una fila en una Base de Datos remota identificada por el Database Link DEV.

El comando COMMIT instruye a ambas Bases de Datos para confirmar la transacción, cual consiste en ambas declaraciones. Una descripción completa de Procesamiento de COMMIT aparece en el capítulo 10. Las transacciones distribuidas requieren de un COMMIT de Dos-Fases (Confirmación de dos fases). El COMMIT en cada Base de Datos debe ser coordinado: si uno fuera a falle y los otros fueran a tener éxito: Todos los datos estarían en un estado incoherente. El COMMIT de Dos-Fases prepara cada Base de Datos para instruir a sus LGWR para vaciar el Log Buffer a Disco (Primera Fase), y una vez esto confirmado, la transacción es marcada como confirmada en todas partes (Segunda Fase). Si algo va mal en cualquier lugar de las dos fases. RECO tomara medidas para cancelar el COMMIT y hará un RollBack al trabajo en todas las Bases de Datos.

ALGUNOS OTROS PROCESOS BACKGROUND.

- CJQ0, J000. Estos gestionan los trabajos programados para ejecutarse periódicamente. El Job Queue Coordinator, CJQn, monitorea la cola de trabajos y envía trabajos a uno de varios procesos de la cola de trabajo, Jnnn, para su ejecución. Tema del segundo Examen OCP.

- D000. Este es un proceso despachador que envía llamadas SQL a los procesos de Servidor compartido, Snnn, si el mecanismo de servidor compartido ha sido habilitado. Este es descrito en el capítulo 6.

- DBRM. El Database Resource Manager es responsable de establecer los planes de recursos y otras tareas relacionadas con gestión de recursos. Tema del Segundo examen OCP.

- DIA0. El proceso Diagnosability Cero (solo uno se utiliza en la versión actual) es responsable de la detección de bloqueos y resolución de DeadLock. DeadLocks y su resolución son descritos en el capítulo 10.

- DIAG. El Proceso Diagnosability (no numero cero) realiza volcados de diagnostico y ejecuta comandos oradebug (oradebug es una herramienta para investigar problemas dentro de la instancia).

- FBAR. El proceso FlashBack Data Archiver archiva as filas históricas de las tablas de seguimiento en los Datos de Archivos FlashBack. Esta es una instalación para asegurarse de que siempre es posible consultar datos como lo fue en un momento en el pasado.

- PSP0. El proceso spawner tiene la tarea de crear y gestionar de otros procesos de Oracle y no está documentado.

- QMNC, Q000. El Queue Manager Coordinator supervisa colas en la Base de Datos y asigna procesos Qnnn para encolar y quitar mensajes hacia y desde estas colas .Las colas puede ser creadas por programadores y también se utilizas Streams .Por ejemplo utilice las colas para almacenas las transacciones que necesitan ser propagadas a las Bases de Datos Remotas.

- SHAD. Estos se llamaran TNS V1-V3 en sistemas Linux. Estos procesos son procesos servidor que apoyan a sesiones de usuarios. En la figura hay solo una, ya que solo un usuario está conectado actualmente. El usuario que ha emitido la consulta.

- SMCO, W000. El Proceso Space Management Coordinator, coordina la ejecución de tareas diversas relacionadas con la gestión del espacio, tales como la asignación de espacio dinámico y recuperación del espacio. Se genera de forma dinámica los procesos de esclavo (Wnnn) para implementar la tarea.

- VKTM. El Virtual Keeper of Time es responsable de mantener el seguimiento del tiempo. Más complicado de lo que uno podría pensar. Particularmente en un entorno de Clustered.

EJERCICIO 2-3.

INVESTIGAR LOS PROCESOS EJECUTANDOSE EN SU INSTACIA.

En este ejercicio ejecutara consulta para ver que procesos Background están ejecutándose en su Instancia.

1.Conéctese a la Base de Datos con el usuario SYSTEM.

2.Determine que procesos están ejecutándose, y cuantos de cada uno:

select program from v$session order by program;.

select program from v$process order by program;.

3.Estas consultas darán resultados similares: cada proceso debe tener una sesión (incluso los procesos Background), y cada sesión debe tener un proceso. Los procesos que pueden ocurrir varias veces, tendrán un sufijo numérico, a excepto de los procesos que apoyan a las sesiones de usuario: todos estos tendrán el mismo nombre.

4.Demostrar la puesta en marcha de los procesos servidor cuando la sesiones se realizan, contando el número de procesos de servidor (en Linux o cualquier plataforma Unix) o el número de Oracle Threads (en Windows). La técnica es diferente en las dos plataformas, porque en Linux/Unix, los procesos de Oracle son procesos separados del sistema operativo, pero en Windows son hilos dentro de un proceso de sistema operativo.

A.En Linux, ejecute este comando desde el prompt del Sistema Operativo:

ps –ef | grep oracle | wc -1

Este contará el numero de procesos ejecutándose que tienen la cadena oracle en su nombre; este incluye todos los procesos de servidor de sesiones (y posiblemente algunos otros).

Lance una sesión SQL/PLUS, y vuelva a ejecutar el comando anterior: utilice el comando host para lanzar un Shell del sistema operativo desde dentro la sesión de SQL/PLUS. Usted verá el numero de procesos incrementará. Salir de la sesión, y usted verá que el número ha disminuidos de nuevo.

Observe en la ilustración como el número de procesos cambia de 4 a 5 y viceversa: la diferencia es la puesta en marcha y terminación de los procesos servidor de apoyo a la sesión de SQL/PLUS.

B.En Windows, lance el Task Manager. Configurar para mostrar el numero de hilos dentro de cada proceso: en la pestaña Ver, tome “Seleccionar columnas y marque la casilla de verificación hilos. Busque el proceso de ORACLE.EXE y tenga en cuenta el número de subprocesos. En la ilustración siguiente, esto es en la actualidad a los 33.”.

Lance una nueva sesión contra la instancia, y usted verá como incrementan los hilos. Salir de la sesión, y este decrementará.

DENTRO DEL EXAMEN.

LA RELACIÓN ENTRE PROCESOS, ESTRUCTURAS DE MEMORIA Y ARCHIVOS.

Es vital tener una comprensión de la Relación entre la Instancia y la Base de Datos. Este enlace es hecho por los procesos Background. Cuando una instancia inicia, la SGA es construida en memoria. Entonces los procesos Background se conectan con los archivos de Base de Datos en disco. Los procesos son el enlace entre las estructuras de memoria y las estructuras de disco.

Los DataFiles usualmente serán fuera de fecha: que no podrán contar con el trabajo que se ha hecho en memoria, porque el DBWn no ha encontrado el momento de escribir el trabajo a los archivos. No hay problema-en memoria, la información es en tiempo real, y eso es lo que las sesiones de usuario verán. En contraste, el Online Redo Log File son hasta la fecha, porque el LGWR escribe en casi tiempo real y cuando un usuario dice COMMIT, este hace la escritura en tiempo real.

Always be absolutely clear on which processes are reading and writing memory structures, and which are reading and writing disk structures.

OBJETIVO DE CERTIFICACION 2.04.

RESUMIR LAS ESTRUCTURAS DE ALMACENAMIENTO.

La Base de Datos Oracle ofrece una completa abstracción del Almacenamiento Lógico del Físico. El almacenamiento de datos Lógico es en segmentos. Hay varios tipos de segmentos; un segmento típico es una Tabla. Los segmentos son almacenados físicamente en DataFiles. La abstracción del Almacenamiento Lógico del almacenamiento físico es logrado atraves de Tablespaces. La relación entre las estructuras Lógicas y físicas, así como sus definiciones, son mantenidas en el Diccionario de Datos.

ESTRUCTURAS FISICAS DE LA BASE DE DATOS.

Hay tres tipos de archivos que conforman una Base de Datos Oracle, mas algunos otros que existen externamente de la Base de Datos y son, estrictamente hablando, opcionales. Los archivos requeridos son los ControlFiles, Los Redo Log Files, y los DataFiles. Los archivos externos que generalmente se presentan(Hay otros, necesarios para las opciones avanzadas) son el Initialization Parameter File, El Password File, El Archive Redo Log Files y el Log y Trace Files.

EXAMEN.

¿Cuáles son los tres tipos de archivos que deben estar presentes en una Base de Datos? El ControlFile, El Online Redo Log Files y cualquier número de DataFiles.

EL CONTROLFILE.

Primer punto de la terminología: algunos DBAs dirán, que una Base de Datos puede tener múltiples ControlFiles, mientras que otros dirán que tiene un ControlFile, del cual puede haber múltiples copias. En este libro seguiremos la última terminología. Que se ajusta a Oracle Corporation de frases tales como “Multiplexación de ControlFiles”, que significa crear múltiples copias.

El ControlFile es pequeño, pero vital. Contiene referencias al resto de la Base de Datos: La ubicación de los Online Redo Log Files y de los DataFiles y de los más recientes Archive Log Files si la Base de Datos esta en Modo Archive Log. Este también almacena la información necesaria para mantener la integridad de la Base de Datos: varios números de secuencia critica (critical sequence numbers) y marcas de tiempo (timestamps), por ejemplo. Si la Herramienta Recovery Manager (Descrita en el Capitulo 16 y 17) se utiliza para Backups, entonces los detalles de estos Backups serán almacenados en el ControlFile. El ControlFile suele ser no más que unos pocos Megabytes, pero no puede sobrevivir sin este.

Cada Base de Datos tiene un ControlFile, pero un buen DBA creará siempre múltiples copias del ControlFile, de modo que si se daña una copia, la Base de Datos sobrevivirá. Si todas las copias del ControlFile se pierden, es posible recuperar, pero nunca debe encontrarse en esa situación. Usted no tiene que preocuparse de mantener las copias multiplexadas del ControlFiles sincronizadas. Oracle se ocupara de eso. Su mantenimiento es automático. El único control es el número de copias que tiene, y donde ponerlos.

Si obtiene el número de copias, o su ubicación, incorrecto en el tiempo de creación de la Base de Datos, usted puede añadir o remover copias posteriores, o moverlos. Pero usted debería tener en cuenta que cualquier tipo de operaciones requerirá el tiempo de inactividad, por lo que es una buena idea hacerlo bien desde el principio. No hay bien o mal cuando determina el número de copias a tener. El mínimo es uno; el máximo posible es ocho. Todas las organizaciones deben tener un manual de normas de DBA, que expone algo así “Todas las Bases de Datos en Producción tendrá tres copias de los ControlFiles, en tres dispositivos diferentes” tres son un numero escogido solo para ilustración, pero un numero con que muchas organizaciones son felices. Si no hay tales indicaciones de este tipo, alguien debería escribirlos. No hay regla que dice que dos copias son demasiadas pocas, o siete copias es demasiado; hay solo estándares corporativos, y el trabajo del DBA es asegurarse de que las Bases de Datos se ajustan a estos.

El daño a cualquier copia de ControlFile hará que la instancia de base de datos terminar inmediatamente. No hay manera de evitar esto: Oracle Corporation no permite operar una Bases de datos con menos que el número de ControlFiles que se han solicitado. La técnicas de multiplexación o relocalización son tratados en el Capitulo 15.

EL ONLINE REDO LOG FILES.

El Redo Log almacena una cadena continua en orden cronológico de cada change vector aplicado a la Base de Datos. Esta será la mínima cantidad de información requerida para reconstruir, o rehacer, todo el trabajo que ha sido hecho. Si un DataFile(o la totalidad de la Base de Datos) es dañado o destruido, estos change vector pueden ser aplicados a los respaldos del DataFile para rehacer de nuevo el trabajo, trayéndolo hacia adelante en el tiempo, hasta el momento en que ocurrió el daño. El Redo Log consiste en dos tipos de archivos: El Online Redo Log Files (Que son requeridos) y el Archive Log Files (Que son opcionales). Cada Base de Datos tiene al menos dos Online Redo Log Files, pero como con los ControlFiles, un buen DBA crea múltiples copias para cada Online Redo Log File. El Online Redo Log consiste en grupos de Online Redo Log Files, cada archivo será conocido como un miembro. Una Base de Datos Oracle requiere al menos de dos grupos de al menos un miembro cada uno para su funcionamiento. Usted puede crear más de dos grupos por razones de rendimiento, y más de un miembro por grupo por seguridad. El requerimiento de un mínimo de dos grupos es para que un grupo pueda aceptar los cambios actuales, mientras que el otro grupo está respaldando (o archivando-archived, para usar el término correcto).

EXAMEN.

Cada Base de Datos debe tener al menos dos Grupos de Online Redo Log File para funcionar, cada grupo debería tener al menos dos miembros por seguridad.

Uno de los Grupos es el Grupo Actual: los cambios son escritos al actual Online Redo Log File Group por el LGWR. Mientras las sesiones de usuario actualizan datos en el Database Buffer Cache, también escriben los change vector mínimos al Redo Log Buffer. LGWR limpia continuamente este buffer a los archivos que conforman el actual Online Redo Log File Group. Los archivos Log son de tamaño fijo; por lo tanto, los archivos que conforman el grupo actual se llenarán. LGWR entonces realizará lo que es llamado un switch de log. Esto hace que el segundo grupo actual y comienza a escribir. Si su Base de Datos se configura correctamente, los procesos ARCn entonces archivará los miembros Log File que conforman el primer grupo, cuando el segundo grupo llena, LGWR volverá al primer grupo, haciendo este actual, y sobrescribiéndola; ARCn entonces archivará el segundo grupo. Por lo tanto, El Online Redo Log File Groups se utilizan en forma circular, y cada switch generará un archivado de Redo Log File.

Como con el ControlFile, si usted tiene múltiples miembros por grupo (y debe!) usted no tiene preocuparse por mantenerlos sincronizados. LGWR se asegurará de que escriba a todos, paralelamente, así mantenerlos idénticos. Si usted pierde un miembro del grupo, mientras tenga un miembro sobreviviente, la base de datos puede continuar con su funcionamiento.

El tamaño y número de sus grupos Log File son una cuestión de ajuste. En general, usted elije el tamaño adecuado a la cantidad de actividad que usted anticipa. El tamaño mínimo es cincuenta megabytes, pero algunas bases de datos muy activas necesitarán levantar esto a varios gigabytes sino son llenados en muy pocos minutos. Una Base de Datos muy ocupada puede generar megabytes de Redo en un segundo, mientras una base de datos estática puede generar solo unos pocos megabytes en una hora. El número de miembros por grupo dependerá de que nivel de tolerancia a fallos se considere necesario, y es una cuestión que se documenta en los estándares corporativos. Sin embargo, no tiene que preocuparse acerca de esto en el tiempo de la creación de la Base de Datos. Puede mover sus Online Redo Log Files alrededor, añadir o eliminar, y crear unos de diferentes tamaños cuando desee en cualquier momento más tarde. Estas operaciones se realizan en línea y no requieren tiempo de inactividad por lo que son transparentes para los usuarios finales.

LOS DATAFILES.

El tercer tipo de archivo requerido para conformar una Base de Datos es el DataFile. Como un mínimo, debe tener dos DataFiles, serán creados en la Base de Datos en tiempo de creación. Con versiones previas de Oracle, usted puede crear una Base de Datos con solo un DataFile-10g y 11g requieren dos, al menos uno cada uno, para el Tablespace SYSTEM (que almacena el Diccionario de Datos) y el Tablespace SYSAUX (que almacena datos que son auxiliares para el Diccionario de Datos.). Usted, sin embargo. Tendrá mucho más que eso cuando su base de datos es útil, y generalmente creará unos pocos más para iniciar.

Los DataFiles son el repositorio para los Datos. Su tamaño y número son prácticamente ilimitados. Una pequeña Base de Datos, de solo unos pocos gigabytes. Podría tener solo media docena de DataFiles de solo unos pocos cientos de megabytes cada una. Una Base de Datos más grande podría tener miles de DataFiles, cuyo tamaño es limitado solo por la capacidad del sistema operativo host y el hardware.

Los DataFiles son las Estructuras Físicas visible al Administrador de Sistema. Lógicamente, son el Repositorio de los segmentos que contienen los datos del usuario que los programadores consideran, y también para los segmentos que conforman el Diccionario de Datos.

Un segmento es una estructura de almacenamiento para datos; segmentos típicos son Tablas e Índices. Los DataFiles pueden ser renombrados, cambiados de tamaño, mover, agregar o eliminar en cualquier momento de la vida útil de la Base de Datos, pero recuerde que algunas operaciones en algunos DataFiles pueden requerir tiempo de inactividad.

A nivel del Sistema Operativo, un DataFile consiste en un número de bloques del Sistema Operativo. Internamente, los DataFiles son formateados en Oracle Blocks. Estos bloques son numerados consecutivamente dentro de cada DataFile. El tamaño del Block es fijado cuando el DataFiles es creado. Y en la mayoría de circunstancias, será el mismo en toda la Base de Datos. El tamaño del Block es una cuestión para ajuste y puede variar (con limites dependiendo de la plataforma) desde 2KB hasta 64 KB. No hay relación entre el tamaño de Oracle Block y el tamaño de Block del Sistema Operativo.

EN EL TRABAJO.

Muchos DBA tienen gusto de emparejar el Tamaño de Block de sistema Operativo al tamaño de block de Oracle Block. Por motivos de rendimiento, los Blocks de Sistema Operativo nunca deben ser más grandes que los Oracle Blocks, pero no hay razón no tenerlos más pequeños. Por ejemplo, un 1KB de tamaño de block de sistema operativo y 8KB de tamaño de Oracle Block es perfectamente aceptable.

EXAMEN.

Procesos Servidor leen desde el DataFile; DBWn escribe al DataFile.

Dentro de un block, hay una sección de encabezado y un área de datos, y posiblemente algún espacio libre. La sección de encabezado contiene información tal como el directorio de la fila, que lista la ubicación dentro del área de datos de las filas en el Block (si el Block se está utilizando para un segmento de tabla) y también la información de bloqueo de fila si hay una transacción trabajando sobre la fila en el block. El área de datos contiene los datos, tales como filas si es parte de un segmento de tabla, o llaves de índices si el block es parte de un segmento de índice.

Cuando una sesión de usuario necesita trabajar sobre los datos para cualquier propósito, el proceso servidor que soporta la sesión, localiza el block relevante en el disco y copia este en un buffer libre en el Database Buffer Cache. Si los datos en el bloque entonces se cambian (El buffer es sucio) ejecutando un comando DML contra él, Eventualmente DBWn escribirá el Block de regreso al DataFile en Disco.

Los DataFiles deberían ser respaldados regularmente. A diferencia los ControlFiles y los Online Redo Log Files, no pueden ser protegidos por multiplexación (Aunque pueden, por supuesto, estar protegidos por el sistema operativo y las instalaciones de hardware, tales como RAID.). Si un DataFile es dañado, este puede ser restaurado desde un Backup y entonces recuperado (para recuperar un DataFile significa traerlo hasta la fecha) aplicando todo el Redo generado desde que el Backup fue hecho. El Redo necesario extrae los Change Vectors en el Online y Archive Redo Log Files. Las rutinas para respaldar DataFiles, restaurar y la recuperación son descritos en capítulos 16 y 17.

OTROS ARCHIVOS DE BASE DE DATOS.

Estos archivos existen externamente a la Base de Datos. Son, para fines prácticos, necesaria-pero no son estrictamente parte de la Base de Datos.

El INSTANCE PARAMETER FILE. Cuando una Instancia Oracle es iniciada, construir las estructuras SGA en memoria y los procesos background iniciará de acuerdo a los ajustes en el Archivo de Parámetros. Este es el único archivo que necesita existir para iniciar una instancia. Hay varios cientos de parámetros, pero solo uno es requerido: El parámetro DB_NAME. Todos los demás tienen valores default. Así el archivo de parámetros puede ser bastante pequeño, pero debe existir.

EL PASSWORD FILE. Los usuarios establecen sesiones presentando un Username y un Password. El servidor Oracle autentifica esto contra definiciones de usuarios almacenadas en el Diccionario de Datos. El Diccionario de Datos es un conjunto de tablas en la Base de Datos. Es por lo tanto inaccesible si la base de datos no está abierta: Hay ocasiones cuando un usuario necesita ser autentificado antes de que el diccionario de datos esté disponible: cuando el necesita para iniciar la Base de Datos, o incluso para crearlo. Un archivo de contraseñas externa es uno de los medios de hacerlo. Contiene un pequeño número (típicamente menos que la mitad de una docena) de nombres de usuarios y Password que existen fuera del diccionario de datos, y que por tanto se puede utilizar para conectarse a una instancia ante el diccionario de datos está disponible. Crear el fichero de contraseñas se describe en el capítulo 4.

ARCHIVE REDO LOG FILES. Cuando un Online Redo Log File está lleno. El proceso ARCn copia fuera de la Base de Datos a un Archive Redo Log File. Una vez hecho esto, el Archive Log ya no forma parte de la Base de Datos. Es, sin embargo, esencial si es siempre necesario para restaurar un respaldo de DataFile, y Oracle proporciona herramientas para administrar los Archive Redo Log Files.

ALERT LOG Y TRACE FILES. El Alert Log es un flujo continuo de mensajes con respecto a ciertas operaciones críticas que afectan la instancia y la Base de Datos. No se registra todo: solo los eventos que son considerados realmente importantes, como el inicio y apagado; cambios en las estructuras físicas de la base de datos; cambios en los parámetros que controlan la instancia. Archivos Trace son generados por procesos background cuando detectan condiciones de error, y a veces para reportar ciertas acciones.

ESCENARIO Y SOLUCION

Usted está asumiendo el control la gerencia de una base de datos, y no hay documentación del almacenaje físico o lógico, o el uso de la memoria. ¿Cómo puede usted resolverse cómo se configura? Debe ejecutar consultas en numerosas vistas que describen la base de datos y su contenido. Existen herramientas gráficas que le ayudarán a-muchos se incluyen con Oracle Enterprise Manager, pero todos estos están haciendo es ejecutar consultas contra puntos de vista, y el formato de los resultados de una forma bonita.

Peor aún, la base de datos está en un sistema operativo y hardware con el que no está familiarizado. ¿Eso significa que no se puede gestionar? No, él doesnt-pero puede que necesite alguna ayuda. En principio, la arquitectura de Oracle es idéntico en todas las plataformas, y cuando se está trabajando desde dentro de una herramienta de Oracle como SQL * Plus o SQL Developer, realmente no importa lo que la plataforma es. Dicho esto, a menos que esté razonablemente competentes a trabajar desde el sistema operativo

del sistema, así, necesitará mucha ayuda de los administradores del sistema. El trabajo en equipo! Una habilidad esencial en soporte de TI.

LAS ESTRUCTURAS LOGICAS DE BASE DE DATOS.

Las estructuras físicas que conforman una Base de Datos son visibles como Archivos de Sistema Operativo a los Administradores de sistemas. Sus usuarios ven las estructuras lógicas tales como tablas. Oracle utiliza el término segmento para describir cualquier estructura que contenga datos. Un típico segmento es una Tabla, que contiene filas de datos, pero hay más de una docena posible de tipos de segmentos en una Base de Datos. De particular interés (para efectos de este examen) son segmentos Tablas, segmentos Índices, segmentos Undo, todos los cuales son investigados en detalle más adelante. Por ahora. Usted no necesita saber más que las tablas contienen filas de información; que los índices son un mecanismo para obtener rápido acceso a cualquier registro en particular, y que los segmentos Undo son estructuras de datos utilizadas para almacenar información que pudiera necesitarse para revertir, o roll back, cualquier transacción que usted no desea hacer permanente.

Así los Administradores de Sistemas ven DataFiles Físicos; programadores ven segmentos Lógicos. Oracle abstrae el almacenamiento Lógico del almacenamiento físico por medio de Tablespace. Un Tablespace es lógicamente una colección de uno o más segmentos, y físicamente una colección de uno o más DataFiles. Dicho en términos de análisis relacional, existe una relación muchos-a-muchos entre Segmentos y DataFiles: una tabla puede ser cortada atraves de muchos DataFiles (una tabla puede estar almacenada en varios DataFiles), un DataFile puede contener bits de muchas tablas. Mediante la inserción de la entidad Tablespace entre los segmentos y los archivos, Oracle resuelve esta relación mucho-a-muchos.

Una serie de segmentos deben ser creados en tiempo de creación de la Base de Datos: estos son los segmentos que conforman el Diccionario de Datos. Estos segmentos son almacenados en dos Tablespaces, llamados SYSTEM y SYSAUX. El Tablespace SYSAUX era nuevo con la versión 10g: en versiones anteriores, la totalidad del Diccionario de Datos entraba en SYSTEM. El proceso de creación de la Base de Datos debe crear al menos estos dos Tablespaces, con al menos un DataFile cada uno, para almacenar el Diccionario de Datos.

EXAMEN.

El Tablespace SYSAUX se debe crear en tiempo de creación de la Base de Datos en Oracle 10g y posteriores. Si usted no los especifica, será creado por defecto.

Un segmento consistirá de un número de Blocks. Los DataFiles son formateados en Block, y estos Blocks son asignados a segmentos como el segmento Grow. Por que administrar espacio en un Block sería un proceso desgastante, los bloques son agrupados en extents (extensiones), los Blocks son agrupados en extents (extensiones). Un Extents (extensión) es una serie de Blocks que son numerados consecutivamente dentro de un DataFile, y los segmentos crecerán agregando nuevos extents a ellos. Estos Extents (extensiones) no necesitan ser adyacentes entre sí, o incluso en el mismo DataFile; pueden venir de cualquier DataFile que es parte del Tablespace dentro del cual el segmento reside.

La Figura 2-3 muestra la Jerarquía de almacenamiento de Datos de Oracle, con la separación del almacenamiento lógico del físico.

La figura muestra las relaciones entre las estructuras de almacenamiento. Lógicamente, un Tablespace puede contener muchos segmentos, cada uno constituido de muchos extents (extensiones). Un Extents (extensión) es un conjunto de Block Oracle. Físicamente, un DataFile se compone de muchos Block de Sistema Operativo asignados por cualquier sistema de archivos del sistema operativo que utiliza. Las dos partes del modelo están conectadas por las relaciones que demuestran que un Tablespace puede consistir de múltiples DataFiles, y el nivel más bajo que un Block Oracle consistirá de varios Block de sistema operativo.

EL DICCIONARIO DE DATOS

El Diccionario de Datos son los Metadatos: Datos sobre Datos. Este describe la Base de Datos, tanto físicamente y Lógicamente, y su contenido. Definiciones de Usuario, Información de Seguridad, restricciones de Integridad, y (en versiones 10g y posteriores) información de monitoreo de rendimiento son todos parte del Diccionario de Datos. Se almacena como un conjunto de Segmentos en el Tablespace SYSTEM y SYSAUX.

De muchas maneras, los segmentos que conforman el Diccionario de Datos son Segmentos como cualquier otro: solo Tablas e Índices. La diferencia crítica es que las Tablas del Diccionario de Datos son generadas en tiempo de creación de la Base de Datos, y no permite acceso a ellos directamente. No hay nada que impida a un DBA inquisitiva de investigar el diccionario de datos directamente, pero si usted hace cualquier actualización a este, usted puede causar daños irreparables a su Base de Datos, y ciertamente Oracle Corporation no le apoyará. La creación del Diccionario de Datos es parte del Proceso de creación de la Base de Datos. Este es mantenido posteriormente por comandos del Lenguaje de Definición de Datos. Cuando usted emita el comando CREATE TABLE, usted de hecho esta insertando filas en las Tablas del Diccionario de Datos, como son con comandos tales como CREATE USER o GRANT. Para consultar el Diccionario, Oracle provee un conjunto de Vistas. Las vistas vienen en tres formas: Prefijos DBA_, ALL_ o USER_. La matoria de las vistas vienen en todas las tres formas. Cualquier vista con prefijo USER_ será llenado con filas describiendo objetos que pertenecen al usuario que consulto la vista. Así que no existen dos personas podrán ver el mismo contenido. Si el usuario SCOTT consulta USER_TABLES, se mostrará información acerca de sus tablas, si usted consulta USER_TABLES, se mostrará información acerca de sus tablas. Cualquier vista con Prefijo ALL_ serán llenadas con filas describiendo objetos a los tiene Acceso. Así ALL_TABLES contendrá filas describiendo sus propias tablas, más filas describiendo Tablas que pertenezcan a cualquiera y que le han dado permiso para ver.

EXAMEN.

Cual vista muestra todas las Tablas en la Base de Datos? DBA_TABLES, no ALL_TABLES.

Cualquier vista con prefijo DBA_ tendrá filas para cada objeto en la Base de Datos. Así DBA_TABLES tendrá un registro por cada Tabla en la Base de Datos, no importa quién lo creó. Estas vistas son creadas como parte del proceso de creación de la Base de Datos, junto con un gran número de paquetes PL/SQL que son proveídos por Oracle para ayudar a las Administradores de Bases de Datos en la Administración de la Base de Datos y programadores en el Desarrollo de Aplicaciones. El Código PL/SQL es también almacenado en el Diccionario de Datos.

La relación entre Tablespace y DataFile es mantenida en el ControlFile de la Base de Datos. Esto lista todos los DataFiles, indicando que Tablespace son parte de. Sin el ControlFile, no hay forma de que una instancia pueda localizar los DataFiles y luego identificar aquellos que conforma el Tablespace SYSTEM. Solo cuando el Tablespace SYSTEM ha sido abierto es posible para la instancia acceder al Diccionario de Datos, momento en el cual se hace posible abrir la Base de Datos.

El Código SQL siempre referirá a objetos definidos en el Diccionario de Datos. Para ejecutar un simple Query contra una tabla, El Servidor Oracle debe primero consultar el Diccionario de Datos para buscar si la tabla existe, y las columnas que la componen. Entonces debe encontrar donde, físicamente, esta la tabla. Esto requiere la lectura del Mapa de Extents del Segmento. El mapa de Extents lista todos los extents que conforman la Tabla, con el detalle cuyo el DataFile cada Extents está adentro, en qué bloque del DataFile el Extents comienza, y para cuánto Blocks continúa.

EJERCICIO 2-4

INVESTIGAR LAS EXTRUCTURAS DE ALMACENAMIENTO EN SU BASE DE DATOS.

En este ejercicio usted creara un Segmento Tabla, y luego resuelve donde se encuentra físicamente.

1.Conéctese a la Base de Datos como usuario SYSTEM.

2.Crear una Tabla sin el nombramiento de un Tablespace-esta será creada en su Tablespace por default, con un Extents:

create table tab24 (c1 varchar2(10));

3.Identifique el Tablespace en el que reside la Tabla, el tamaño del Extent, el numero de archivo en el que el Extents está dentro, y en que Block del archivo el Extents inicia.

select tablespace_name, extent_id, bytes, file_id, block_id from dba_extents where owner='SYSTEM' and segment_name='TAB24';

4.Identificar el archive por nombre: sustituir la file_id de la consulta previa cuando se le solicite:

select name from v$datafile where file#=&file_id;

5.Resolver exactamente donde en el archive esta el Extents, en términos de cuantos bytes en el archivo inicia. Esto requiere descubrir el tamaño de bloque del tablespace. Enter the block_id and tablespace_name returned by the query in Step 3 when prompted.

select block_size * &block_id from dba_tablespaces where tablespace_name='&tablespace_name';

The illustration shows that the table exists in one extent that is 64 KB large. This extent is in the file /home/db11g/app/db11g/oradata/orcl/ system01.dbf and begins about 700 MB into the file.

RESUMEN DE CERTIFICACION.

Este capítulo cubre la Instancia Oracle y Arquitectura de Base de Datos. Muchos temas serán tratados más completo en capitulo posteriores. Pero en este punto la arquitectura general de la Instancia (Consiste por estructuras de memoria compartida y procesos) la Base de Datos (consiste de archivos en disco), y sesiones de usuarios (un proceso servidor y un proceso usuario) deben ser claras.

DOS MINUTOS.

Describir la Arquitectura de Instancia-Única

- Un Servidor Oracle es una Instancia conectada a una Base de Datos.

- Una instancia es un bloque de memoria compartida y un conjunto de procesos Background.

- Una Base de Datos es un conjunto de Archivos en Disco.

- Una sesión de usuario es un proceso usuario conectado a un proceso servidor.

Explicar las Estructuras de Memoria.

- La memoria compartida de la Instancia es la System Global Area (La SGA).

- Las sesiones tienes una memoria privada esta es Program Global Area (La PGA).

- La SGA consiste de una serie de subestructuras, algunos de los cuales son Requeridos (El DataBase Buffer Cache, El Log Buffer y la Shared Pool) y algunos de los cuales son opcionales (el Large Pool, el Java Pool y la Streams Pool).

- Las estructuras SGA pueden ser cambiadas de tamaño dinámicamente y gestionada dinámicamente, con la excepción del Log Buffer.

Describir las Estructuras de Procesos.

- Los procesos de sesión de servidor son lanzados en demanda cuando los usuarios se conectan.

- Los procesos Background son lanzado en el inicio de la instancia y persisten hasta que termina la instancia.

- Los procesos servidor leen desde la Base de Datos; Los procesos Background escriben a la Base de Datos.

- Algunos procesos Background siempre estarán presentes (en particular SMON, PMON, DBWn, LGWR, CKPT y MMON); otros se ejecutaran dependiendo que opciones han sido habilitadas.

Resumiendo las Estructuras de almacenamiento.

- Existen tres tipos de archivos requeridos en una Base de Datos: El ControlFile, El Online Redo Log Files y los DataFiles.

- El ControlFile almacena información de integridad y referencias del resto de la Base de Datos.

- El Online Redo Log almacena Change Vector recientes aplicados a las Base de Datos.

- Los DataFiles almacenan los datos.

- Archivos Externos incluyen el Parameter File, el Password File, Archive Redo Logs, y el Log y Trace Files.

- El almacenamiento Lógico de Datos (Segments) se abstrae del almacenamiento físico de datos (DataFiles) mediante los Tablespaces.

- Un Tablespace puede estar conformado de múltiples DataFiles.

- Segments están conformados de múltiples extents, que consisten de múltiples Oracle Blocks, que consisten de múltiples Blocks de sistema operativo.

- Un Segment puede tener extents en varios DataFiles.