1 Bases de Datos e Instancias Estos son dos conceptos fundamentales para entender la arquitectura de Oracle.

En trminos sencillos, una instancia de BD es un conjunto de procesos del servidor Oracle que tiene su propio rea global de memoria y una base de datos asociada a ellos.

1.1 Base de Datos Una Base de Datos Oracle es un conjunto de datos almacenado y accesible segn el formato de tablas relacionales. Una tabla relacional tiene un nombre y unas columnas, su definicin. Los datos estn almacenados en las filas. Las tablas pueden estar relacionadas con otras.

Una Base de Datos Oracle est almacenada fsicamente en ficheros, y la correspondencia entre los ficheros y las tablas es posible gracias a las estructuras internas de la BD, que permiten que diferentes tipos de datos estn almacenados fsicamente separados. Est divisin lgica se hace gracias a los espacios de tablas, tablespaces.

1.1.1 Los Espacios de Tablas, Tablespaces Un espacio de tablas es una divisin lgica de la BD. Cada BD tiene al menos uno (SYSTEM). Un espacio de tablas puede pertenecer slo a una BD. Los espacios de tablas se utilizan para mantener juntos los datos de usuarios o de aplicaciones para facilitar su mantenimiento o mejorar las prestaciones del sistema.

De esta manera, cuando se crea una tabla se debe indicar el espacio de tablas al que se destina. Por defecto se depositan en el espacio de tablas SYSTEM, que se crea por defecto. Este espacio de tablas es el que contiene el diccionario de datos, por lo que conviene reservarlo para el uso del servidor, y asignar las tablas de usuario a otro.

Lo razonable y aconsejable es que cada aplicacin tenga su propio espacio de tablas.

Hay varias razones que justifican este modo de organizacin de las tablas en espacios de tablas:

Un espacio de tablas puede quedarse offline debido a un fallo de disco, permitiendo que el SGBD contine funcionando con el resto.

Los espacios de tablas pueden estar montados sobre dispositivos pticos si son de slo lectura. Permiten distribuir a nivel lgico/fsico los distintos objetos de las aplicaciones. Son una unidad lgica de almacenamiento, pueden usarse para aislar completamente los datos de diferentes aplicaciones. Oracle permite realizar operaciones de backup/recovery a nivel de espacio de tabla mientras la BD sigue funcionando. Cuando se crean se les asigna un espacio en disco que Oracle reserva inmediatamente, se utilice o no. Si este espacin inicial se ha quedado pequeo Oracle puede gestionar el crecimiento dinmico de los ficheros sobre los que se asientan los espacios de tablas. Esto elimina la posibilidad de error en las aplicaciones por fallos de dimensionamiento inicial. Los parmetros de crecimiento del tamao de los espacios de tablas se especifican en la creacin de los mismos.

Se pueden ver los espacios de tablas definidos en nuestra BD con el comando SQL siguiente:

SQL> select * from user_tablespaces; Dentro de cada espacio de tabla se pueden almacenar objetos de distinta naturaleza: tablas, ndices, etc. Pero no se pueden mezclar si ms. Necesitamos una manera de separarlos, y eso son los segmentos.

Se pueden almacenar ms de un segmento por espacio de tabla. Un segmento est contenido en su totalidad en un espacio de tabla. Un segmento est constituido por un conjunto de extensiones, que no son ms que grupos de bloques de disco ORACLE contiguos. Cuando se borra un segmento, el espacio es devuelto al espacio de tabla.

Todos los datos de la BD estn almacenados en segmentos. Y existen 5 tipos de segmentos:

de datos: almacenan las tablas. de ndices: permiten un acceso rpido a los datos dependiendo de la cantidad de los mismos (rboles B). Las consultas que slo referencian a columnas indexadas se resuelven en el ndice. Establecen un control de unicidad (los ndices son automticos cuando se definen claves primarias). Cada ndice ocupa un segmento independiente del segmento de datos y deberan estar en un espacio de tablas distinto al de los datos, para mejorar el rendimiento. de rollback: son objetos internos de la BD que permiten efectuar la restauracin de las transacciones no validadas asegurando la consistencia en lectura. La estructura de los registros de rollback es :

Identificador de la transaccin. Direccin del bloque donde est la tabla. Nmero de fila. Nmero de columna. Valor del dato antiguo (antes de ser modificado). Son tan importantes que una BD no puede arrancar si no puede acceder al menos a un segmento de rollback. Si la BD tiene mltiples espacios de tablas, deben existir al menos dos segmentos de rollback y cada segmento de rollback debe tener al menos dos extensiones, reutilizables de manera cclica. Esto segmentos son un objeto compartido de la BD, aunque se puede asinar un segmento de rollback particular a una transaccin dada.

temporales: son creados por Oracle para un uso temporal cuando debe realizar una ordenacin que no le cabe en memoria, y en las operaciones: create index, order by, group by, distinct, union, intersect, minus. Son eliminados cuando la sentencia finaliza. de bootstrap: Se crea en SYSTEM y contiene definiciones del diccionario para sus tablas, que se cargan al abrir la BD. No requiere ninguna accin por parte del DBA. No cambia de tamao. La tabla que guarda la informacin de los segmentos de usuario es user_segments, y se puede visualizar la informacin sobre los segmentos con la sentencia SQL siguiente:

SQL> select * from user_segments;

1.1.2 Ficheros Cada espacio de tablas se compone de uno o ms ficheros en disco. Un fichero puede pertenecer slo a un espacio de tablas. Los ficheros reciben un tamao fijo en el momento de su creacin, y cuando se necesita ms espacio se deben aadir ms ficheros a espacio de tablas.

Dividir los objetos de la BD entre mltiples espacios de tablas permiten que los objetos sean almacenados fsicamente en discos separados, dependiendo de donde estn los ficheros sobre los que se asientan.

1.2 Instancias

Para permitir el acceso a los datos, Oracle utiliza un conjunto de procesos que son compartidos por todos los usuarios. Adems, existen estructuras de memoria que son utilizadas para almacenar los datos ms recientemente solicitados a la BD.

Una instancia de BD es el conjunto de estructuras de memoria y de procesos que acceden a los ficheros de datos.

Los parmetros que determinan el tamao y composicin de una instancia estn almacenados en un fichero llamado init.ora. Este fichero es leido durante el arranque de la BD y puede ser modificado por el DBA. Cualquier modificacin de este fichero no tiene efecto hasta la siguiente vez que se arranque la BD.

Las estructuras de la BD Oracle pueden ser divididas en tres clases:

aquellas que son internas a la BD, aquellas que son internas a las reas de memoria (incluidas la memoria compartida y procesos), aquellas que son externas a la BD.

1.3 Estructuras Internas de la BD Tablas y Columnas

Los datos son almacenados en la BD utilizando tablas. Cada tabla est compuesta por un nmero determinado de columnas.

Las tablas propiedad del usuario SYS son llamadas tablas del diccionario de datos. Proveen el catlogo del sistema que permite que la BD se gestione a s misma.

Las tablas se pueden relacionar entre ellas a travs de las columnas que las componen. La BD se puede utilizar para asegurar el cumplimiento de esas relaciones a travs de la integridad referencial, que se concreta en las restricciones de tablas.

Restricciones de Tablas

Una tabla puede tener asociadas restricciones que deben cumplir todas las filas. Entre las restricciones que se pueden fijar algunas reciben nombres especiales.: clave primaria, clave ajena.

La clave primaria de una tabla est compuesta por las columnas que hacen a cada fila de la tabla una fila distinta.

La clave ajena se utiliza para especificar las relaciones entre tablas. De modo que un conjunto de columnas declaradas como clave ajena de una tabla deben tener valores tomados de la clave primaria de otra tabla.

Usuarios

Una cuenta de usuario no es una estructura fsica de la BD, pero est relacionada con los objetos de la BD: los usuarios poseen los objetos de la BD. Existen dos usuarios especiales: SYS y SYSTEM. El usuarios SYS posee las tablas del diccionario de datos; que almacenan informacin sobre el resto de las estructuras de la BD. El usuario SYSTEM posee las vistas que permiten acceder a las tablas del diccionario, para el uso del resto de los usuarios de la BD.

Todo objeto creado en la BD se crea por un usuario, en un espacio de tablas y en un fichero de datos determinado. Toda cuenta de la BD puede estr unida a una cuenta del S.O., lo que permite a los usuarios acceder a la cuenta de la BD sin dar la clave de acceso.

Cada usuario puede acceder a los objetos que posea o a aquellos sobre los que tenga derecho de acceso.

Esquemas

El conjunto de objetos de un usuario es conocido como esquema.

ndices

Un ndice es una estructura de la BD utilizada para agilizar el acceso a una fila de una tabla. Cada fila tiene un identificador de fila, ROWID, que determina el fichero, bloque y fila dentro del bloque donde est almacenada la fila.

Cada entrada del ndice consite en un valor clave y una ROWID. Cada una de estas entradas se almacena en un rbol B+.

Los ndices se crean automticamente cuando se define una restriccin UNIQUE o PRIMARY KEY.

Clusters

Las tablas que son accedidas juntas frecuentemente pueden ser almacenadas juntas. Para ello se crea un cluster. De este modo se minimiza el nmero de E/S.

Las columnas que relacionan las tablas de un cluster se llaman clave del cluster.

Vistas

Conceptualmente, una vista puede considerarse como una mscara que se extiende sobre una o ms tablas, de modo que cada columna de la vista se corresponde con una o ms columnas de las tablas subyacentes. Cuando se consulta una vista, esta traspasa la consulta a las tablas sobre las que se asienta. Las vistas no se pueden indexar.

Las vistas no generan almacenamiento de datos, y sus definiciones se almacenan en el diccionario de datos.

Secuencias

Las definiciones de secuencias se almacenan en el diccionario de datos. Son mecanismos para obtener listas de nmeros secuenciales.

Procedimientos y Funciones

Un procedimiento es un bloque de cdigo PL/SQL, que se almacena en el diccionario de datos y que es llamado por las aplicaciones. Se pueden utilizar para implementar seguridad, no dando acceso directamente a determinadas tablas sino es a travs de procedimientos que acceden a esas tablas. Cuando se ejecuta un procedimiento se ejecuta con los privilegios del propietario del procedimiento. La diferencia entre un procedimiento y una funcin es que sta ltima puede devolver valores.

Paquetes, Packages

Se utilizan para agrupar procedimientos y funciones. Los elementos dentro de los paquetes pueden ser pblicos o privados. Los pblicos pueden ser llamados por los usuarios, los privados estn ocultos a los usuarios y son llamados por otros procedimientos.

Disparadores, Triggers

Son procedimientos que son ejecutados cuando se procude un determinado evento en la BD. Se pueden utilizar para mejorar y reforzar la integridad y la seguridad de la BD.

Sinnimos

Para identificar completamente un objeto dentro de una BD se necesita especificar el nombre de la mquina, el nombre del servidor, el nombre del propietario y el nombre del objeto. Para hacer transparente todo esto al usuario se pueden utilizar los sinnimos. stos apuntarn a los objetos y si el objeto cambia de lugar o propietario, slo habr que modificar el sinnimo. Existen sinnimos pblicos y privados. Los pblicos son conocidos por todos los usuarios de una BD. Los privados son locales a un usuario.

Privilegios y Roles

Para que un objeto pueda ser accedido por un usuario debe de tener otorgado ese privilegio. Ejemplos de privilegios son INSERT, SELECT, UPDATE, EXECUTE, etc.

Los roles son grupos de privilegios que pueden ser utilizados para facilitar la gestin de los privilegios. Los privilegios se pueden otorgar a un rol, y los roles pueden ser otorgados a mltiples usuarios.

Segmentos, Extensiones y Bloques

Los segmentos son los equivalentes fsicos de los objetos que almacenan datos. El uso efectivo de los segmentos requiere que el DBA conozca los objetos que utiliza una aplicacin, cmo los datos son introducidos en esos objetos y el modo en que sern recuperados.

Como los segmentos son entidades fsicas, deben estar asignados a espacios de tablas en la BD y estarn localizados en uno de los ficheros de datos del espacio de tablas. Un segmento est constituido por secciones llamadas extensiones, que son conjuntos contiguos de bloques Oracle. Una vez que una extensin existente en un segmento no puede almacenar ms datos, el segmento obtendr del espacio de tabla otra extensin. Este proceso de extensin continuar hasta que no quede ms espacio disponible en los ficheros del espacio de tablas, o hasta que se alcance un nmero mximo de extensines por segmento.

Segmento de Rollback

Para mantener la consistencia en lectura y permitir deshacer las transacciones, Oracle debe tener un mecanismo para reconstruir la imgen previa a una transaccin incompleta. Oracle utiliza los segmentos de rollback para esto.

Los segmentos de rollback pueden crecer tanto como sea necesario para soportar las transacciones.

1.4 Estructuras de Memoria Internas Oracle mantiene dos estructuras principales de memoria: el rea Global de Programa, Program Global Area, PGA; y el rea Global del Sistema, System Global Area o tambin Shared Global Area, SGA.

El PGA es la zona de memoria de cada proceso Oracle. No est compartida y contiene datos e informacin de control de un nico proceso.

El SGA es la zona de memoria en la que la BD Oracle guarda informacin sobre su estado. Esta estructura de memoria est disponible para todos los procesos, por eso se dice que est compartida.

1.4.1 rea Global del Sistema, SGA Sirve para facilitar la transferencia de informacin entre usuarios y tambin almacena la informacin estructural de la BD ms frecuentemente requerida.

La SGA se divide en varias partes:

Buffers de BD, Database Buffer Cache

Es el cach que almacena los bloques de datos leidos de los segmentos de datos de la BD, tales como tablas, ndices y clusters. Los bloques modificados se llamas bloques sucios. El tamao de buffer cach se fija por el parmetro DB_BLOCK_BUFFERS del fichero init.ora. Como el tamao del buffer suele ser pequeo para almacenar todos los bloques de datos leidos, su gestin se hace mediante el algoritmo LRU.

Buffer Redo Log

Los registros Redo describen los cmbios realizados en la BD y son escritos en los ficheros redo log para que puedan ser utilizados en las operaciones de recuperacin hacia adelante, rollforward, durante las recuperaciones de la BD. Pero antes de ser escritos en los ficheros redo log son escritos en un cach de la SGA llamado redo log buffer. El servidor escribe peridicamente los registros redo log en los ficheros redo log.

El tamao del buffer redo log se fija por el parmetro LOG_BUFFER.

rea de SQL Compartido, Shared SQL Pool

En esta zona se encuentran las sentencias SQL que han sido analizadas. El analisis sintctico de las sentencias SQL lleva su tiempo y Oracle mantiene las estructuras asociadas a cada sentencia SQL analizada durante el tiempo que pueda para ver si puede reutilizarlas. Antes de analizar una sentencia SQL, Oracle mira a ver si encuentra otra sentencia exactamente igual en la zona de SQL compartido. Si es as, no la analiza y pasa directamente a ejecutar la que mantinene en memoria. De esta manera se premia la uniformidad en la programacin de las aplicaciones. La igualdad se entiende que es lexicografica, espacios en blanco y variables incluidas. El contenido de la zona de SQL compartido es:

Plan de ejecucin de la sentencia SQL. Texto de la sentencia. Lista de objetos referenciados. Los pasos de procesamiento de cada peticin de anlisis de una sentencia SQL son:

Comprobar si la sentencia se encuentra en el rea compartida. Comprobar si los objetos referenciados son los mismos. Comprobar si el usuario tiene acceso a los objetos referenciados. Si no, la sentencia es nueva, se analiza y los datos de anlisis se almacenan en la zona de SQL compartida.

Tambin se almacena en la zona de SQL compartido el cach del diccionario. La informacin sobre los objetos de la BD se encuentra almacenada en las tablas del diccionario. Cuando esta informacin se necesita, se leen las tablas del diccionario y su informacin se guarda en el cach del diccionario de la SGA.

Este cach tambin se administra mediante el algoritmo LRU. El tamao del cach est gestionado internamente por el servidor, pero es parte del shared pool, cuyo manao viene determinado por el parmetro SHARED_POOL_SIZE.

1.4.2 rea Global de Programa El Program Global Area es un rea de memoria utilizada por un proceso Oracle. Esta zona de memoria no se puede compartir.

1.5 Estructuras de Proceso El servidor se vale de una serie de procesos que son el enlace entre las estructuras fsicas y de memoria. A continuacin se describen cada proceso y el papel que juega en la gestin de laBD. Todo esto se puede ver en la siguiente figura.

Arquitectura Oracle

System Monitor, SMON

El SMON es el supervisor del sistema y se encarga de todas las recuperaciones que sean necesarias durante el arranque. Esto puede ser necesario si la BD se par inesperadamente por fallo fsico, lgico u otras causas. Este proceso realiza la recuperacin de la instancia de BD a partir de los ficheros redo log. Adems lmpia los segmentos temporales no utilizados y compacta los huecos libres contiguos en los ficheros de datos. Este proceso se despierta regularmente para comprobar si debe intervenir.

Process Monitor, PMON

Este proceso restaura las transacciones no validadas de los procesos de usuario que abortan, liberando los bloqueos y los recursos de la SGA. Asume la identidad del usuario que ha fallado, liberando todos los recursos de la BD que estuviera utilizando, y anula la transaccin cancelada. Este proceso se despierta regularmente para comprobar si su intervencin es necesaria.

Database Writer, DBWR

El proceso DBWR es el responsable de gestionar el contenido de los buffers de datos y del cach del diccionario. l lee los bloques de los ficheros de datos y los almacena en la SGA. Luego escribe en los ficheros de datos los bloques cuyo contenido ha variado. La escritura de los bloques a disco es diferida buscando mejorar la eficiencia de la E/S.

Es el nico proceso que puede escribir en la BD. Esto asegura la integridad. Se encarga de escribir los bloques de datos modificados por las transacciones, tomando la informacin del buffer de la BD cuando se valida una transaccin. Cada validacin no se lleva a la BD fsica de manera inmediata sino que los bloques de la BD modificados se vuelcan a los ficheros de datos periodicamente o cuando sucede algn checkpoint o punto de sincronizain: grabacin diferida:

