2.1 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 DISTRIBUIDO.

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.