Los bloques del buffer de la BD (bloques del segmento de rollback y bloques de datos) menos recientemente utilizados son volcados en el disco continuamente para dejar sitio a los nuevos bloques. El bloque del segmento de rollback se escribe SIEMPRE antes que el correspondiente bloque de datos. Mltiples transacciones pueden solapar los cambios en un slo bloque antes de escribirlo en el disco. Mientras, para que se mantenga la integridad y coherencia de la BD, todas las operaciones se guardan en los ficheros de redo log. El proceso de escritura es asncrono y puede realizar grabaciones multibloque para aumentar la velocidad.

Log Writer, LGWR

El proceso LGWR es el encargado de escribir los registros redo log en los ficheros redo log. Los registros redo log siempre contienen el estado ms reciente de la BD, ya que puede que el

DBWR deba esperar para escribir los bloques modificados desde el buffer de datos a los ficheros de datos.

Conviene tener en cuenta que el LGWR es el nico proceso que escribe en los ficheros de redo log y el nico que lee directamente los buffers de redo log durante el funcionamiento normal de la BD.

Coloca la informacin de los redo log buffers en los ficheros de redo log. Los redo log buffers almacenan una copia de las transacciones que se llevan a cabo en la BD. Esto se produce:

a cada validacin de transaccin, y antes de que se comunique al proceso que todo ha ido bien, cuando se llena el grupo de buffers de redo log cuando el DBWR escribe buffers de datos modificados en disco. As, aunque los ficheros de DB no se actualicen en ese instante con los buffers de BD, la operacin queda guardada y se puede reproducir. Oracle no tiene que consumir sus recursos escribiendo el resultado de las modificaciones de los datos en los archivos de datos de manera inmediata. Esto se hace porque los registros de redo log casi siempre tendrn un tamao menor que los bloques afectados por las modificaciones de una transaccin, y por lo tanto el tiempo que emplea en guardarlos es menor que el que empleara en almacenar los bloques sucios resultado de una transaccin; que ya sern trasladados a los ficheros por el DBWR. El LGWR es un proceso nico, para asegurar la integridad. Es asncrono. Adems permite las grabaciones multibloque.

Checkpoint, CKPT

Este proceso escribe en los ficheros de control los checkpoints. Estos puntos de sincronizacin son referencias al estado coherente de todos los ficheros de la BD en un instante determinado, en un punto de sincronizacin. Esto significa que los bloques sucios de la BD se vuelcan a los ficheros de BD, asegurndose de que todos los bloques de datos modificados desde el ltimo checkpoint se escriben realmente en los ficheros de datos y no slo en los ficheros redo log; y que los ficheros de redo log tambin almacenan los registros de redo log hasta este instante. La secuencia de puntos de control se almacena en los ficheros de datos, redo log y control. Los checkpoints se produce cuando:

un espacio de tabla se pone inactivo, offline, se llena el fichero de redo log activo, se para la BD,

el nmero de bloques escritos en el redo log desde el ltimo checkpoint alcanza el lmite definido en el parmetro LOG_CHECKPOINT_INTERVAL, cuando transcurra el nmero de segundos indicado por el parmetro LOG_CHECKPOINT_TIMEOUT desde el ltimo checkpoint. Est activo si el parmetro CHECKPOINT_PROCESS tiene un valor verdadero.

Archiver, ARCH

El proceso archivador tiene que ver con los ficheros redo log. Por defecto, estos ficheros se reutilizan de manera cclica de modo que se van perdiendo los registros redo log que tienen una cierta antiguedad. Cuando la BD se ejecuta en modo ARCHIVELOG, antes de reutilizar un fichero redo log realiza una copia del mismo. De esta manera se mantiene una copia de todos los registros redo log por si fueran necesarios para una recuperacin. Este es el trabajo del proceso archivador.

Recoverer, RECO El proceso de recuperacin est asociado al servidor distribuido. En un servidor distribuido los datos se encuentran repartidos en varias localizaciones fsicas, y estas se han de mantener sincronizadas. Cuando una transaccin distribuida se lleva a cabo puede que problemas en la red de comunicacin haga que una de las localizaciones no aplique las modificaciones debidas. Esta transaccin dudosa debe ser resuelta de algn modo, y esa es la tarea del proceso recuperador. Est activo si el parmetro DISTRIBUTED_TRANSACTIONS tiene un valor distinto de 0.

Lock, LCK El proceso de bloqueo est asociado al servidor en paralelo.

1.6 Estructuras Externas Por estructuras externas se entienden los ficheros que utiliza el servidor de BD, de los cuales ya se han ido contanto algunos aspectos, y otros se han ido intuyendo. Estos ficheros guardan informacin tanto de los datos almacenados en la BD como la necesaria para gobernar la propia BD.

Ficheros de la BD

En estos ficheros reside la informacin de la BD. Solo son modificados por el DBWR. A ellos se vuelcan los bloques sucios de la SGA cuando se hace una validacin o cuando sucede un checkpoint. Las validaciones de las transacciones no producen un volcado inmediato, sino lo que se conoce por un commit diferido. Toda actualizacin se guarda en los ficheros de redo log, y se lleva a la BD fsica cuando tenemos una buena cantidad de bloques que justifiquen una operacin de E/S. Almacenan los segmentos (datos, ndices, rollback) de la BD. Estn divididos en bloques (Bloque Oracle = c * Bloque SO), cada uno de los cuales se corresponde con un buffer del buffer cache de la SGA. En el bloque de cabecera no se guardan datos de usuario, sino la marca de tiempo del ltimo checkpoint realizado sobre el fichero.

Ficheros redo log

En ellos se graba toda operacin que se efectue en la BD y sirven de salvaguarda de la misma. Tiene que haber por lo menos 2, uno de ellos debe estar activo, online, y se escribe en ellos de forma cclica. Existe la posibilidad de almacenar los distintos ficheros de redo log en el tiempo mediante el modo ARCHIVER. As, se puede guardar toda la evolucin de la BD desde un punto dado del tiempo.

Una opcin es la utilizacin de archivos redo log multiplexados:

Permite al LGWR escribir simultaneamente la misma informacin en mltiples archivos redo log. Se utiliza para protegerse contra fallos en el disco. Da una alta disponibilidad a los archivos redo log activos u online. Esto se hace definiendo el nmero de grupos y de miembros de archivos redo log que van a funcionar en paralelo:

grupos: funcionan como ficheros redo log normales, uno de ellos est activo y el resto espera su turno. Su nombre lleva incorporado una numeracin. Deben contener todos el mismo nmero de miembros. miembros: cada escritura de un registro redo log se lleva a cabo en todos los miembros del grupo activo en ese momento. Los miembros deben: tener el mismo tamao y el mismo nmero de secuencia. deben tener nombres similares y estar en diferentes discos para proteger contra fallos de una manera efectiva. Cuando se produce algn fallo en los ficheros de redo log o en el proceso LGWR:

Si la escritura en un fichero redo log falla pero el LGWR puede escribir al menos en uno de los miembros del grupo, lo hace , ignorando el fichero inaccesible y registrando un fallo en un fichero de traza o alerta. Si el siguiente grupo no ha sido archivado (modo ARCHIVELOG) antes del cambio de grupo que lo pone activo, ORACLE espera hasta que se produzca el archivado. Si fallan todos los miembros de un grupo mientras el LGWR trata de escribir, la instancia se para y necesita recupecin al arrancar. Se pueden visualizar los nombres y estado de los ficheros de redo log:

SVRMGR> select group#, status, substr(member,1,60) from v$logfile; Tambin se pueden visualizar estadsticas de los ficheros redo log:

SVRMGR> select group#, sequence#, bytes, members, archived, 2 status, first_change#, first_time from v$logfile; Ficheros de control

Mantienen la informacin fsica de todos los ficheros que forman la BD, camino incluido; as como el estado actual de la BD. Son utilizados para mantener la consistencia interna y guiar las operaciones de recuperacin. Son imprescindibles para que la BD se pueda arrancar. Contienen: Infomacin de arranque y parada de la BD. Nombres de los archivos de la BD y redo log. Informacin sobre los checkpoints. Fecha de creacin y nombre de la BD. Estado online y offline de los archivos. Debe haber mltiples copias en distintos discos, mnimo dos, para progerlos de los fallos de disco. La lista de los ficheros de control se encuentra en el parmetro CONTROL_FILES, que debe modificarse con la BD parada.

Se puede componer una sentencia SQL que nos muestre todos los ficheros asociados a una BD. Esta es:

SQL> select 'control' tipo, substr(name,1,70) nombre from v$controlfile 2 union all 3 select 'datos' tipo, substr(name,1,70) nombre from v$datafile 4 union all 5 select 'redo log' tipo, substr(name,1,70) nombre from v$logfile 6 / Hasta aqu los tipos de ficheros que se suelen considerar fundamentales en la arquitectura del SGBD Oracle. Pero existen otros ficheros, que aunque no forman parte de la arquitectura Oracle resultan importantes en el uso del SGBD.

El Fichero INIT.ORA

Como parte de la distribucin software, Oracle provee de un fichero de parmetros de inicializacin llamado init.ora. Este fichero contiene los parmetros del sistema Oracle y debe ser utilizado por el DBA para configurar el SGDB y adecuarlo a una determinada explotacin. Oracle lee este fichero durante el proceso de arranque para determinar el tamao de la SGA y encontrar los ficheros de control, entre otros menesteres.

Como el fichero init.ora es fundamental para el arranque de la BD, debera ser copiado frecuentemente para protegerlo de posibles prdidas.

Ficheros de Traza

Orace crea ficheros de texto llamados de traza para ayudar en la diagnosis de problemas y en el ajuste del SGBD. Cada proceso del servidor escribe en un fichero de traza asociado cuando es necesario. Los procesos de usuarios tambin pueden tener asociados ficheros de traza. La situacin de estos ficheros de traza del sistema se especifica por el parmetro BACKGROUND_DUMP_DEST, y los de usuario por USER_DUMP_DEST. Oracle crea ficheros de traza automticamente cuando ocurre algn error.

Un parmetro muy frecuentemente utilizado por los desarrolladores Oracle es el SQL_TRACE, que cuando est puesto a TRUE produce que toda sentencia SQL ejecutada genere informacin en los ficheros de traza. Este parmetro se puede variar con el siguiente comando:

SQL> alter session set SQL_TRACE=TRUE; Session Altered. El directorio donde se depositan los ficheros de traza debe de examinarse con regularidad para controlar el tamao de los fichero alli depositados.

2 Ciclo de Ejecucin Para ilustrar el funcionamiento del servidor Oracle vamos a ver el ciclo de ejecucin de una sentencia de lectura y otra de actualizacin.

2.1 Ciclo de Lectura Las sentencias de lectura siguen el siguiente ciclo:

El proceso cliente pasa la sentencia SQL (SELECT) al proceso servidor por medio de la SGA. Los procesos del servidor buscan en la zona de SQL compartido una versin ejecutable de la sentencia. Si la encuentran no tienen que procesarla. Se procesa la sentencia SQL y su versin ejecutable se coloca en la zona de SQL compartido. El proceso del servidor intenta leer los bloques de datos de la SGA. Si no estn, se han de leer del fichero de datos. Si los bloques estn en la SGA pero han sido modificados por otro usuario y esa modificacin no ha sido validada an, el proceso de servidor debe reconstruir la imagen de la fila a partir de los segmentos de rollback, para conseguir consistencia en lectura. El proceso servidor pasa los datos solicitados al proceso cliente.

2.2 Ciclo de Actualizacin Las sentencias de actualizacin siguen el siguiente ciclo:

El proceso cliente pasa la sentencia SQL (UPDATE) al proceso servidor por medio de la SGA. Los procesos del servidor buscan en la zona de SQL compartido una versin ejecutable de la sentencia. Si la encuentran no tienen que procesarla. Se procesa la sentencia SQL y su versin ejecutable se coloca en la zona de SQL compartido. El proceso del servidor intenta leer los bloques de datos de la SGA. Si no estn, se han de leer del fichero de datos.

Se registra el valor antiguo de los datos en un segmento de rollback y se crea un registro redo log. Se crea una copia de la transaccin en un registro redo log. Se ejecuta la sentencia SQL modificando los datos, y se crea un registro redo log que as lo refleja. El proceso usuario valida la transaccin (COMMIT), registrandose en un registro redo log. El LGWR escribe los buffers del redo log en el disco. El servidor indica al cliente que la operacin ha sido completada de manera satisfactoria. Se registra la terminacin de la transaccin en un registro redo log. Se libera la informacin del rollback, pues ya no va a necesitarse. Si a partir del paso 6 el usuario cancela la transaccin (ROLLBACK), se puede utilizar la informacin de rollback para restablecer el valor original.

Si sucede algo que impida que la transaccin validada por el usuario pueda llevarse a cabo, se puede utilizar la informacin contenida en los registros redo log para rehacer la transaccin (a partir del paso 6).

Como ocurre con todas las transacciones, en algn momento el DBWR escribe en el archivo de datos la copia de los bloques de datos modificados que se encuentran en el buffer cache.

3 Configuracin

3.1 El Cdigo Oracle Cuando el software Oracle se instala en un sistema, se crean subdirectorios y ficheros, dependientes todos ellos del S.O. Por ejemplo, en el S.O. Unix, todo los subdirectorios Oracle se encuentran colgando del directorio principal ORACLE_HOME. Todos estos subdirectorios contienen ficheros ejecutables y scripts que son cruciales para el funcionamiento y la administracin del SGBD, y es lo que se conoce por el cdigo Oracle. Entre ellos, una herramienta nos va a ser fundamental en las tareas de adminstracin y puesta en marcha de la BD: server manager, svrmgr. Con ella son convertiremos en DBA, y para ejecutarla deberemos ser sus propietarios. La sentencia es la siguiente:

SVRMGR> connect internal Connected.

Todas las operaciones de administracin deben comenzar por conectarse a la BD.

3.2 Arranque y Parada de la BD Durante el arranque y parada de la BD se sucenden un conjunto de eventos que llevan a la BD por diferentes estados.

Para que los usuarios puedan acceder a la BD el DBA necesita abrir la BD. El siguiente es un ejemplo de apertura de una BD llamada test.

SVRMGR> startup open test ORACLE instance started. Total System Global Area 4512688 bytes. Fixed Size Variable Size Database Buffers Redo Bufers Database mounted. Database opened. cuando se ejecuta el comando startup open la BD pasa por tres estados (nomount, mount y open) antes de estar disponible. El DBA puede arrancar la BD hasta uno de los estados con el comando startup: startup nomount, startup mount. A continuacin vamos a describir cada uno de los estados por los que pasa la BD en el proceso de arranque. 39732 bytes. 4055164 bytes. 409600 bytes. 8192 bytes.

nomount

SVRMGR> startup open test ORACLE instance started. Total System Global Area 4512688 bytes. Fixed Size Variable Size 39732 bytes. 4055164 bytes.

Database Buffers Redo Bufers

409600 bytes. 8192 bytes.

Oracle lee el fichero init.ora, localiza los ficheros de control, crea e inicializa la SGA, y finalmente arranca todos los procesos Oracle. En este estado la instancia de BD est arrancada. Se deber llevar la BD al estado nomount cuando se est creando la BD o cuando se est restaurando un fichero de control despus de haberlo perdido. mount

SVRMGR> alter database mount; Statement processed. Oracle abre los ficheros de control para localizar los ficheros de datos y los redo log, pero no se realizan ninguna comprobacin en ellos en este momento. La instancia monta la BD y la bloquea, verificando que ninguna otra instancia ha montado la misma BD.

Hay varias razones para querer tener la BD en el estado mount. En general, todas las sentencias SQL del tipo alter database se deben ejecutar en esta etapa. Algunas de las operaciones a realizar cuando la BD est montada son:

efectuar recuperaciones, poner online/offline un fichero de datos, recolocar los ficheros de datos y redo log, crear un nuevo grupo o miembro redo log, o borrar un grupo o miembro redo log existente. open

SVRMGR> alter database open; Statement processed. Durante esta etapa, la instancia abre la BD, bloquea los ficheros de datos, y abre todos los ficheros redo log. Si la instancia abre la BD despus de una terminacin anormal, o despus de una caida, se ejecutar automticamente el proceso de recuperacin utilizando los ficheros redo log. Al final de esta etapa la BD est dispuesta para su uso normal. Para parar la BD el comando base es shutdown como se puede ver en el siguiente ejemplo:

SVRMGR> shutdown Database closed. Database dismounted. ORACLE instance shut down. Pero este comando se nos presenta con tres opciones: normal, immediate y abort. shutdown normal

Se impide el acceso a la BD, espera a que todos los usuarios completen todas sus peticiones y se desconecten del servidor. Purga todos los buffers de datos y cachs de redo log, actualizando los ficheros de datos y de redo log, se eliminan los bloqueos de ficheros, se completan las transacciones en marcha, se actualizan las cabeceras de ficheros, elimina los threads, libera los bloqueos de la BD por parte de la instancia, y sincroniza los ficheros de control y de datos. En resumen, la opcin normal cierran la BD, desmonta la BD y para la instancia con cuidado y es la opcin recomendada para parar la BD. shutdown immediate

En ciertas ocasiones puede ser necesario parar la BD de modo inmediato. Si es as, las sentencias en proceso son terminadas inmediatamente, cualquier transaccin no confirmada (uncommitted) es vuelta atrs (rolled back) y la BD es parada. La nica desventaja de utilizar esta opcin es que Oracle no espera a que los usuarios se desconecten. Sin embargo, la BD ser consistenta y no se necesitar recuperacin en el siguiente arranque. shutdown abort

En situaciones de emergencia, y cuando todo lo dems falla, se debe realizar una parada de este tipo. Por ejemplo, cuando un proceso de la instancia muere y la BD no puede pararse de modo normal o inmediato. Cuando se utiliza la opcin abort las sentencias SQL son terminadas bruscamente, y las transacciones no confirmadas no son vueltas atrs. Parar la BD con la opcin abort requiere recuperacin en la siguiente vez que arranque la BD y esta opcin debe ser utilizada slo cuando no quede ms remedio.

3.3 Almacenamiento de Datos Los datos se almacenan en estacios de tablas, y un espacio de tabla es la entidad lgica que se corresponde con uno o ms ficheros fsicos. La principal razn de esta organizacin es el aumento de la flexibilidad a la hora de realizar operaciones con la BD. En esta seccin vamos a dar un repaso a las tareas de administracin relacionadas con los espacios de tablas y con los ficheros.

3.3.1 Espacios de Tablas y Ficheros Los espacios de tablas se utilizan para realizar tareas de gestin de espacio, controlar la disponibilidad de los datos y ejecutar copias de seguridad y recuperaciones parciales.

Gestin de Espacio

El primer espacio de tablas es el SYSTEM. Este espacio de tablas debe estar disponible siempre durante el funcionamiento normal de la BD porque contiene el diccionario de datos. Despus de la creacin de la BD, se recomienda la creacin de otros espacios de tablas para que los datos de los usuarios puedan ser separados de los del diccionario de datos. Incluso, si varias apliaciones se van a ejecutar sobre la misma BD es recomendable que sus datos estn separados. Para crear un espacio de tablas se puede utilizar el comando create tablespace:

SVRMGR> create tablespace nombre_tablespace 2> datafile 'nombre_fichero' size 50M online; En el ejemplo anterior se ha creado un espacio de tablas de 50 Mb. de tamao. Cada espacio de tabla tiene un conjunto de parmetros de almacenamiento que controla su crecimiento:

initial: tamao de la extensin inicial (10k). next: tamao de la siguiente extensin a asignar (10k). minextents: nmero de extensiones asignadas en el momento de la creacin del espacio de tablas (1). maxextents: nmero mximo de extensiones. pctincrease: Porcentaje en el que crecer la siguiente extensin antes de que se asigne, en relacin con la ltima extensin utilizada. optimal: Tamao ptimo declarado para este espacio de tablas. pctused: porcentaje de utilizacin del bloque por debajo del cual Oracle considera que un bloque puede ser utilizado para insertar filas nuevas en l. Si el espacio de tablas necesita ms espacio despus de su creacin se puede puede alterar para aadir uno o ms ficheros. Para ello se puede utilizar el comando alter tablespace:

SVRMGR> alter tablespace nombre_tablespace 2> add datafile 'nombre_fichero' size 30M;

Si se necesitara variar la localizacin de los ficheros asociados a un espacio de tablas se puede hacer con los comandos alter tablespace (el espacio de tables debe estar offline) o alter database (la BD debe estar montada pero no abierta). Antes de ejecutar los anteriores comandos los ficheros asociados al espacio de tablas deben de haber sido movidos a su nueva localizacin utilizando los comandos del SO oportunos.

Poniendo los tablespaces offline

Llevar a un espacio de tablas al estado offline significa que se impide el acceso a los datos que almacena. El espacio de tablas SYSTEM nunca puede estar offline. Las razones para poner un espacio de tablas offline pueden ser varias: un error de escritura en los ficheros que lo soportan, el mover los ficheros de sitio, etc. Depus de realizar estas operaciones hay que poner otra vez disponible el espacio de tablas, esto es on line

Los espacios de tablas se pueden poner offline de tres modos: normal, temporary e immediate. Si no existe ningn error lo recomendable es poner el espacio de tablas offline usando el modo normal. As, se colocar un checkpoint en el espacio de tablas antes de ponerlo offline.

SVRMGR> alter tablespace nombre_tablespace offline normal; Si alguno de los ficheros est corrupto, la opcin normal fallar y se necesitar el modo temporary. La opcin immediate se utilizar slo cuando la BD est en modo ARCHIVELOG, ya que no se produce checkpoint alguno.

Poniendo los ficheros offline

No es normal poner los ficheros offline/online. Si un determinado fichero de datos se corrompe, se tendr que pone offline, repararlo y ponerlo online de nuevo. Esta operacin puede suponer sustituirlo por su copia de seguridad, lo que implicar ejecutar el comando recover datafile antes de poner el fichero online.

3.3.2 Segmentos, Extensiones y Bloques Los datos en la BD son almacenados fsicamente en bloques Oracle: la mnima unidad de espacio fsico, y es un mltiplo del bloque del SO (2 Kb usualmente). El tamao del bloque Oracle se fija por el parmetro DB_BLOCK_SIZE del fichero init.ora. Un tamao grande de

bloque mejora la eficiencia del cache de E/S, pero el tamao de la SGA aumentar para contener los mismos DB_BLOCK_BUFFERS, lo que significa un problema de memoria.

Una serie de bloques contiguos es una extensin, que es una unidad lgica de almacenamiento. Una serie de extensiones es un segmento. Cuando un objeto es creado, se reserva una extensin en su segmento. Cuando el objeto crezca, necesitar ms espacio y se reservarn ms extensiones.

Cada segmento tiene un conjunto de parmetros de almacenamiento que controla su crecimiento:

initial: tamao de la extensin inicial (10k). next: tamao de la siguiente extensin a asignar (10k). minextents: nmero de extensiones asignadas en el momento de la creacin del segmento (1). maxextents: nmero mximo de extensiones (99). pctincrease: Porcentaje en el que crecer la siguiente extensin antes de que se asigne, en relacin con la ltima extensin utilizada (50). pctfree: porcentaje de espacio libre para actualizaciones de filas que se reserva dentro de cada bloque asignado al segmento (10). pctused: porcentaje de utilizacin del bloque por debajo del cual Oracle considera que un bloque puede ser utilizado para insertar filas nuevas en l. tablespace: nombre del espacio de tablas donde se crear el segmento. Cuando se disea una BD se ha de tener mucho cuidado a la hora de dimensionar la BD y prever el crecimiento de las tablas. A continuacin se hacen algunas consideraciones sobre la gestin del espacio para los diferentes segmentos.

Segmentos de Datos

El espacio del diccionario de datos se suele mantener ms o menos constante, aunque es crtico que tenga suficiente espacio para crecer en el espacio de tablas SYSTEM. As, hay que tener cuidado de colocar las tablas de usuario, los ndices, segmentos temporales y los segmentos de rollback en otros espacios de tablas. Adems, es recomendable que el espacio de tablas SYSTEM est al 50% o 75% de su espacio disponible. Finalmente, asegurarse que los usuarios no tienen privilegios de escritura en el espacio de tablas SYSTEM.

Las tablas crecen proporcionalmente con el nmero de filas, ya que se puede suponer que la longitud de las filas es constante.

Segmentos de ndice

Los ndices crecen en tamao en mayor proporcin que las tablas asociadas si los datos en la tabla son modificados frecuentemente. La gestin del espacio es mejor si se mantienen los ndices de tablas grandes en espacios de tablas separados.

Segmentos de Rollback

Los segmentos de rollback almacenan la imagen anterior a una modificacin de un bloque. La informacin en el segmento de rollback se utiliza para asegurar la consistencia en lectura, el rollback (el valor en el segmento de rollback se copia en el bloque de datos) y la recuperacin.

Es importante comprender cual es el contenido de un segmento de rollback. No almacenan el bloque de datos modificado entero, slo la imagen previa de la fila o filas modificadas. La informacin del segmento de roolback consiste en varias entradas llamadas undo. Por ejemplo, si se inserta una fila en una tabla, el undo necesitar slo el rowid de la fila insertada, ya que para volver atrs la insercion slo hay que realizar un delete. En las operacin de actualizacin, se almacenar el valor antiguo de las columnas modificadas. El segmento de rollback asegura que la informacin undo se guardan durante la vida de la transaccin.

Un segmento de rollback como cualquier otro segmento consiste en una serie de extensiones. Sin embargo, la mayor diferencia entre un segmento de datos y otro rollback es que en este ltimo las extensiones se utilizan de manera circular. As, habr que tener cuidado a la hora de fijar el tamao del segmento de rollback para que la cabeza no pille a la cola.

Segmentos Temporales

Los segmentos temporales se crean cuando se efectuan las siguientes operaciones:

Create Index Select con distinct, order by, union, intersect y minus. uniones no indexadas. Ciertas subconsultas correlacionadas.

Si las tablas a ordenar son pequeas la ordenacin se realiza en memoria principal, pero si la tabla es grande se realiza en disco. El parmetro SORT_AREA_SIZE determina el lugar donde se hace la ordenacin. Incrementndole se reduce la creacin de segmentos temporales.

3.4 Configuracin de la BD Mientras se disea la BD hay que considerar la posible recuperacin de una caida, y las prestaciones de la BD, relacionando todo esto con las necesidades de la implantacin y los medios disponibles. La configuracin de la BD est relacionada con los ficheros de control, los ficheros redo log activos y los archivados.

3.4.1 Gestionando los Ficheros de Control Los ficheros de control contienen el esquema de la BD. Es uno de los ms importantes ficheros e imprescindible para el uso normal de la BD. As que daremos alguna pista para su gestin.

El parmetro CONTROL_FILES del fichero init.ora contiene la lista de todos los ficheros de control. Cuando se arranca la BS, Oracle lee el fichero init.ora para determinar cuntos ficheros de control se usan en la BD y dnde estn. Durante la fase de montaje, se abren los ficheros de control para leer el esquema de la BD. Aunque Oracle escribe en todos los ficheros de control, slo lee el primero listado en el parmetro CONTROL_FILES.

Para protegerlos contra fallos de almacenamiento, se sugiere que al menos existan dos ficheros de control, cada uno en un disco diferente, aunque es buena idea mantener ms copias en diferentes discos. Esto es una poltica de espejado que protege frente a fallos en disco. Si un disco falla y se pierden todos los ficheros en l, se puede seguir utilizando los ficheros de control de otros discos. Esto supone una pequea sobrecarga al sistema, ya que cada vez que se porduce un checkpoint o cambia el esquema de la BD, todos los ficheros de control son actualizados.

Cuando se produce un fallo en algn disco y algn fichero de control se pierde hay que parar la BD con la opcin abort, copiar el fichero de control que queda en otro disco, editar el fichero init.ora para reflejar este cambio, y volver a levantar la BD.

Si un fallo ha producido la prdida de todas las copias de los ficheros de control habr que recrearlos con el comando create controlfile. Si algunos de los parmetros MAXLOGFILES, MAXLOGMEMBERS, MAXLOGHISTORY, MAXDATAFILES y MAXINSTANCES vara habr que utilizar tambin el comando CREATE CONTROLFILE.

3.4.2 Gestionando los Ficheros Redo Log Activos Oracle proporciona la posibilidad de espejar los ficheros redo log activos. Mecanismo conocido como ficheros redo log multiplexados. Oracle necesita al menos dos grupos de fricheros redo log, cada uno con un miembro como mnimo. Oracle efectua escrituras en paralelo a cada miembro, pero si estn en el mismo disco, realmente la escritura se serializa.

Otro aspecto a tener en cuenta es el tamao de los ficheros redo log. Si son muy pequeos, el LGWR deber cambiar de ficheros demasiado frecuentemente, lo que reduce su rendimiento. Por otro lado, si los ficheros redo log son demasiado grandes, se necesitar mucho tiempo en las recuperaciones, ya que se tendrn que recuperar muchas transacciones.

Otro aspecto muy importante es la eleccin del nmero correcto de grupos, ya que disponer de demasiados pocos grupos puede acarrear problemas cuando estmos en modos ARCHIVELOG y tenemos una tasa de transacciones muy alta. Esto puede suponer que un grupo que todava est archivando por el proceso ARCH se convierta en el grupo en el que el LGWR necesite escribir, lo que producira que la BD se parara, ya que el LGWR tienen que esperar a que el grupo est disponible, una vez que su contenido ha sido archivado. Para la mayora de las implantaciones, tener entre 2 y 10 grupos puede ser suficiente. El nmero de grupos no puede exceder de MAXLOGFILES, ni el nmero de miembros puede ser mayor que MAXLOGMEMBERS.

4 Creacin de una BD Ejemplo A continuacin se muestran los scripts de creacin de una BD llamada demo. Este conjunto de scripts es: crdbdemo.sql Script de creacin de la BD llamada demo. Antes de ejecutarlo hay que asegurarse que los path en l referenciados sean consecuentes con la implantacin. Adems la variable ORACLE_SID debe ser puesta a demo configdemo.ora Script con los parmetros de configuracin bsicos. Estos parmetros no suelen cambiar. Este fichero es incluido en initdemo_0.ira y en initdemo.ora. initdemo_0.ora Script con los parmetros de configuracin iniciales. Se utilizar slo en la fase de creacin de la BD. initdemo.ora Script con los parmetros de configuracin.

crdbdemo.sql

REM * REM * script de creacion para bd DEMO REM * fichero: crdbdemo.sql REM * localizacion: /opt/app/oracle/admin/demo REM * ORACLE_HOME: /opt/app/oracle/product/7.3.2 REM *

set termout on set echo on spool crdbdemo.log

REM * REM * creacion inicial de la BD REM * Paso 1: crear la BD, con los ficheros de control REM * especificados en el fichero initdemo.ora REM * ORACLE_SID debe ser igual a demo REM * REM * arrancar la BD demo con el fichero initdemo.ora REM *

connect internal startup pfile=/opt/app/oracle/admin/demo/initdemo.ora nomount

REM * REM * crear la BD demo REM * Guia de configuracion del tablespace SYSTEM: REM * ORACLE RDBMS 5Mb

REM * Espacio adicional del diccionario para aplicaciones 10-50Mb REM * Guia de configuracion de los Redo Log: REM * Utilizar 3+ ficheros redo log para disminuir las esperas. REM * Utilizar 2Mb por redo y por conexion para reducir checkpoints. REM *

create database "demo" maxinstances 1 maxlogfiles 16 character set "WE8DEC" datafile '/export/home/oradata/demo/system01.dbf' size 20M reuse logfile '/export/home/oradata/demo/redodemo01.log' size 2M reuse, '/export/home/oradata/demo/redodemo02.log' size 2M reuse, '/export/home/oradata/demo/redodemo03.log' size 2M reuse;

disconnect

REM * REM * la BD debera estar arrancada en este momento. REM *

connect internal

REM * REM * Paso 2: crear el diccionario REM * el fichero catalog.sql viene con la instalacion del software Oracle. REM *

@/opt/app/oracle/product/7.3.2/rdbms/admin/catalog.sql

REM * REM * Paso 3: crear un segundo segmenteo rollback (r0) en SYSTEM. REM *

connect internal create rollback segment r0 tablespace system storage (initial 16k next 16k minextents 2 maxextents 20);

REM * REM * Paso 4: Alterar el nuevo segmento de rollback para hacerlo disponible REM * Utilizar ALTER ROLLBACK SEGMENT ONLINE para poner r0 online REM * sin tirar la BD y volverla a arrancar. REM *

alter rollback segment r0 online;

REM * REM * crear nuevos tablespaces REM * REM * Paso 5: crear el tablespace RBS para los segmentos de rollback REM * Guia de configuracion de los segmentos rollback: REM * 1 segmento rollback por cada 4 acciones concurrentes. REM * No mas de 50 segmentos rollback. REM * Todos los segmentos rollback del mismo tamano. REM * Entre 2 y 4 extensiones de igual tamano por segmento rollback. REM *

create tablespace rbs datafile

'/export/home/oradata/demo/rbs01.dbf' size 8M reuse, '/export/home/oradata/demo/rbs02.dbf' size 8M reuse, '/export/home/oradata/demo/rbs03.dbf' size 8M reuse, default storage ( initial next pctincrease minextents maxextents ); 128k 128k 0 2 50

REM * REM * Paso 6: crear el tablespace (TEMP) para segmentos temporales. REM * Guia de configuracion del tablespace temporal: REM * Initial y next extensiones = k * SORT_AREA_SIZE, k en {1,2,...}. REM *

create tablespace temp datafile '/export/home/oradata/demo/temp01.dbf' size 1M reuse default storage ( initial next 500k 500k

pctincrease 0 );

REM * REM * Paso 7: crear el tablespace (TOOLS) para las herramientas de bd REM *

create tablespace tools datafile '/export/home/oradata/demo/tools01.dbf' size 15M;

REM * REM * Paso 8: crear el tablespace para los usuarios. REM *

create tablespace users datafile '/export/home/oradata/demo/users01.dbf' size 1M;

REM * REM * Paso 9: crear segmentos rollback REM * crear 2 segmentos rollback en el tablespace RBS REM *

create rollback segment r01 tablespace rbs; create rollback segment r02 tablespace rbs;

REM * REM * Paso 10: desactivar el segundo segmento rollback en el REM * tablespace SYSTEM. REM * Utilizar ALTER ROLLBACK SEGMENT ONLINE para poner los REM * segmentos rollback online sin tirar la BD y volverla a arrancar. REM *

alter rollback segment r01 online; alter rollback segment r02 online;

REM * REM * Como ya hay 2 segmentos rollback creados y online, REM * no necesitamos el segmento rollback en el tablespace SYSTEM. REM *

alter rollback segment r0 offline; drop rollback segment r0;

REM * REM * Modificar los usuarios SYS y SYSTEM. REM * designar tablespace temporal a TEMP REM * designar tablespace por defecto para todos los usuarios TOOLS REM *

alter user sys temporary tablespace temp; alter user system default tablespace tools temporary tablespace temp;

REM * REM * Paso 11: Para cada usuario DBA, ejecutar el script de REM * creacion de sinonimos. No olvidar ejecutarlo para cada REM * usuario DBA creado en el futuro. REM *

connect system/manager @/opt/app/oracle/product/7.3.2/rdbms/admin/catdbsyn.sql

spool off

configdemo.ora

https://www.google.com.pe/url?sa=t&rct=j&q=&esrc=s&source=web&cd=6&cad=rja&ved=0C DUQFjAF&url=http%3A%2F%2Fwww.infor.uva.es%2F~jvegas%2Fcursos%2Fbd%2Forarq%2For arq.html&ei=8SnfUuvxO43gsATt04HQCA&usg=AFQjCNElwM55mV1mqvzm_1Do0uqOGMcNuA &bvm=bv.59568121,d.eW0Instancia Oracle[editar]

Cada vez que se arranca una base de datos se asigna en la memoria un rea Global del Sistema (SGA), que emplean los usuarios para compartir informacin de la base, y algunos procesos background de Oracle son inicializados. Estos procesos, junto con la memoria buffer, constituyen la Instancia Oracle. Los procesos de usuario y los procesos Oracle[editar]

Un proceso de usuario ejecuta el cdigo de un programa de aplicacin o una herramienta Oracle, y se comunica con los procesos del servidor. Los procesos del servidor son creados por Oracle para capturar los requerimientos de los procesos de usuario. Los procesos background realizan las operaciones de I/O y monitorean a los otros procesos; lo realizan asincrnicamente para proveer mayor paralelismo y mejorar la performance. Database Writer (DBWR) Escribe los bloques modificados desde el DB buffer a los datafiles. Log Writer (LGWR) Escribe las entradas del redo log generadas en el redo log buffer al disco. Checkpoint (CKPT) Da una seal al DBWR de los checkpoints y actualiza todos los datafiles y control files para indicar el ms reciente checkpoint. System Monitor (SMON) Realiza la recuperacin de la instancia cuando se realiza el startup. Limpia los segmentos temporales y recupera transacciones muertas durante alguna falla. Agrupa extents libres que tienen PCTINCREASE=1. Process Monitor (PMON) Realiza la recuperacin de los procesos cuando un proceso de usuario falla; limpia el cach y libera recursos que el proceso usaba. Archiver (ARCH) Copia el redo log file online a un almacenamiento de archivo cuando est lleno. Recoverer (RECO) Resuelve transacciones distribuidas que quedaron pendientes durante una falla en una DB distribuida. Dispatcher (Dnnn) Se presentan cuando es usada una configuracin de server multithread. Lock (LCKn) Es usado para el bloqueo inter-instancia en el Oracle Parallel Server.

Estructura lgica de la DB[editar]

Tablespaces[editar] La DB est dividida en una o ms unidades lgicas de almacenamiento llamadas tablespaces, que a su vez pueden estar constituidos por uno o ms archivos del S.O., llamados datafiles. Representan un nivel medio entre la DB y los datafiles. Por su parte, un datafile puede ser asociado con slo una tablespace y una base de datos. Data blocks[editar] Un bloque de datos del Oracle Server es la menor unidad de almacenamiento usada por la base de datos. Extents[editar] Un extent es un conjunto de bloques de datos contiguos. Segments[editar] Un conjunto de uno o ms extents que contiene todos los datos para una estructura especfica en un tablespace. El segmento de datos es una coleccin de extents que mantiene todos los datos para una tabla o cluster. El segmento de ndices mantiene todos los datos para un ndice. El segmento de rollback mantiene datos para rollback, consistencia de lecturas o recuperacin El segmento temporario es una coleccin de extents que mantiene datos pertenecientes a objetos temporales (consultas largas que necesitan guardar resultados intermedios). Schemas Objects[editar] Es la estructura lgica que refiere directamente a los datos de la DB. Consideraciones[editar] Especificaciones a nivel de segmento solapan las del tablespace (no MIN. EXTENT). Un tamao de extensin mnima se aplica a todas las asignadas al tablespace. Por omisin se emplean las especificaciones del tablespace. Cuando no se tienen especificaciones para el tablespace se emplean las del Servidor ORACLE. La modificacin de parmetros de almacenamiento se aplican a extensiones futuras. Existen parmetros que se especifican a nivel de segmento no de tablespace. Estructura fsica de la DB[editar]

Datafiles[editar] Contienen todos los datos de la base de datos, como las tablas e ndices.

Redo Log files[editar] Mantienen registros de todos los cambios hechos a la base de datos, con fines de recuperacin. Control files[editar] Almacenan la estructura fsica y el estado de la base de datos. Bloques de datos, Extensiones y Segmentos[editar]

Estas son las unidades de asignacin de espacio para una Base de Datos. Un Bloque de Datos se corresponde con un nmero especfico de bytes relacionado con el espacio de datos fsico en el disco. Oracle requiere los datos en mltiplos del Bloque de Datos de Oracle. Cuando se crea la Base de Datos Oracle se debe setear la medida del Bloque de Datos (parmetro db_block_size), procurando que sea un mltiplo de la medida del bloque del sistema operativo, dentro de un lmite mximo para evitar I/O innecesarios. La extensin (extent) que es un nmero especfico de Bloques de Datos contiguos asignados para almacenar un tipo especfico de informacin. Un segmento es un conjunto de extensiones que se han asignado a un tipo especfico de estructura de datos. Por ejemplo cada tabla de datos es almacenada en su propio segmento de datos, mientras que cada ndice de datos es almacenado en su propio segmento de ndice. Cuando una extensin existente en un segmento esta llena, Oracle asigna otra extensin para ese segmento.

Debido a que las extensiones son asignadas en la medida que son necesarias, las extensiones de los segmentos pueden o no ser contiguas en el disco. Un segmento y todas sus extensiones son almacenados en un Tablespace, dentro del cual un segmento puede extenderse sobre los archivos de datos (tener extensiones con datos en ms de un archivo). Cada extensin puede contener datos de un archivo solamente. Formato del bloque de datos[editar] El bloque est dividido en el overhead, los datos de fila, y el espacio libre entre ellos dos. El overhead[editar] El overhead est constituido por: Cabecera (Header) contiene informacin general del bloque tales como la direccin del bloque y el tipo de segmento (datos, ndices o rollback). Directorio de tablas (Table Directory) contiene informacin acerca de aquellas tablas que tienen filas en este bloque.

Directorio de filas (Row Directory) contiene informacin sobre las filas actuales en el bloque, incluyendo direcciones para cada pedazo de fila en el rea de datos. Datos de fila[editar] Contiene los datos de tablas o ndices. Espacio libre[editar] Es asignado para insertar filas nuevas y actualizar aquellas que requieren espacio adicional. El espacio libre debe albergar tambin los datos de la transaccin (transaction entry), que se requiere en un bloque por cada INSERT, UPDATE, DELETE y SELECT...FOR UPDATE que acceden a una o ms filas en el bloque. PCTFREE, PCTUSED y Encadenamiento de filas[editar] PCTFREE Y PCTUSED permiten controlar el espacio libre para inserciones y eliminaciones de filas en los bloques de un segmento. Estos parmetros se especifican cuando se crea o altera una tabla o cluster; para el caso de los ndices se puede especificar PCTFREE. PCTFREE Indica el porcentaje mnimo de un bloque de datos que se debe reservar como espacio libre. PCTUSED Indica cuando un bloque puede volver a emplearse para insertar nuevos datos de filas. Un bloque est disponible para insercin mientras tenga libre el porcentaje que indica PCTFREE. Cuando ste es menor, se marcar como no disponible para inserciones, hasta que el porcentaje de uso caiga debajo del parmetro PCTUSED. En dos casos, los datos de una tabla pueden ser demasiado largos para encajar en un bloque de datos: La fila es demasiado larga cuando se inserta por primera vez, en cuyo caso Oracle almacena los datos para la fila en una cadena de bloques de datos (una o ms) reservadas para ese segmento. Una fila que originalmente encaja se actualiza de modo tal que la longitud global se incrementa y el espacio libre del bloque se encuentra lleno; en este caso Oracle mueve la fila entera a un bloque de datos nuevo. Asignacin y liberacin de espacio[editar] Cuando el espacio existente en un segmento es usado completamente, Oracle asigna un nuevo extent para el segmento. Asignacin de extents[editar] Cuando se crea una tabla, Oracle asigna al segmento de datos de la tabla un extent inicial compuesto por un nmero especfico de bloques de datos.

Si los bloques de datos de un extent inicial del segmento se llenan, Oracle automticamente asigna un extent incremental para ese segmento, que es un extent subsecuente del mismo tamao de un tamao mayor que el extent asignado previamente en ese segmento. Para propsitos de mantenimiento el bloque cabecera de cada segmento contiene un directorio de los extents de ese segmento. Algoritmo de asignacin de segmentos[editar] Oracle busca en el espacio libre (del tablespace que contiene los segmentos) hasta el encontrar el primer conjunto de bloques de datos contiguos, libre, de igual o mayor tamao que el extent incremental: Coincidencia exacta: se busca un conjunto que coincidan con el tamao del extent nuevo ms un bloque adicional para reducir la fragmentacin interna. Espacio contiguo mayor: si encuentra un grupo mayor en al menos 5 bloques que el necesitado, divide el grupo de bloques en extents separados uno de los cuales es del tamao que se requiere. Reasignacin de espacio: si Oracle no encuentra un bloque de datos contiguo igual o mayor, reordena los bloques libres de su correspondiente tablespace para formar conjuntos de bloques de datos contiguos mayores. Luego aplica los pasos anteriores. Autoextensin: Si un extent no puede ser asignado despus de una segunda bsqueda, Oracle trata de redimensionar los archivos por autoextensin. Si no puede hacerlo retorna un error. Una vez que Oracle encuentra y asigna el espacio libre necesario en el tablespace, asigna una porcin del espacio libre que corresponde al tamao del extent incremental. Si hay remanente, queda como espacio libre. Oracle actualiza la cabecera del segmento y el diccionario de datos para mostrar que un extent nuevo ha sido asignado y que el espacio asignado no est ms libre. Liberacin de los extents[editar] En general, los extents de un segmento no retornan al tablespace mientras no se eliminan los objetos cuyos datos estn almacenados en el segmento (por medio de un DROP TABLE o DROP CLUSTER). Excepciones a esto: Se puede truncar la tabla o cluster con la sentencia TRUNCATE...DROP STORAGE. Peridicamente, Oracle puede desasignar uno o ms extents de un segmento de rollback si tienen la opcin OPTIMAL especificada. Un DBA puede desasignar extents no utilizados usando la instruccin SQL ALTER TABLE nombre_tabla DEALLOCATE UNUSED. Tablas Nonclustered[editar] En tanto existan las tablas nonclustered o hasta que se las trunca, cualquier bloque de datos asignado a su segmento de datos permanece asignado a la tabla. Despus de eliminarse una tabla nonclustered, este espacio puede ser reclamado cuando otros extents requieran espacio libre.

Tablas Clustered[editar] Almacenan su informacin en los segmento de datos creados para el cluster. Si se elimina una tabla en un cluster, el segmento de datos permanece para las otras tablas en el cluster y ningn extent se desasigna. Indices[editar] Todos los extents asignados en un segmento ndice permanecen asignados en tanto y en cuanto exista el ndice. Segmentos Rollback[editar] Oracle peridicamente chequea para ver si los segmentos de rollback de una base de datos han crecido ms que su tamao ptimo. Si un segmento rollback es mayor que su ptimo, Oracle automticamente desasigna uno o ms extents de su segmento de rollback. Segmentos temporarios[editar] Cuando se completa la ejecucin de una sentencia que requiere un segmento temporario, Oracle automticamente lo elimina. Segmentos[editar] Un segmento es un conjunto de extents que contienen todos los datos para una estructura de almacenamiento lgico especfica. Segmentos de datos[editar] Cada tabla o particin nonclustered y cada cluster en una base de datos Oracle tiene un segmento de datos simple para mantener todos sus datos.

Los parmetros de almacenamiento determinan como sus extents de segmentos de datos son asignados. Estos parmetros afectan la eficiencia de la recuperacin de datos y almacenamiento para el segmento de datos asociado con el objeto. Segmentos de ndices[editar] Sirven para mantener los datos de los ndices. Se pueden especificar los parmetros de almacenamiento para los extents del segmento de ndices y el tablespace en el que se crea el segmento ndice. Segmentos temporarios[editar] Constituyen un rea de trabajo para las actividades de ordenamiento. Si dicha operacin puede ser realizada en memoria este segmento no se crea. Las consultas que pueden requerir de segmentos temporarios son: CREATE INDEX SELECT ... ORDER BY SELECT DISTINCT SELECT ... GROUP BY

SELECT...UNION SELECT...INTERSECT SELECT...MINUS Joins indexados o con subconsultas Segmentos de rollback[editar] Un segmento de rollback registra los valores viejos de los datos que fueron cambiados por cada transaccin (cometida o no). Contenido de los segmentos de rollback[editar] Consiste de varias entradas de rollback, que incluyen informacin del bloque y los datos como existan antes de la operacin en una transaccin.

Slo Oracle puede acceder a los segmentos de Rollback, ni los usuarios ni el DBA pueden acceder a ellos. Las entradas de rollback cambian los bloques de datos en los segmento de rollback y Oracle registra todos los cambios de los bloques de datos, incluyendo las entradas de rollback en los redo log (que son por lo menos dos). Si hay una falla en el sistema, Oracle automticamente recupera la informacin del segmento, incluyendo las entradas de rollback para transacciones interactivas. Una vez que se completa la recuperacin, Oracle realiza los rollback de las transacciones que ni fueron completadas ni vueltas a atrs en el momento de la falla.

Para cada segmento rollback, Oracle mantiene una tabla de transacciones: Una lista de todas las transacciones que usan el segmento de rollback. Las entradas de rollback por cada cambio realizado por estas transacciones. Los segmentos de rollback registran los valores de los datos antes de los cambios para cada transaccin, luego vincula cada nuevo cambio al cambio previo. Si se deben recuperar una transaccin, Oracle aplica los cambios en cadena a los bloques de datos en el orden que restablezcan los datos a sus valores previos. Transacciones y segmentos rollback[editar] Cada vez que una transaccin de usuario comienza, se le asigna un segmento de rollback en una de las siguientes dos maneras: Oracle puede asignar una transaccin automticamente al prximo segmento de rollback disponible. La asignacin de la transaccin ocurre cuando se edita la primera sentencia DML o DDL en la transaccin. Nunca se asignan transacciones de solo lectura a un segmento rollback.

Una aplicacin puede asignar una transaccin a un segmento de rollback especfico. Al comienzo de una transaccin, un desarrollador o usuario de aplicaciones puede especificar un segmento rollback particular que Oracle debera usar cuando se ejecute la transaccin. Cuando una transaccin se completa (commit), Oracle libera la informacin de rollback pero no la destruye inmediatamente. La informacin permanece en el segmento de rollback para crear vistas consistentes de lectura de los datos pertinentes para las queries que comenzaron antes que la transaccin se completara exitosamente. Oracle escribe los extents en los segmentos de rollback secuencialmente. Cuando el ltimo extent del segmento rollback se llena, Oracle contina escribiendo datos de rollback sobreescribiendo el primer extent en el segmento. Una transaccin que se ejecute en un perodo de tiempo largo puede requerir un nuevo extent para asignar un segmento de rollback. Oracle siempre trata de reusar los extents ya asignados a una transaccin. Si el prximo extent contiene datos de transacciones que estn activas todava entonces debe asignar un extent nuevo. Esto se hace hasta que el nmero de extents para un segmento alcanza el parmetro de almacenamiento MAXEXTENTS. PCTINCREASE le indica a Oracle cuanto ha de crecer cada extent luego que fueren usados los extents INITIAL y NEXT. INITRANS, MAXTRANS especifica el nmero de entradas inicial y mximo que las transacciones tendrn en el bloque. Estn relacionados con la concurrencia que se permite en el bloque. http://es.wikibooks.org/wiki/Manual_del_estudiante_de_Ingenier%C3%ADa_en_Sistemas_de _UTN/Bases_de_datos_avanzadas/Arquitectura_de_la_base_de_datos_Oracle La Arquitectura de la Base de Datos Oracle ABR 25 Publicado por GUNN3R El Oracle Server consiste en dos entidades:

La Instancia: Es un conjunto de Procesos y Estructuras de Memoria. La Base de Datos: Es un conjunto de Archivos en Disco. Durante la creacin, se crea primero la instancia y despus la Base de Datos. Es decir, primero se levanta la instancia y posteriormente se abre la Base de Datos.

Las estructuras lgicas (tablas, ndices, etc) no estn directamente conectadas con las estructuras fsicas (archivos).

La instancia consiste en un conjunto de procesos y estructuras de memoria que existen en la RAM y en el CPU. Cuando se apaga la instancia, ambos procesos y estructuras de memoria terminan de ejecutarse al mismo tiempo, mientras la Base de Datos prevalece en disco.

A pesar de que la instancia vive en memoria, puede ser detenida o iniciada. En cambio, la Base de Datos persiste indefinidamente hasta que se borren los archivos del disco.

Los procesos que hacen la instancia son llamados Background Process. Las estructuras de memoria son implementadas en segmentos de memoria compartida provedas por el Sistema Operativo. Esta rea de memoria compartida se conoce como SGA(System Global Area).

A los procesos de servidor tambin se les conoce como Foreground Process. A cada proceso de servidor se le asocia con una PGA (Program Global Area).

Un PGA es una rea de memoria no compartida. Es decir un rea de memoria privada a la cual solo puede accesar el proceso de servidor a la cual esta asociado.

Las sesiones consisten de un proceso de usuario que corre localmente en el ordenador del usuario ligado a un proceso de servidor que corre localmente en el servidor.

Las estructuras fsicas que conforman a una base de datos se llaman:

Data Files Control File Redo Logs La Base de Datos garantiza completa abstraccin entre las estructuras fsicas y las estructuras lgicas. Es decir, no hay manera en que se pueda saber en que bit yace que informacin.

Los datos se guardan en los datafiles, es decir que estos ficheros son como un banco de informacin que no tiene lmite en tamao. La abstraccin se refiere a que los archivos fsicos podran moverse, cambiar de tamao, etc. Y los usuarios no se enteraran.

La relacin entre las estructuras fsicas y lgicas se mantiene y documenta en el Diccionario de Datos, ya que este contiene los metadatos que describen a toda la Base de Datos.

El redo log es un archivo que contiene todos los change vectors. Un change vector es una alteracin hecha por un comando DML.

Cuando una sesin efecta cambios en la informacin, la informacin en los data blocks cambia y el vector change se escribe el el redo log.

Entonces, cuando se daa un datafile, Oracle extraer los vectores relevantes del redo log y los aplicar en los bloques.

Los Control Files guardan informacin acerca de las estructuras de la Base de Datos.

Cuando una instancia abre alguna Base de Datos, primero abre el Control File. En el Control File se encuentra la informacin para que la instancia se pueda conectar a la Base de Datos y al Diccionario de Datos.

Es imposible para cualquier proceso de usuario tener contacto con la Base de Datos, todos los accesos deben ser mediados por los procesos del servidor.

En un ambiente de una sola instancia, una sola instancia abre la Base de Datos, mientras que en un ambiente distribuido existen varias maneras de agrupar las instancias con las Bases de Datos.

Ejemplos de Sistemas Distribuidos:

Real Application Clustering Streaming Data Guard Una instancia consiste en un bloque de memoria compartida conocida como SGA y un conjunto de procesos BackGround.

Existen como mnimo 3 estructuras de memoria en el SGA:

Database Buffer Cache Log Buffer

Shared Pool Las sesiones de usuario tambin necesitan memoria en el servidor. Esta memoria privada se conoce como PGA. Entonces as, cada sesin tendr su propio PGA.

El Database Buffer Cache, se encarga de ejecutar SQL. Cuando se hace una operacin DML, se toman los data blocks que contienen la informacin solicitada y se copian al Database Buffer Cache. Posteriormente, los cambios son aplicados a las copias de los data blocks que se encuentran en el Database Buffer Cache.

Cuando se requiere consultar informacin, los datos tambin son procesados a travs del cache. La sesin obtiene los data blocks que contienen la informacin de inters y los copia al Database Buffer Cache; los registros relevantes son posteriormente transferidos al PGA de la sesin para un procesamiento prximo.

Cabe decir que estos bloques se mantendrn en el buffer por cierto tiempo. Todos los datafiles, estn formateados en data blocks, mientras el Database Buffer cache estar formateado en memory buffers. Cada memory buffer se acoplar al tamao de de un data block.

Un memory buffer que guarda un bloque en cache, cuya informacin es diferente al bloque en disco, se conoce como dirty buffer. Un buffer estar limpio(es decir ser un clean buffer) cuando se le ingrese un bloque por primera vez cuando los datos del buffer se copien a los datafiles.

Un buffer se convertir en dirty buffer cuando el bloque que contiene es actualizado. Los bloques deben ser copiados a los Data Files eventualmente, de esto se encarga el proceso DBWR. Cuando esto ocurre, los buffers vuelven a ser clean buffers nuevamente.

El Log Buffer Cache es un rea para montar los vector changes antes de que se registren en el redo log. Un vector change es cualquier cambio aplicado a la informacin por alguna instruccin DML.

Las sesiones escriben los redos en memoria y posteriormente se transcriben en los redo logs. De esto se encarga un proceso llamado LGWR.

LGWR copia la informacin del buffer al redo log en forma de batches, y conforme se va liberando la informacin del buffer, este puede ser sobrescrito por ms vector changes.

El Shared Pool es la ms compleja de las reas del SGA, ya que se divide en docenas de subestructuras. Algunas de ellas son:

Library Cache Data Dictionary Cache rea PL/SQL Cache para Resultado de Funciones y Queries El Library Cache es utilizado para guardar el cdigo ejecutado recientemente en su forma parseada. Parsing significa transformar todo el cdigo escrito por los programadores a una unidad ejecutable, cosa que Oracle hace bajo demanda. El cdigo parseado en el Shared Pool puede ser reutilizado sin tener que volver a ser convertido a una entidad ejecutable. Esto para poder incrementar el performance de la Base de Datos.

En conclusin, el propsito del Library Cache es el poder guardar el cdigo de los queries en su forma parseada, listo para su ejecucin.

El Data Dictionary Cache guarda las definiciones de objetos usados recientemente: Descripciones de Tablas, ndices, etc. Esto para que cuando las sentencias sean parseadas, sean parseadas de una manera ms rpida sin tener que consultar al Diccionario de Datos.

El rea PL/SQL almacena objetos tales como Procedimientos, Funciones, etc. Cuando un objeto PL/SQL es llamado por una sesin, debe ser llamado desde el Diccionario de Datos. Para prevenir llamadas repetitivas al Diccionario de Datos, los objetos son guardados en el rea PL/SQL.

El Cache de Resultados permite a Oracle guardar los resultados de los queries en memoria, esto para que cuando se ejecute el query de nuevo, solamente regrese su resultado en vez de tener que volverlo a procesar.

Cuando el Oracle Server necesita espacio, sobreescribir los objetos que no han sido utilizados por el mayor tiempo, esto gracias a un algoritmo denominado LRU ( Least Recently Used ).

El Large Pool es un rea que de ser creada, es utilizada por algunos procesos que de no existir el Large Pool tomaran espacio del Shared Pool.

El Java Pool es un rea que es requerida si se van a ejecutar procedimientos java en la Base de Datos. Sin embargo, muchas opciones de Oracle corren bajo java, por lo tanto se podra decir que este pool es considerado un estndar actualmente.

Los background process, son procesos que son lanzados cuando una instancia es iniciada, y se ejecutan hasta que la instancia termine. Existen cinco procesos que han estado por mucho tiempo en la historia de Oracle, estos son:

System Monitor(SMON) Process Monitor(PMON) Database Writer (DBWn) Log Writer(LGWRn) CheckPoint Process (CKPT) SMON Se encarga de montar y abrir la Base de Datos. SMON monta la base de datos al localizar y validar el controlfile de la Base de Datos y posteriormente la abre al localizar y validar todos los datafiles y los online log files de la misma.

Un server process es lanzado cuando una sesin es creada y es destruido cuando la sesin termina. Cuando una sesin termina de una manera anormal, entonces el espacio utilizado por ese proceso de servidor debe limpiarse. PMON monitorea todos los procesos de servidor y detecta anomalas con las sesiones. Si una sesin ha terminado de una manera irregular, PMON eliminar el proceso de servidor asignado a la sesin y regresar a la memoria utilizada por este al PGA. Despus de esto, PMON aplicar un rollback a todas las transacciones incompletas que la sesin haya tenido en progreso.

Las sesiones NO escriben directamente en disco, primero deben escribir en cache y posteriormente los procesos escribirn la informacin a disco.

El proceso DBWn, escribe dirty buffers en los datafiles, pero no los escribe conforme se van ensuciando. El algoritmo DBWn solamente escribe dirty buffers que no han sido utilizados recientemente. Existen cuatro circunstancias bajo las cuales se escriben los dirty buffers a disco:

Que exista un gran nmero Dirty Buffers. Que hayan transcurrido 3 segundos. Que se ejecute un CheckPoint. Que no existen buffers disponibles.

Si un proceso de servidor necesita copiar un bloque al database buffer cache, debe encontrar un free buffer (buffer libre). Un free buffer es un buffer que no es un dirty buffer o pinned buffer ( buffer sujeto a otra sesin).

Un dirty buffer no se debe sobreescribir ya que se perdera la informacin que contiene. Adems de esto, un pinned buffer no puede ser sobreescrito ya que los mecanismos de proteccin de memoria del sistema operativo no lo permitirn.

Cuando un checkpoint ocurre, todos los dirty buffers son escritos al disco. La nica razn por la cual se necesita que se ejecute un Checkpoint es cuando se cierra la Base de Datos y se apaga la instancia. Un Checkpoint copia todos los dirty buffers a disco, esto sincroniza el buffer cache con los datafiles y la instancia con la Base de Datos. Un checkpoint ocurre cuando se cerrar la base de datos y se apagar la instancia, pero tambin puede ser ejecutado de una manera forzada por la instruccin:

SQL> alter system checkpoint

El LGWR escribe los contenidos del log buffer a los online log buffers en disco. Al procedimiento de transferir los log buffers a disco se conoce como flushing.

Es imposible hacer que el cdigo DML se ejecute ms rpido que LGWR cuando escribe los vectores al disco. Existen 3 circunstancias bajo las cuales se ejecutar un LGWR:

Que se ejecute un COMMIT. Que el Log Buffer este a un tercio de lleno. Que el DBWn este a punto de escribir Dirty Buffers. Antes de que el DBWn escriba la informacin en los datafiles, manda una seal al LGWR para que este transfiera toda su informacin almacenada a los redo logs.

En resumen, despus de un crash, todos los vectores refirindose a dirty buffers deben ser extrados del redo log y aplicados a la data blocks, de eso se encarga el CKPT.

MMON se encarga de obtener estadsticas y actividades de rendimiento. A estas estadsticas se les conoce como Snapshots.

MMAN habilita el manejamiento automtico de alocacin de memoria. Es decir MMAN observa la demanda sobre el PGA y el SGA y distribuye la memoria a las sesiones y estructuras del SGA.

Todos los vector changes aplicados a la informacin se escriben en los buffers y posteriormene a los online redo logs.

Los online redo logs tienen un tamao y numero fijo. Una vez que se llenen, LGWR los sobreescribir con ms informacin.

Los Online Redo Log Files deben ser copiados antes de ser sobreescritos, de esto se encarga ARCn. A estas copias se les conoce como Archived Redo Logs.

Oracle Server provee un nivel de abstraccin entre las estructuras fsicas y lgicas, esta abstraccin se lleva a cabo a travs de los tablespaces.

El Controlfile contiene punteros al resto de la Base de Datos:

Ubicacin del Redo Log Ubicacin a los Data Files Ubicacin a otros archivos para mantener la integridad de la B.D. Al proceso de crear copias de archivos se conoce como multiplexar.

Toda base de datos debe tener mnimo un Controlfile, pero todo buen DBA debe crear mltiples copias por s un duplicado se daa o se pierde. Entonces, si se llega a daar o perder una copia, se tendrn otras copias de respaldo. Cabe decir que el nmero mximo de copias del Controlfile es de 8. Cualquier dao en el Controlfile causar que la instancia termine inmediatamente.

El Redo Log guarda cronolgicamente todos los cambios realizados por un vector change a la Base de Datos.

El Redo Log consiste de dos tipos de archivos:

Online Redo Logs

Archive Redo Logs Toda Base de Datos tiene al menos 2 Online Redo Log Groups. Cada Online Redo Log Group consiste de grupos de Online Redo Log Files, a cada Online Redo Log File se le conoce como miembro. La Base de Datos requiere al menos de dos grupos, cada uno con al menos un miembro.

Uno de los grupos se conoce como Current Group: Los cambios son escritos a este grupo por medio de LGWR. Como ya se mencion, los Redo Log Files son de tamao fijo, por lo tanto los archivos que compongan al Current Group eventualmente se llenarn. LGWR despus ejecutar lo que se conoce como Log Switch. Esto har que el segundo grupo se tome el puesto del Current Group, mientras el antiguo Current Group se archiva en el Archive Redo Log, y as sucesivamente.

Ya que los Online Redo Log Groups son usados de una manera circular, cada vez que exista un Log Switch, se generar un archive Redo Log File. El tamao mnimo de los Online Redo Log File Groups es de 50 MB.

Se deben tener como mnimo 2 Data Files. Los Data Files son el repositorio de los segmentos que contienen informacin que visualizan los usuarios y de los segmentos que componen al Diccionario de Datos.

Un segmento es una estructura de almacenamiento de informacin. Internamente los Datafiles estn formateados en Oracle Blocks. Todo bloque contiene una cabecera, un rea de informacin, y posiblemente algo de espacio libre. La cabecera posee informacin como el directorio el cual se utiliza para obtener la ubicacin del rea de informacin, adems de un rea de candado utilizada para bloquear la informacin que se encuentre en una transaccin.

Cuando una sesin necesita trabajar sobre la informacin por cualquier motivo, el proceso de servidor que atiende a la sesin localiza los bloques relevantes en el disco y los copia en los Free Buffers del Database Buffer Cache.

Al contrario del Control File y de los Online Redo Log Files, los Data Files no pueden ser multiplexados. Si un Data File se daa, puede ser restablecido desde algn respaldo, esto se logra aplicando todo el redo generado desde que se ejecut el ltimo backup. Los redos necesarios se extraen desde los change vectors que se encuentran en los Online y Archived Redo Log Files.

Cuando se inicia una instancia, las estructuras SGA se crean en memoria y se lanzan los Background Process de acuerdo a las especificaciones contenidas dentro del Parameter File. Este es el nico archivo que se necesita para poder iniciar una instancia.

Hay ocasiones en las cuales el usuario necesita autenticarse antes de que el Diccionario de Datos este disponible. Por ejemplo cuando necesite iniciar o crear una Base Datos. De esto se encarga un Password File, este archivo contiene un nmero pequeo de nombres de usuarios y contraseas que existen fuera del Diccionario de Datos y que por consiguiente puede ser utilizado para conectarse a una instancia an y cuando el Diccionario de Datos no este disponible.

Cuando un Online Redo Log File se llena, el proceso ARCn copia su informacin a un Archive Redo Log File.

El Alert Log es un fichero el cual almacena todos los mensajes referentes a operaciones criticas que afectan a la Base de Datos y a la Instancia.

Los Trace Files, son archivos que son generados por los Background Processes cuando estos detectan errores.

Las estructuras fsicas que componen la Base de Datos, pueden ser vistas por los Administradores como archivos comunes del Sistema Operativo. Mientras que los usuarios ven estructuras lgicas, como por ejemplo tablas. Oracle utiliza el trmino segmento para referirse a cualquier estructura que contiene informacin.

As que los Administradores ven archivos fsicos, mientras los usuarios ven segmentos lgicos. Un tablespace es fsicamente la coleccin de uno o ms Datafiles. Mientras que lgicamente es la coleccin de uno o ms segmentos.

Hay una relacin muchos a muchos entre los segmentos y los Datafiles. Esta relacin se da gracias que una tabla puede estar definida en uno o ms Datafiles mientras que un Datafile puede contener informacin de una o ms tablas.

Un nmero de segmentos debe ser creado a la hora de crear la Base de Datos. Estos segmentos son los que componen al Diccionario de Datos. Estos segmentos estn almacenados dentro de dos tablespaces llamados SYSTEM y SYSAUX.

Un segmento consiste en uno ms bloques. Los Datafiles estn formateados en bloques, y estos bloques a su vez estn asignados a segmentos. Los bloques se agrupan en extents. Un extent es una serie de bloques que estn numerados consecutivamente dentro de un Datafile.

Fsicamente un tablespace puede consistir de mltiples DataFiles y en un nivel ms abajo, un bloque puede consistir de mltiples Bloques de Sistema Operativo. Mientras que lgicamente, un tablespace puede contener varios segmentos, cada uno constituido por varios extents.

El Diccionario de Datos almacena metadatos, es decir datos acerca de los datos. Describe la Base de Datos tanto Fsica como Lgicamente.

Las tablas del Diccionario de Datos son generados a la hora que se crea la Base de Datos, pero dichas tablas no pueden ser accesadas directamente. Para poder consultar el Diccionario de Datos, Oracle provee un conjunto de vistas, estas vistas poseen alguno de estos 3 prefijos:

DBA_ ALL_ USER_ Cualquier vista que posea el prefijo USER_, mostrar todos los objetos pertenecientes al usuario.

Toda vista que contenga el prefijo ALL_, desplegar todos los objetos a los cuales el usuario tiene algn tipo de acceso.

Las vistas que posean el prefijo DBA_, listarn todos los objetos de la Base de Datos.

La relacin que existe entre los tablespaces y los Datafile se mantiene gracias al Controlfile. El Controlfile lista todos los Datafiles con sus respectivos tablespaces a los que pertenecen.

El extent_map, lista todos los extents que crean una tabla y muestra con detalle que extent se encuentra en que datafile, en que bloque empieza que extent y de cuntos bloques esta conformado cada extent. http://lecturasoracle.wordpress.com/2012/04/25/la-arquitectura-de-la-base-de-datos-oracle/

# Fichero de Configuracion Oracle 7 # fichero: configdemo.ora

# localizacion: /opt/app/oracle/admin/demo

control_files = (/export/home/oradata/demo/control01.ctl, /export/home/oradata/demo/control02.ctl, /export/home/oradata/demo/control03.ctl) background_dump_dest = /opt/app/oracle/admin/demo/bdump core_dump_dest = /opt/app/oracle/admin/demo/cdump user_dump_dest = /opt/app/oracle/admin/demo/udump log_archive_dest = /opt/app/oracle/admin/demo/arch/arch.log db_block_size = 2048 db_name = demo

initdemo_0.ora

# # Fichero initdemo_0.ora, utilizado en la creacion de la BD # localizacion: /opt/app/oracle/admin/demo #

# incluir los parametros de configuracion de la BD ifile = /opt/app/oracle/admin/demo/configdemo.ora

rollback_segments = ()

db_files = 20

db_file_multiblock_read_count = 8 db_block_buffers = 200 shared_pool_size = 3500000 log_checkpoint_interval = 10000

processes = 50 dml_locks = 100 log_buffer = 8192 sequence_cache_entries = 10 sequence_cache_hash_buckets = 10 # audit_trail = true # timed_statistics = true # si quieres auditar # si quieres estadisticas de tiempo # limita tamano del fichero traza a

max_dump_file_size = 10240 5Mb each # log_archive_start = true compatible = 7.1.0.0 global_names = TRUE

# si quieres archivado automatico

initdemo.ora

# # Fichero initdemo.ora # localizacion: /opt/app/oracle/admin/demo #

# incluir configuracion de los parametros de la BD ifile = /opt/app/oracle/admin/demo/configdemo.ora

rollback_segments = (r01,r02)

db_files = 20

db_file_multiblock_read_count = 8 db_block_buffers = 200

shared_pool_size = 3500000 log_checkpoint_interval = 10000 processes = 50 dml_locks = 100 log_buffer = 8192 sequence_cache_entries = 10 sequence_cache_hash_buckets = 10 # audit_trail = true # timed_statistics = true # si quieres auditar # si quieres estadisticas de tiempo # limita tamano del fichero traza a

max_dump_file_size = 10240 5Mb each # log_archive_start = true compatible = 7.1.0.0 global_names = TRUE

# si quieres archivado automatico

remote_os_authent = TRUE os_authent_prefix = ""

PDF: http://www.jorgesanchez.net/bd/arquOracle.pdf
Oracle Componentes de la arquitectura de Oracle

Oracle Componentes de la arquitectura de OracleESOracle - Composants de larchitecture OracleFROracle - Componentes da arquitetura do OracleBR Enero 2014

Un servidor Oracle es un sistema que permite administrar bases de datos y que ofrece un medio de gestin de informacin abierto, completo e integrado. Un servidor Oracle est constituido de una instancia y una base de datos. Graf Instancia de Oracle

La instancia de Oracle permite acceder a la base de datos Oracle y permite abrir nicamente una sola base de datos. La instancia de Oracle est compuesta de: procesos en segundo plano que administran y aplican las relaciones entre las estructuras fsicas y las estructuras de memoria. Existen dos categoras: los procesos en segundo plano obligatorios: DBWN, PMON, CKPT, LGWR, SMON los procesos en segundo plano facultativos: ARCn, LMDn, RECO, CJQ0, LMON, Snnn, Dnnn, Pnnn, LCKn, QMNn estructuras de memoria: compuestas bsicamente de dos reas de memoria: el rea de memoria asignada a la SGA (System Global Area): asignada al inicio de la instancia y representa un componente fundamental de una instancia de Oracle. Est compuesta de varias reas de memoria: el rea de memoria compartida el buffer cach de la base de datos el log buffer as como otras estructuras para la gestin de bloqueos externos (lock), internos (match), datos estadsticos, etc. Eventualmente tambin es posible configurar al nivel de la SGA el rea de memoria LARGE POOL el rea de memoria Java el rea de memoria asignada a la PGA (Program Global Area): sta es asignada al inicio del proceso de servidor. Es reservada a cada proceso de usuario que se conecte a la base de datos Oracle y liberada al final del proceso.

El proceso de usuario

Es el programa que solicita una interaccin con la base de datos iniciando una conexin. Se comunica nicamente con el proceso de servidor correspondiente. El proceso de servidor

Representa el programa que entra directamente en interaccin con el servidor Oracle. Responde a todas las peticiones y envia los resultados. Puede estar dedicado a un servidor cliente o compartido por varios. Base de datos Oracle

La base de datos Oracle es un conjunto de datos tratados como una sola y misma entidad y est constituida de tres tipos de archivos, a saber: los ficheros de control los ficheros de datos los ficheros log

Annonces Google Quin es mi cliente? Si se hace esta cuestin, necesita un software capaz. Conozca AibE. www.zasylogic.com Vase tambin

Oracle Componentes de la arquitectura de Oracle Memoria SGA y PGA Oracle En que componente de la arquitectura se guard Foro - Windows Oracle Optimizar el rendimiento de Import/Export Consejos - Oracle Abrir una base datos Oracle conteniendo un data file faltante Consejos - Oracle Oracle Optimizacin de las operaciones de ordenacin Consejos - Oracle Oracle Deteccin de objetos superando el MAXEXTENT Consejos - Oracle En la misma categora

Oracle Deteccin de objetos superando el MAXEXTENT Oracle Funciones y procedimientos almacenados Oracle Generar estadsticas Oracle Informacin acerca del tamao de la base de datos Oracle Optimizacin de las operaciones de ordenacin Oracle Optimizar el rendimiento de Import/Export Reiniciar una secuencia Utilizar SQLPlus bajo Linux Comunidad de asistencia y consejos.

Foro Foro de Windows

Oracle - Composants de larchitecture OracleOracle - Composants de larchitecture Oracle Por wjaouadi el 15 de julio de 2009 Oracle - Componentes da arquitetura do OracleOracle - Componentes da arquitetura do Oracle Por pintuda el 14 de mayo de 2010 El artculo original fue escrito por wjaouadi. Traducido por Carlos-vialfa. http://es.kioskea.net/faq/3000-oracle-componentes-de-la-arquitectura-de-oracle Arquitectura (SQL Server Compact)

SQL Server 2008 R2 Otras versiones Personas que lo han encontrado til: 0 de 2 - Valorar este tema La arquitectura de Microsoft SQL Server Compact 3.5 incluye tanto un entorno de desarrollo como un entorno de cliente y servidor. En esta seccin se describen los componentes que forman cada entorno. Arquitectura de SQL Server Everywhere Edition Entorno de desarrollo El entorno de desarrollo incluye el equipo en el que se desarrollan las aplicaciones. Este equipo debe tener las versiones apropiadas de Microsoft Visual Studio para crear aplicaciones para SQL Server Compact 3.5. Visual Studio 2010 es ms adecuado para desarrollar aplicaciones de SQL Server Compact 3.5 en equipos. Es preferible usar Visual Studio 2008 Service Pack 1 (SP1) para desarrollar aplicaciones de SQL Server Compact 3.5 para dispositivos. Estas versiones de Visual Studio se pueden instalar en el mismo equipo y ejecutarse en paralelo. Puede crear aplicaciones administradas con Microsoft Visual Basic o C#, o bien puede usar Microsoft Visual C++ para crear aplicaciones nativas. Para obtener ms informacin acerca del entorno de desarrollo, vea Instalar un entorno de desarrollo. Entorno de cliente y servidor En la arquitectura de SQL Server Compact 3.5, el entorno de cliente se compone de uno o varios equipo y dispositivos compatibles en los que se implementan la aplicacin y SQL Server Compact 3.5. Cuando los dispositivos carecen de conectividad de red, puede utilizar Microsoft ActiveSync para conectar SQL Server Compact 3.5 al entorno de servidor. El entorno de servidor est formado por uno o varios equipos en los que se ejecuta Microsoft Internet Information Services (IIS) y una instancia de SQL Server o datos propagados para un origen de datos heterogneo. Puede ejecutar IIS y SQL Server en el mismo equipo o

configurarlos en varios equipos. IIS es necesario para conectarse e intercambiar datos entre servidores y clientes. En esta seccin Tema Descripcin Entorno de desarrollo Proporciona ms informacin sobre el entorno de desarrollo de SQL Server Compact 3.5. Entorno de cliente y servidor Proporciona ms informacin sobre el entorno de cliente y servidor de SQL Server Compact 3.5. Te ha resultado til? S No 2014 Microsoft Administre su perfil Boletn |Contacte con nosotros http://technet.microsoft.com/es-es/library/ms172445(v=sql.105).aspx Memorias de un DBA Un blog dedicado a contribuir a la comunidad SQL Server en espaol Arquitectura de Bases de Datos SQL Server con 7 comentarios

La arquitectura interna de las bases de datos en SQL Server estn compuestas por 2 tipos de estructura, la estructura lgica y la estructura fsica. Es muy importante conocer cmo es que estas estructuras estn compuestas y cul es la relacin que tienen los objetos de base de datos con cada una de estas estructuras.

Estructura Lgica:

Desde el punto de vista lgico, la base de datos debe tener al menos 1 FileGroup el cual contiene a toda la metadata de la misma base de datos, es decir tablas y vistas de sistema, a este FileGroup inicial se le conoce como Primario y est presente en todas las bases de datos. Todos los objetos de usuario que contengan data, ya sean tablas o ndices, deben estar ligados a un FileGroup, esto se puede definir al momento de ejecutar la sentencia DDL de creacin del objeto, si no se indica a que FileGroup estar ligado ese objeto, este

pertenecer al FileGroup por defecto definido en la base de datos. La base de datos solo puede tener definido 1 solo default FileGroup.

Las bases de datos pueden tener hasta 32767 FileGroups definidos, segn los lmites establecidos para la ltima versin de SQL Server, la cual es SQL Server 2008 R2. Uno de los propsitos de los FileGroups es poder distribuir la data a travs de varios discos duros fsicos, de esta manera se puede obtener mayor rendimiento en las operaciones de I/O debido a que ms de un disco trabajara al mismo tiempo. Otro de los propsitos es poder esconder la ubicacin fsica real de la informacin a los programadores, ya que para ellos la tabla X pertenece al FileGroup A, pero no saben en que data files fsicamente se encuentra la informacin de la tabla X.

Los FileGroups pueden contener 1 o ms Datafiles, y cada uno de estos datafiles se pude encontrar en un discos diferentes, lo cual tambin agilizara las consultas y los ingresos de informacin a las tablas que se encuentren asignadas a este FileGroup, debido a que SQL Server distribuir la informacin uniformemente a travs de todos los DataFiles del FileGroup.

Estructura Fsica:

Desde el punto de vista fsico, como ya hemos visto, tenemos los DataFiles que los en realidad los archivos de datos, es decir donde se guarda toda la informacin de la base de datos. Un DataFile solo puede pertenecer a 1 FileGroup.

Internamente los DataFiles estn divididos en Extends y estos a su vez en Pages. Las Pages son la unidad minima de almacenamiento dentro de la base de datos. Un Page tiene 8 Kb de tamao en espacio de disco. Un Extend tiene 8 Pages contiguas que lo conforman, es decir, un Extend tiene como tamao 64 Kb de espacio en disco.

En un Page solo puede haber informacin de 1 sola tabla, es decir el espacio de un Page no es compartido entre tablas o ndices. En el caso de los Extends, estos pueden ser de dos tipos:

Mixed: Los cuales son compartidos hasta por 8 objetos, uno por cada Page. Uniform: Los cuales solo pertenecen a un solo objeto, es decir que todos los Pages pertenecen a un solo objeto. Normalmente cuando se crea una nueva tabla esta es asignada a un Extend de tipo Mixed, hasta alcanzar la utilizacin de hasta 8 Pages, a partir de ese momento se asignan Extends de tipo Uniform para optimizar el uso del espacio en la tabla.

Los DataFiles normalmente tienen 2 extensiones de archivo, las cuales son estandar mas no obligarias, la extencion mdf que se utiliza para el primer Datafile perteneciente al FileGroup primario, y la extension ndf que se utiliza para los demas datafiles que se agregan posteriormente a los demas FileGroups de la base de datos.

En el caso del LogFile, este no pertenece a un FileGroup en especifico, en cambio archivo esta ligado directamente a la base de datos. Las bases de datos de SQL Server solo pueden tener un solo LogFile activo al mismo tiempo, si bien se pueden crear multiples LogFiles en la base de datos, solo uno podra ser escrito, ya que solo uno puede estar activo, cuando este archivo se llene, la base de datos pasara a escribir al siguiente archivo de transacciones, y asi sucesivamente. Por esta razon no es muy conveniente ni util tener mas de un LogFile.

En conclusin espero que sea de ayuda estas explicaciones sobre la arquitectura de una base de datos de SQL Server, si desean temas por favor no duden en solicitarlo, har lo posible para poder cubrir los temas solicitados en el mas corto tiempo. http://dbamemories.wordpress.com/2011/07/11/arquitectura-de-bases-de-datos-sql-server/ Arquitectura fsica de SQL Server

La forma en la que "vemos" una base de datos, y la manera en que esta base de datos reside o se estructura en un ordenador o un conjunto de ellos puede ser muy diferente. Algunas de estas diferencias se muestran en el cuadro siguiente:

Un administrador de bases de datos (DBA) ve: Mientras que SQL Server ve: Bases de Datos almacenadas fsicamente en archivos Bases de Datos almacenadas fsicamente en archivos Tablas, ndices, vistas y otros objetos colocados en grupos de archivos Pginas asignadas a tablas e ndices Columnas (campos) filas (registros) y almacenadas en tablas Informacin almacenada en paginas Una Base de Datos se crea sobre un conjunto de archivos de base de datos. La forma en la que se almacene va a afectar en gran media al rendimiento (velocidad) de respuesta ante consultas y actualizaciones.

La pgina es el nivel inferior de entrada/salida de SQL Server, y es la unidad de almacenamiento fundamental. Las pginas contienen los propios datos o bien informacin acerca de la disposicin fsica de los datos.

Existen seis tipos de pgina en SQL Server:

Tipo de Pgina Almacena Datos Las filas reales (registros) que forman las tablas de datos. ndice Los elementos de ndice y punteros. Texto e imagen Los datos de texto e imgenes Mapa de Asignacin Global Informacin acerca de las extensiones empleadas Pgina de Espacio Libre Informacin acerca del espacio libre en las pginas. Mapa de Asignacin de ndices Informacin acerca de las extensiones usadas por una tabla o ndice. Todas las pginas tienen una disposicin similar. Todas tienen una cabecera de pgina de 96 bytes, y un cuerpo que, en consecuencia, ocupa 8.096 bytes. La informacin almacenada en la cabecera y en el cuerpo depende del tipo de pgina. El administrador de una base de datos, con sus privilegios, puede examinar el contenido de una pgina mediente el comando DBCC PAGE.

Un archivo de base de datos puede configurarse para crecer automticamente, si se desea, o se puede limitar en su crecimiento. La unidad ms pequea de entrada/salida y la estructura bsica de almacenamiento es una pgina de 8 KB. Las pginas de una tabla o ndice se agrupan de ocho en ocho, en extensiones. Las extensiones pueden compartirse entre tablas, lo que hace que se desperdicie menos espacio de almacenamiento entre tablas pequeas. Utilizando grupos de archivos, se puede especificar el archivo (o conjunto de archivos) en el que se debera almacenar una tabla o ndice.

Un ndice agrupado ordena la tabla de acuerdo a la clave del ndice. Los ndices no agrupados (tambin llamados rboles binarios) apuntan a las filas de datos.

El tamao mximo de un nico archivo de base de datos es de 32 TB (treinta y dos billones de bytes), y el tamao mximo de una base de datos es de 1.048.516 TB.

http://sqlserver.galeon.com/dos.html Tipo de datos y Vistas

La integridad es una propiedad bsica de las bases de datos. El tipo ms bsico de integridad es la definicin del tipos de datos que se puede almacenar en cada columna. Esto no solo restringe los "caracteres" que se pueden almacenar en cada columna, sino que tambin proporciona a SQL Server un conocimiento bsico sobre la semntica de los datos.

Se debe seleccionar ciudadosamente los tipos de datos a emplear en una tabla. Los tipos de datos que se seleccionen tienen implicaciones en cuanto a la utilizacin del espacio, el rendimiento, y otras cuestiones relativas a su sistema. SQL Server permite cambiar los tipos de datos de las tablas existentes, siempre que sea posible una conversin implcita.

Tipo de Datos Nombre Caractersticas Caracteres char Longitud fija Caracteres nchar Longitud fija Unicode Caracteres varchar Longitud variable Caracteres nvarchar Longitud variable Unicode Caracteres varbinary

Binario Caracteres image Para objetos binarios (como imgenes) de hastas 2 GB por fila Caracteres timestamp Sello de tiempo. Slo puede haber una columna Timestamp por tabla. Fecha datetime Para almacenar fechas y horas Lgico bit

Numrico int 1 byte, rango desde 0 hasta 255 Numrico smallint 2 bytes, rango desde -32.768 hasta 32.768 Numrico tinyint 4 bytes, rango desde -2.147.483,647 hasta 2.147.483,647 Numrico float hasta 15 dgitos (-1,79E308 hasta 1,79E308) Numrico real hasta 7 dgitos (-3,40E38 hasta 3,40E38) Numrico numeric Exacto

Numrico decimal Exacto Numrico money 8 bytes (-922.337.203.685.477 hasta 922.337.203.685.477) Numrico smallmoney 4 bytes (-214.748,364 hasta 214.748,364)

Vistas

Adems de tablas de datos hay Vistas. Una Tabla es una estructura fsica que contiene datos en filas y columnas. Una Vista es una forma lgica de ver los datos fsicos ubicados en las tablas. Una definicin de Vista no es ms que una Select almacenada, una ventana a los datos almacenados.

Ejemplo

CREATE VIEW "Corredores_Veteranos" AS

SELECT Nombre, Apellidos, Numero, Edad

FROM Inscritos

WHERE Edad>40;

(Las palabras CREATE, VIEW, SELECT, FROM y WHERE, no son ms que elementos del lenguaje SQL que se explican posteriormente en la leccin 16).

En este ejemplo, existe una tabla de datos de corredores inscritos en un carrera popular. Se crea una Vista, que muestra slo los corredores veteranos, es decir aquellos que tienen ms de 40 aos de edad.

El empleo de Vistas proporciona una gran flexibilidad a las bases de datos relacionales, y especialmente a SQL Server, permitiendo ofrecer a distintos usuarios y a distintas aplicaciones una perspectiva distinta de los datos almacenados en la base, sin incurrir en redundancias. http://sqlserver.galeon.com/tres.html Procedimientos Almacenados y Desencadenadores

Adems de Tablas y Vistas, una base de datos contiene otra serie de objetos (elementos) necesarios para su funcionamiento y que se deben conocer.

Procedimientos almacenados

Un procedimiento almacenado (procedure) es un objeto ejecutable de la base de datos que est almacenado en la misma. En trminos coloquiales lo podramos llamar "programa". Pueden ser llamados de forma interactiva desde aplicaciones cliente, desde otros procedimientos almacenados, y tambin desde los desencadenadores. Los procedimientos almacenados pueden aceptar y devolver parmetros, tambin diversos conjuntos de resultados, y un cdigo de estado.

Los procedimientos almacenados son un buen lugar donde programar las reglas de negocio de las aplicaciones, y generalmente son ms eficientes que programar tales reglar en los programas ejecutables en la parte "cliente".

Estos procedimientos se programas en Transac-SQL, que es una extensin del lenguaje de consulta SQL.

Desencadenadores

Los desencadenadores (trigger) son un tipo especial de procedimientos almacenados que se ejecutan automticamente como parte de una instruccin de modificacin de datos (INSERT, UPDATE o DELETE). Cuando una de las acciones para las que se ha definido el desencadenador

ocurre, el desencadenador se activa automticamente. Este se ejecuta en el mismo espacio de transacciones que la instruccin de modificacin de datos

Son una herramienta muy potente para el mantenimiento de la integridad de la base de datos, ya que pueden:

Comparar las versiones anterior y posterior

Deshacer modificaciones no vlidas

Leer otras tablas

Modificar otras tablas

Ejecutar procedimientos almacenados locales y remotos

Se pueden crear y administrar los desencadenadores de cada tabla desde el Administrador Corporativo. Para ello, una vez posicionado sobre la tabla en que se quiere crear o modificar un desencadenador, se accede al men pulsando el botn derecho del ratn.

De esta forma slo hay que especificar el nombre del desencadenador, la tabla en la que est y sobre la que acta, el motivo por el que se dispara (insercin, actualizacin o borrado), y la secuencia de acciones programadas.

http://sqlserver.galeon.com/cuatro.html

Bases y Tablas del Sistema

Cuando se instala SQL Server se crean cuatro bases de datos del sistema que guardan informacin del propio sistema, son necesarias para su funcionamiento, y no son utilizables directamente por el usuario:

La base de datos Master registra toda la informacin de nivel de sistema para el servidor SQL Server. Esto incluye las cuentas de inicio de sesin, parmetros de configuracin del servidor, la existencia de otras bases de datos, etc. La base de datos Master MASTER es absolutamente crtica para los datos, por le que debera mantener siempre una copia de seguridad de la misma. La mayor parte de los procedimientos almacenados del sistema tambin se guardan en esta base de datos, junto a los mensajes de error. Su uso principal es el almacenamiento de la informacin que emplea el agente SQL Server, como programacin de trabajos, definicin de operadores y alertas. La informacin de la copia de seguridad tambin se almacena en esta base de datos, y se emplea en la restauracin de la base de datos.

MSBD

Es una base de datos plantilla, que se emplea cada vez que se crea una nueva base de datos. Los contenidos de la base Model se MODEL copian a la nueva base. Si se desea que determinados objetos, permisos, usuarios se creen automticamente cada vez que se crea una base de datos, pueden incluirse en esta base. Algunas veces SQL Server necesita crear tablas temporales internas (o tablas de trabajo) para determinadas operaciones. Entre dichas operaciones se incluye la ordenacin, las operaciones multitabla, el tratamento de cursores, etc. Estas tablas temporales se borran tan pronto como el conjunto de TEMPDB resultados se devuelve a la aplicacin cliente, o cuando se cierra el cursor. Almacena todas las tablas y procedimientos almacenados temporales. Esta base de crea de nuevo cada vez que se inicia SQL Server, por lo que no tiene sentido crear copias de seguridad de esta.

Cada base de datos dispone de un conjunto de tablas que la describen. Estas tablas se denominan Catlogo de la base de datos. La base de datos MASTER tiene un conjunto adicional de tablas que describen la instalacin de SQL Server. Este conjunto se denomina Catlogo del sistema. El catlogo de la base de datos MSDB se usa como rea de almacenamiento para:

La informacin de configuracin utilizada por el Agente SQL Server. Incluye informacin acerca de trabajos, pasos de trabajo, alertas, operadores, etc. Informacin histrica de copia de seguridad. Se conserva para que el Administrador Corporativo pueda ayudar en la restauracin de la base de datos.

Adems de tablas, tambin hay Vistas del Sistema, y Procedimientos almacenados del Sistema. Un procedimiento almacenado del sistema es un procedimiento almacenado con algunas caractersticas especiales. Estos procedimientos, creados cuando SQL Server se instala, se usan para administrar el Servidor. Evitan al administrador tener que acceder directamente a las tablas del sistema. Los siguientes atributos identifican un procedimiento almacenado del sistema:

El nombre del procedimiento almacenado empieza por sp_. El procedimiento se almecena en la base de datos Master. El procedimiento es propiedad del dbo, es decir ha sido creado por el administrador del sistema.

ANSI SQL-92 define un conjunto de vistas que proporcionan informacin acerca de los datos del sistema. Estas vistas estn disponibles en SQL Server 7.0. La ventaja de usar vistas en lugar de consultar directamente a las tablas del sistema, es que la aplicacin es menos dependiente del sistema de administracin de base de datos o de una versin particular.

Arquitectura de Integration Services

SQL Server 2008 R2 Otras versiones Este tema an no ha recibido ninguna valoracin - Valorar este tema Como se muestra en el diagrama siguiente, Microsoft SQL Server Integration Services incluye diversos componentes. Arquitectura de Integration Services De los componentes mostrados en el diagrama anterior, los siguientes son importantes para utilizar Integration Services correctamente: Diseador SSIS El Diseador SSIS es una herramienta grfica que se puede usar para crear y mantener paquetes Integration Services. El Diseador SSIS est disponible en Business Intelligence Development Studio como parte de un proyecto de Integration Services. Para obtener ms informacin, vea Diseador SSIS y Integration Services en Business Intelligence Development Studio.

Motor en tiempo de ejecucin El tiempo de ejecucin de Integration Services guarda el diseo de paquetes, ejecuta paquetes y admite registros, puntos de interrupcin, configuracin, conexiones y transacciones. Para obtener ms informacin, vea Paquetes de Integration Services. Tareas y otros ejecutables Los ejecutables de tiempo de ejecucin de Integration Services son el paquete, los contenedores, las tareas y los controladores de eventos que incluye Integration Services. Los ejecutables de tiempo de ejecucin tambin incluyen tareas personalizadas que el usuario puede desarrollar. Para obtener ms informacin, vea Tareas de Integration Services, Contenedores de Integration Services y Controladores de eventos de Integration Services. Motor de flujo de datos (tambin conocido como canalizacin) y componentes de flujo de datos La tarea Flujo de datos encapsula el motor de flujo de datos. El motor de flujo de datos proporciona los bferes en memoria que mueven datos desde el origen hasta el destino y llama los orgenes que extraen datos de archivos y bases de datos relacionales. El motor de flujo de datos tambin administra las transformaciones que modifican datos y los destinos que cargan datos o los ponen a disposicin de otros procesos. Integration Services Los componentes de flujo de datos son los orgenes, transformaciones y destinos que se utilizan diferentes tipos de elementos de flujo de datos: orgenes que extraen datos, transformaciones que Integration Services incluye. Tambin puede incluir componentes personalizados en un flujo de datos. Para obtener ms informacin, vea Tarea Flujo de datos y Elementos de flujo de datos. API o modelo de objetos El modelo de objetos de Integration Services incluye interfaces de programacin de aplicaciones (API) administradas para crear componentes personalizados para su uso en paquetes, o aplicaciones personalizadas que crean, cargan, ejecutan y administran paquetes. El programador puede escribir aplicaciones personalizadas o tareas y transformaciones personalizadas utilizando cualquier lenguaje que cumpla con Common Language Runtime (CLR). Para obtener ms informacin, vea Gua del desarrollador (Integration Services). Servicio Integration Services El servicio Integration Services permite usar SQL Server Management Studio para supervisar paquetes Integration Services en ejecucin y para administrar el almacenamiento de los paquetes. Para obtener ms informacin, vea Administrar Integration Services y Usar SQL Server Management Studio. Asistente para importacin y exportacin de SQL Server

El Asistente para importacin y exportacin de SQL Server puede copiar datos entre orgenes de datos para los que est disponible un proveedor de datos de .NET Framework administrado o un proveedor OLE DB nativo. El Asistente ofrece tambin el mtodo ms simple para crear un paquete Integration Services que copia datos de un origen en un destino. Para obtener ms informacin, vea Usar el Asistente para importacin y exportacin de SQL Server para mover datos. Otras herramientas, asistentes y utilidades de smbolo del sistema Integration Services incluye herramientas, asistentes y utilidades de smbolo del sistema adicionales para ejecutar y administrar paquetes de Integration Services. Para obtener ms informacin, vea Asistentes de Integration Services y Utilidades del smbolo del sistema (Integration Services). Icono de Integration Services (pequeo) Mantngase al da con Integration Services Para obtener las ms recientes descargas, artculos, ejemplos y vdeos de Microsoft, as como soluciones seleccionadas de la comunidad, visite la pgina de Integration Services en MSDN o TechNet: Visite la pgina de Integration Services en MSDN Visite la pgina de Integration Services en TechNet Para recibir notificaciones automticas de estas actualizaciones, suscrbase a las fuentes RSS disponibles en la pgina. http://technet.microsoft.com/es-es/library/bb522498(v=sql.105).aspx Arquitectura de MySQL

martes, 26 de marzo de 2013

ARQUITECTURA LGICA DEL MySQL QUE ES SQL? Por sus siglas en ingles, structured query language.

El lenguaje de consulta estructurado o SQL es un lenguaje declarativo de acceso a base de datos relacionales que permite especificar diversos tipos de operaciones en ellas. Una de sus caractersticas es el manejo del algebra y el calculo relacional que permiten efectuar consultas con el fin de recuperar de forma sencilla informacin de inters de bases de datos, as como hacer cambios en ella. TIPO DE DATOS Los tipos datos bsicos de SQL son: Date: una fecha de calendario que contiene el ao (de cuatro cifras), el mes y el da.

Time: La hora del da en horas minutos segundos (el valor predeterminado es 0). Timestamp: la combinacin de Date y Time.

MOTORES DE ALMACENAMIENTO Para el diseo fsico del MySQL es necesario ver por sobretodo un buen motor de almacenamiento que es nica en el mundo de las bases de datos. Ahora veremos los elementos que esta puede implementar: Concurrencia: es necesario tener una poltica de bloqueo o ninguna, sin embargo esta causa de que el tiempo de procesamiento se vuelva mucho mas lento por lo cual la concurrencia no es alta. Soporte de transacciones drsticamente es el

Indexado: las diferentes tcnicas de indexado pueden influir rendimiento de una base de datos.

Transacciones: dota de fiabilidad a los datos mientras se realizan

operaciones, te permite utilizar los datos pero slo te permite guardarlos cuando se comprueba que las otras condiciones que pudiesen requerirse se han cumplido. Comprobacin de la integridad referencial: incluye detalles detalles de la representacin en disco de informacin, sin embargo esta parte se cumple mas en lo que es almacenamiento fsico. Soporte de ndices, depende mucho de los detalles del almacenamiento fsico, cada motor de almacenamiento proporciona sus propios mtodos de indexacin. Cachs de memoria, depende mucho de cmo procesan los datos las aplicaciones.

Algunos motores pueden ser: El motor InnoDB, soporta transacciones a cambio de un sacrificio de la velocidad de lectura y escritura en un factor 1:10. El motor MyISAM, este se caracteriza principalmente por ofrecer una lectura y escritura rpidas. Adems, es el nico motor que posibilita la bsqueda fulltext. Adems de InnoDB y MyISAM existen los siguientes motores con unas caractersticas muy especiales: MEMORY: Mantiene los datos en memoria, lo que permite obtener una velocidad muy alta. Por contra, los datos se pierden al apagar el servidor. MERGE: Posibilita acceder a varias tablas con la misma estructura como si se tratase de una misma tabla. BLACKHOLE: Procesa todas las consultas pero no almacena los datos en ningn sitio. Es como un agujero negro. CONECTORES

 MySQL ofrece conectividad controlador estndar de base de datos MySQL para utilizar con aplicaciones y herramientas que sean compatibles con estndares de la industria ODBC y JDBC. Cualquier sistema que trabaja con ODBC o JDBC puede usar MySQL. Los conectores MySql son los drivers que utilizan los programas cliente para conectarse al servidor, estn disponibles para Windows y Unix. Para utilizar un conector debe instalarse en la mquina cliente. No es necesario que la maquina cliente y el servidor corran bajo el mismo sistema operativo. GESTOR DE CONEXIONES Un gestor de conexin representa una agrupacin de conexiones, en lugar de una nica conexin de red cliente-servidor de MySQL. La agrupacin de conexiones consiste en una conexin maestra, y opcionalmente cualquier nmero de conexiones esclavas. El gestor de conexiones de MySQL puede configurarse para limitar el nmero de conexiones concurrentes. PROCESADOR DE CONSULTAS El procesamiento de consultas tiene varias etapas a seguir para resolver una consulta SQL, las caractersticas del modelo relacional permiten que cada motor de base de datos elija su propia representacin que, comnmente, resulta ser el lgebra relacional. La optimizacin de consultas es una de estas etapas. Cuando una consulta llega al gestor de MySQL, se analiza detalladamente y se produce una representacin intermedia de la misma consulta. Posteriormente MySQL toma una serie de decisiones, que pueden incluir el determinar el orden de lectura de las tablas, el uso de ciertos ndices, o la re-escritura de la consulta en una forma ms eficiente. OPTIMIZADOR DE CONSULTAS MySQL utiliza un optimizador basado en costos para determinar la mejor manera de resolver una consulta. En muchos casos, MySQL puede calcular el mejor plan de consulta posible, pero a veces MySQL no tiene suficiente informacin sobre los datos a mano y tiene que hacer suposiciones educadas sobre los datos. EXPLAIN, mediante esta podemos obtener toda la informacin sobre el modo en el que una consulta SQL se ejecutara en el servidor. Es extremadamente til para conocer la configuracin de ndices en las tablas, los ndices que podran ser configurados para mejorar su rendimiento, el nmero de filas que se revisan, el tipo de query, etc. CACHE DE CONSULTAS La cach de consultas es muy til en un entorno donde tiene tablas que no cambian frecuentemente y donde el servidor recibe muchas consultas idnticas. La cach de consultas no devuelve datos antiguos, despus de haber hecho una modificacin en las tablas.

La cach de consultas no se usa para comandos preparados en la parte del servidor.

Actualmente para MySQL 5.0 Server se proporciona una query cache. Cuando se usa, la query cache almacena el texto de una consulta SELECT junto con el resultado que se le envi al cliente. CONTROL DE CONCURRENCIA El acceso simultneo descrito puede dar como resultados informacin incorrecta, dependiendo de la suerte que tengamos en la intercalacin de las lecturas y escrituras simultneas. Esta problemtica ha llevado a disear e implementar diferentes estrategias de control de concurrencia, que se encargan de evitar todos esos problemas, de modo que los desarrolladores de las aplicaciones pueden olvidarse de ellos al escribir su cdigo. MySQL tiene un apoyo limitado para el control de concurrencia. Como en la versin 3.0, no hay soporte para transacciones y, por lo tanto, no hay nivel de aislamiento de transaccin. Tampoco es posible revertir transacciones. GESTOR DE RECUPERACIN El gestor de recuperacin es responsable de restaurar la base de datos a su estado estable pasado. Tal operacin lo realiza usando el registro para la base de datos, que se adquiere del encargado del almacenador intermediario, y ejecutando cada operacin en el registro. Desde los registros del encargado del registro todas las operaciones realizadas en la base de datos (del principio de la vida de la base de datos), ejecutando cada comando en el fichero de diario recuperaran la base de datos a su estado estable pasado. GESTOR DE TRANSACCIONES Una transaccin es una sola unidad del trabajo que tiene unos o ms comandos de MySQL en ella. El gestor de transacciones es responsable de cerciorarse de que la transaccin est registrada y ejecutada atmico. Si existiera algn error, estas podras ser por: Error lgico (violacin de restricciones, tipos incompatibles, etc.). Error del sistema (interbloqueos, espacio insuficiente,etc.).

http://arquitecturademysqlingenieraorietha.blogspot.com/ Descripcion de los componentes de la Arquitectura MySQL. Editar 0 2

graphics1.png

Conectores: los conectores son bibliotecas en diferentes lenguajes de programacion que permiten la conexin (remota o local) con servidores MySQL y la ejecucin de consultas. Por

Ejemplo, el conector Conector/J permite conectarse a MySQL desde cualquier aplicacin programada en lenguaje Java, y utilizando el Java Database Connectivity (JDBC) API. Gestor de Conexiones: la gestin de conecxiones es responsable de mantener las mltiples conexiones de los clientes. Las conexiones consumen recursos de mquina, y crearlas y destruirlas son tambin procesos costosos. Por eso, el gestor de conexiones de MySQL puede configurarse para limitar el nmero de conexiones concurrentes. Procesador de Consultas: cada vez que una consulta llega al gestor de mySQL, se analiza sintcticamente y se produce una representacion intermedia de la misma. A partir de esa representacion, MySQL toma una serie de decisiones, que pueden incluir el determinar el orden de lectura de las tablas, el uso de ciertos ndices, o la re-escritura de la consulta en una forma ms eficiente. Optimizador de Consultas: dado que la optimizacin de las consultas depende de las capacidades del gestor de almacenamiento que se est utilizando, el optimizador "pregunta" al gestor si soporta ciertas caractersticas, y de este modo, puede decidir el tipo de optimizacion ms adeucado. Cach de Consultas: MySQL implmenta una cach de consultas, donde guarda consultas y sus resultados enteros. De este modo, el procesador de consultas, antes de nisiquiera plantear la optimizacion, busca la consutla en la cach, para evitarse realizar el trabajo en el caso que tenga suerte y encuentre la consulta en la cach. Control de Concurrencia: es un gestor de base de datos que es simplemente el mecanismo que se utiliza para evitar que lecturas o escrituras simultneas a las misma porcin de datos terminen en insconsistencias o efectos no deseados. Gestor de recuperacin: la recuperacion permite "volver hacia atrs" (rollback) partes de una transaccin. Gestor de Transacciones: la gestion de transacciones permite dotar de semntica "todo o nada" a una consulta o a un conjunto de consultas que se declaren como una sola transaccin. Motores de Almacenamiento: son unas interfaces abstractas con funciones comunes de gestin de datos en el nivle fsico.

Adicionalmente a los motores estandar de MySQL, los siguientes motores estn incluidos en los paquetes binarios y fuente de MariaDB: Aria: un motor de almacenamiento a prueba de fallos basado en MyISAM. PBXT: un motor de almacenamiento transaccional con una gran cantidad de nuevas caractersticas. XtraDb: es el reemplazo del motor INNODB basado en el plug-in de InnoDB. FederetedX: el reemplazo del motor Federated.

http://abd-ucvcomputacion.wikispaces.com/Descripcion+de+los+componentes+de+la+Arquitectura+MySQL.

miMySQL Un blog creado para desgranar los temas correspondientes a las certificaciones de MySQL.

martes, 8 de enero de 2013

ARQUITECTURA GENERAL DE MYSQL

MySql trabaja en un entorno de red con una arquitectura cliente / servidor, esto significa que un programa central acta como un servidor y los programas cliente se conectan a l para hacer peticiones.

Los componentes de la instalacin de MySql:

1.- Servidor MySql: (mysqld) Es el encargado de gestionar el acceso a la base de datos en el disco y en la memoria. Es multi-tarea y multi-usuario. Soporta distintos motores de almacenamiento que pueden gestionar distintos tipos de tablas.

2.- Programas cliente: son los programas que empleamos para comunicarnos con el servidor y nos sirven para operar con la base de datos.

Algunos de estos programas cliente son los siguientes:

*MySql Query Browser y MySql Administrator: son interfaces grficas para el servidor.

*mysql: es un programa en lnea de comandos que acta con un interface basado en texto para el servidor.

*Otros programas clientes en lnea de comandos son mysqlimport para importar archivos de datos, mysqldump para hacer copias de seguridad, mysqladmin para la administracin del servidor y mysqlcheck para comprobar la integridad de los archivos de base de datos.

3.- Utilidades no-clientes de MySql: trabajan separadas del servidor con lo cual no establecen primero una conexin con l. Por ejemplo: myisamchk, que realiza una comprobacin de tabla y reparacin, myisampack, que crea versiones de slo lectura comprimidas de tablas MyISAM. Estas utilidades actan accediendo a los archivos de las tablas MyISAM directamente independientes del servidor msqld. http://mimysql.blogspot.com/2013/01/arquitectura-general-de-mysql.html Una descripcin general de DB2

historia db2

1970:Se da el origen del DB2, y pertenece a la firma IBM. 1983:Se empez a vender DB2 con la versin 2.0. 1994:DB2 UDB (DB2 Universal Database) fue construido en base a dos productos incluidos en el DB2 de AIX, DB2 Common Server, que para propsitos generales inclua funciones avanzadas para el mercado de servidores de bases de datos, con soporte de hardware SMP y OLTP; y el DB2 Parallel Edition, que fue desarrollado para soportar aplicaciones de gran escala, como Data Warehousing y Data Mining. En la actualidad la tecnologa de gestin de datos de IBM es utilizada por ms de 40 millones de usuarios de 300.000 empresas en todo el mundo. Mientras que la evolucin del DB2, Universal Data Base dispone de ms de 6 millones de usuarios y 1.300.000 licencias instaladas.

aquitectura db2

en db2 existen tres niveles de jerarqua: mquina, instancia y base de datos.

la mquina y su sistema operativo gestionan los recursos que se comparten por todas las instancias y bases de datos. la configuracin a nivel de mquina afecta a todas las instancias.

el segundo nivel es instancia. es la unidad de administracin bsica de db2. controla los recursos asignados a cada base de datos, y es quien gestiona las comunicaciones y la creacin de agentes. el arranque y parada tambin se hacen a este nivel. dentro de una mquina puede haber muchas instancias.

como tercer nivel estn las bases de datos. aqu se configuran muchas de las variables que afectan al funcionamiento de las bases de datos. aunque la instancia es quien gestiona los recursos, cada base de datos, en general posee sus propios recursos. tiene sus propios bufferpools, su propio catlogo, su propia sortheap...

dentro de este tercer nivel, a su vez, est dividido entre la capa lgica y capa fsica, aunque se podra decir que hay un nivel superior que sera el nivel de vista, pero no voy a entrar ah.

en el nivel lgico estn los objetos de base de datos: vistas, tablas, ndices, triggers, procedimientos almacenados, funciones, secuencias...

en el nivel fsico estaran los tablespaces y sus containers. tambin podran considerarse como nivel fsico las reas de memoria, bufferpools, sortheap, etc...

1322689705957-esquema.gif

caracteristicas de db2

fcil y simple

muchos expertos de la industria y usuarios han elogiado las nuevas herramientas que ibm desarroll para facilitar la administracin y uso del db2 universal database. utiliza una interface grfica, estilo browser, para acceder y manejar objetos de la base de datos. incluye smart.guides que facilitan la tarea de configuracin, guindolo paso a paso para lograr un rendimiento ptimo de la base de datos y para asistir al usuario en la creacin de teclas con plantillas predefinidas. las herramientas mencionadas, ms otras incluidas en db2 universal database.

sql recursivo. permite el manejo de objetos grandes (hasta 2 gb).

monitor grfico: el cual posibilita observar el tiempo de ejecucin de una sentencia sql y corregir detalles para aumentar el rendimiento.

estndares abiertos: fue la primera base de datos que adopt el soporte java y los estndares xml.

capacidad xml: permite gestionar tanto datos relacionales convencionales como datos xml, sin necesidad de que tengan que ser transformados. esta capacidad es nica en el mercado.

compresin de almacenamiento"venom:

esta capacidad permite a db2 ofrecer una capacidad de compresin de almacenamiento similar a la de los grandes servidores corporativos mainframes, para entornos linux, unix y windows.

gestin autnoma del almacenamiento:

diseada para ayudar a los clientes a conseguir un ahorro adicional de tiempo y costes al automatizar las tcnicas de gestin del almacenamiento, que actualmente requieren numerosos cambios manuales por parte de los administradores.

mejoras en la seguridad:

db2 dispone de una solucin de control de accesos basada en etiquetas. adems, dispone de una nueva funcin de seguridad para el administrador, que permite unificar distintos privilegios bajo un solo usuario.

on-line transaction processing (oltp) :

es un tipo de procesamiento de transacciones a travs de una red de computadoras, se basa en la arquitectura cliente-servidor ya que suelen ser utilizados por empresas que no se encuentran 100% en el mismo medio fsico, sino expandidas geogrficamente.

data mining:

db2 posibilita el anlisis orientado al descubrimiento de informacin escondida en los datos, realizando modelizacin predictiva, segmentacin de la base de datos, anlisis de vnculos, o deteccin de desviaciones. incluye las siguientes tcnicas: clustering (segmentacin), clasificacin, prediccin, descubrimiento asociativo, descubrimiento secuencial de patrones y secuencias temporales. todas las tcnicas mencionadas permiten realizar segmentacin de clientes, deteccin defraudes, retencin de clientes, ventas cruzadas, etc.

db2 express-c es un miembro de la familia ibm db2 de poderosas aplicaciones de servidores de datos para manejar tanto datos relacionales como xml. db2 express-c es una edicin de db2 libre, sin lmites y fcil de usar. la c en db2 express-c significa comunidad. una comunidad de usuarios db2 express-c que se juntan para ayudarse unos a otros, tanto en lnea como fuera de ella. la comunidad db2 express-c consiste en una variedad de personas y compaas que disean, desarrollan, implementan o utilizan soluciones de base de datos.

libre para desarrollar: si eres un desarrollador de aplicaciones y necesitas una base de datos para tu aplicacin, t puedes usar db2 express-c.

Libre para implementar: Si ests trabajando en un ambiente de produccin y necesitas una base de datos para almacenar tus registros vitales, t puedes usar DB2 Express-C. Libre para distribuir: Si ests desarrollando una aplicacin o herramienta que requiera un servidor. Ventajas de DB2

Acceso a los datos en tablas de Oracle o MySQL. Copia de seguridad y proteccin de los datos. Soporta XML Soporta todo tipo de datos. Arquitectura Orientada a Servicios - SOA: permite construir un sistema informtico ms gil y fcilmente adaptable a las necesidades del cliente, reduciendo los tiempos de desarrollo y, gracias a la reutilizacin de componentes existentes. Tambin puede ejecutarse en varias plataformas Windows NT (R), Sun Solaris, HP-UX, AIX(R), OS/400 y OS/2(R). El SQL de DB2 es muy potente. Es especialmente interesante la implementacin de triggers.

Desventajas de DB2 Precio calidad: El precio DB2 arranca en 7.500 por procesador. Lentitud crear y ejecutar consultas. Influye en la eleccin el hardware utilizado. En sistemas grandes la base ms usada es DB2 ya que corre en diferentes plataformas operativas, pero en realidad, en la mayora de los casos la decisin para optar por un software de estas caractersticas es corporativa. Conclusin

db2 universal database es un sistema de gestin de base de datos relacionales completamente habilitado para la web que se puede escalar, desde procesadores simples hasta multiprocesadores simtricos y agrupamientos paralelos masivos.

Mediante el se puede influir en todos los aspectos relativos a la informacin de la empresa, ms all de simples filas y columnas de datos alfanumricos, incluyendo informacin en formato XML, imgenes, video en modalidad continua y otros formatos ricos en los medios. Mas sobre DB2 (Lea el pdf)

http://adsisena2011-2013.bligoo.com.co/arquitectura-db2#.Ut87RxDv7IU IBM DB2 Librese de los costos elevados de sus costos elevados de su base de datos Navegacin de pestaa primaria Librese con la administracin de datos IBM - pestaa seleccionada Navegacin de pestaa primaria Costos de administracin Costos de almacenamiento Costos del servidor Migre a DB2 fcilmente IBM DB2 le ayudar a reducir su inversin en TI DB2 automatiza algunas tareas de administracin de base de datos. Como resultado, algunos de los usuarios de base de datos nos informan de un importante ahorro en los costos de administracin de base de datos. Gracias a la compresin de almacenamiento de DB2 se necesita menos hardware para almacenar los datos, y as se reducen las necesidades de consumo de alimentacin. IBM ofrece un conjunto integrado de soluciones de administracin de datos que facilitan la colaboracin entre analistas, arquitectos, desarrolladores y administradores cuando trabajan con datos. DB2 ofrece el rendimiento lder del sector para varias cargas de trabajo. Esto significa que necesitar menos servidores para ejecutar su base de datos, ayudndolo a ahorrar en las licencias de software, el soporte y el mantenimiento. Cmbiese a DB2 y disfrute de estas ventajas, junto con todo lo que le ofrece la gran tradicin de fiabilidad, flexibilidad y disponibilidad de DB2. Comentarios de clientes

"Antes de tomar una decisin definitiva, creamos un ndice de rendimiento con algunos de los principales sistemas de gestin de bases de datos. Incluimos los productos de Oracle, SQL Server y DB2. Acabamos decidindonos por DB2 por varios motivos. En primer lugar estuvo la fiabilidad y en segundo el rendimiento, aunque quizs el factor ms importante de todos fue la facilidad de uso. - Bashir Khan, Dow Jones "La razn principal por la que nos cambiamos a DB2 9 fue el ahorro en costos." - Mark Lindsay, Makau Corporation "Con DB2 en la plataforma IBM Power Systems, obtenemos un gran rendimiento y fiabilidad a un precio muy bajo, adems de todo el potencial que necesitamos para aprovechar los ltimos avances en tecnologa de bases de datos." - Ozcan Soke, Borelik Los ejemplos anteriores son muestras de cmo han utilizado algunos clientes los productos de IBM y los resultados que han conseguido. Los costos reales del entorno y las caractersticas de rendimiento variarn en funcin de las condiciones y las configuraciones de cada cliente. * Usted ser direccionado a pginas de IBM en Estados Unidos con contenido en ingls. http://www-01.ibm.com/software/pe/db2/lowerdatabasecosts/ Clster de DB2 pureScale disperso geogrficamente (GDPC)

El clster de DB2 pureScale disperso geogrficamente (GDPC) es una configuracin que distribuir un clster de DB2 pureScale y que sus miembros se encuentren en ubicaciones distintas.

La caracterstica DB2 pureScale Feature proporciona un alto nivel de escalabilidad de bases de datos, disponibilidad y transparencia de aplicaciones en las plataformas AIX y Linux; se basa en la arquitectura de compartimiento de datos del estndar por excelencia, Parallel Sysplex de DB2 para z/OS. Sin embargo, cualquier sistema de una sola ubicacin, incluso los sistemas DB2 pureScale o Parallel Sysplex de DB2 para z/OS, puede ser vulnerable a sucesos externos que pueden poner en riesgo una ubicacin entera, como, por ejemplo, un corte en el suministro elctrico o una interrupcin de las comunicaciones de larga duracin.

Puesto que las catstrofes como los cortes de suministro elctrico y los incendios pueden inhabilitar un centro de datos, muchas organizaciones de TI configuran dos ubicaciones, lo suficientemente lejos una de otra como para pertenecer a redes de suministro elctrico diferentes. Esta configuracin reduce el riesgo de que haya una interrupcin total y permite a la empresa seguir trabajando en una ubicacin, aunque la otra est afectada por un desastre. Al igual que la configuracin de Geographically Dispersed Parallel Sysplex de DB2 para z/OS, el clster de DB2 pureScale disperso geogrficamente (GDPC) proporciona la escalabilidad y la

transparencia de aplicaciones de un clster de DB2 pureScale de una sola ubicacin normal, pero en una configuracin de varias ubicaciones que permite la disponibilidad de sistemas "activo/activo" en muchos tipos de catstrofes.

La disponibilidad activo/activo es fundamental porque supone que, durante el funcionamiento normal, los miembros de DB2 pureScale en ambas ubicaciones comparten la carga de trabajo de la forma habitual, con equilibrado de la carga de trabajo (WLB, workload balancing) para mantener un nivel de actividad ptimo en todos los miembros, tanto dentro de las ubicaciones como entre una ubicacin y la otra. Esto significa que la segunda ubicacin no es un sitio de reserva, en espera de que algo vaya mal. En lugar de ello, la segunda ubicacin realiza trabajo real, devolviendo el valor de la inversin, incluso durante las operaciones diarias.

Conceptos de GDPC Un clster de DB2 pureScale tpico consta, entre otras cosas, de: Dos o ms miembros de DB2 pureScale Dos recursos de almacenamiento en antememoria de clster (CF) Almacenamiento de clster conectado a una SAN donde se ejecuta IBM General Parallel File System (GPFS) Interconexin de alta velocidad con baja latencia, como InfiniBand (IB), 10GE o RoCE (RDMA (Remote Direct Memory Access) over Converged Ethernet) En la Figura 1 se muestra una configuracin de este tipo, con cuatro miembros y dos CF con InfiniBand para las comunicaciones de baja latencia. La caracterstica DB2 pureScale es una arquitectura de datos compartidos, en la que todos los miembros operan en una sola copia de la base de datos, comunicndose entre s a travs de los CF para sincronizar las actividades y para ingerir, modificar y recuperar datos segn precise la aplicacin. Los mensajes entre los miembros y los CF utilizan la funcin RDMA en la interconexin de clster, lo que proporciona latencias de comunicacin extremadamente bajas, as como una utilizacin de la CPU muy baja por mensaje. Existen algunas comunicaciones miembro a miembro muy limitadas en un clster de pureScale que utilizan la red Ethernet.

Figura 1. Configuracin de clster de DB2 pureScale tpica El diagrama muestra una configuracin de clster de DB2 pureScale tpica La divisin de un clster de DB2 pureScale en dos mitades en dos ubicaciones A y B implica que la mitad de los sistemas de los miembros se alojar fsicamente en la ubicacin A y la otra mitad en la ubicacin B. Para el desempate y la migracin tras error transparente en caso de anomala de una ubicacin, se requiere una tercera ubicacin. Tambin es necesario colocar un CF en cada una de las dos instalaciones principales, para evitar que haya puntos nicos de anomala (SPOF). Para preservar el mejor rendimiento y escalabilidad del software de DB2 pureScale, utilice una interconexin con capacidad para RDMA entre las ubicaciones, de modo que los mensajes que van de un miembro de una ubicacin al CF de la otra ubicacin sean tan

rpidos y econmicos como sea posible. La distancia que abarca una red InfiniBand normalmente se mide en decenas o quizs cientos de metros; sin embargo, existen dispositivos, como el expansor Obsidian Longbow InfiniBand, que permiten que el alcance de una red de interconexin de alta velocidad abarque distancias superiores, a travs de redes de rea amplia o de enlaces de fibra ptica dedicados.

Adems de la dispersin de los recursos informticos como los miembros y los CF, la configuracin del clster de recuperacin de catstrofes (DR) tambin requiere almacenamiento para duplicarse en las ubicaciones. Basada en el diseo del clster de DB2 pureScale estndar, la configuracin de GDPC utiliza la duplicacin sncrona de GPFS entre las ubicaciones para mantener actualizada toda la actividad de grabacin en disco en el clster. Esto incluye tanto las grabaciones en los espacios de tablas como las grabaciones en las anotaciones cronolgicas de transacciones. A alto nivel, un clster de GDPC puede ser similar al de la Figura "Clster de GDPC de alto nivel".

Figura 2. Clster de GDPC de alto nivel Diagrama que muestra cmo puede ser un clster de GDPC a alto nivel Las aplicaciones cliente que se conectan al clster de DB2 pureScale suelen tener habilitado el equilibrado de la carga de trabajo (WLB), que dirige de forma transparente el trabajo al miembro que tiene disponible ms capacidad. El equilibrado de la carga de trabajo mantiene un uso ptimo de los recursos durante el funcionamiento normal, y tambin redirige las conexiones en el caso de que haya un miembro inactivo (tanto si se ha planificado como si no) o que se produzca una anomala en la ubicacin. Los sistemas cliente, a menudo configurados como servidores de aplicaciones en un entorno de varios niveles, a menudo se configuran con redundancia entre las ubicaciones, con lo que tambin se proporciona tolerancia de errores en las capas superiores. La caracterstica de afinidad de cliente tambin puede utilizarse con los GDPC, si se desea dirigir determinadas peticiones de cliente a miembros ubicados fsicamente en una de las ubicaciones.

Tema principal: Introduccin a IBM DB2 pureScale Feature Conceptos relacionados: Infraestructura de GDPC y condiciones de requisito previo especficas de GDPC Concept topic http://www01.ibm.com/support/knowledgecenter/SSEPGG_10.1.0/com.ibm.db2.luw.licensing.doc/doc/c0 060596.html?lang=es