INSTITUTO TECNOLGICO DE

LZARO CRDENAS

ING. EN SISTEMAS COMPUTACIONALES

NOMBRE
RAMIREZ GALINDO EMMA
NMERO DE CONTROL:
12560418
GRUPO Y TURNO:
51 T

T/M

MATERIA:
ADMO. DE BASE DE DATOS
TAREA:
INVESTIGAR LA UNIDAD 2
CIUDAD LZARO CRDENAS MICHOACN, MAYO 2015

Unidad #2
Arquitectura del gestor
2.1 Caractersticas del DBMS
Los sistemas de administracin de bases de datos son usados para:
Permitir a los usuarios acceder y manipular la base de datos proveyendo
mtodos para construir sistemas de procesamiento de datos para
aplicaciones que requieran acceso a los datos.
Proveer a los administradores las herramientas que les permitan
ejecutar tareas de mantenimiento y administracin de los datos.
Algunas de sus caractersticas son:
Control de la Redundancia de Datos
Este consiste en lograr una mnima cantidad de espacio de almacenamiento para
almacenar los datos evitando la duplicacin de la informacin. De esta manera se
logran ahorros en el tiempo de procesamiento de la informacin, se tendrn
menos inconsistencias, menores costos operativos y har el mantenimiento ms
fcil.
Compartimiento de Datos
Una de las principales caractersticas de las bases de datos, es que los datos
pueden ser compartidos entre muchos usuarios simultneamente, proveyendo, de
esta manera, mxima eficiencia.
Mantenimiento de la Integridad
La integridad de los datos es la que garantiza la precisin o exactitud de la
informacin contenida en una base de datos. Los datos interrelacionados deben
siempre representar informacin correcta a los usuarios.
Soporte para Control de Transacciones y Recuperacin de Fallas
Se conoce como transaccin toda operacin que se haga sobre la base de datos.
Las transacciones deben por lo tanto ser controladas de manera que no alteren la
integridad de la base de datos. La recuperacin de fallas tiene que ver con la

capacidad de un sistema DBMS de recuperar la informacin que se haya perdido

durante una falla en el software o en el hardware.
Independencia de los Datos
En las aplicaciones basadas en archivos, el programa de aplicacin debe conocer
tanto la organizacin de los datos como las tcnicas que el permiten acceder a los
datos. En los sistemas DBMS los programas de aplicacin no necesitan conocer la
organizacin de los datos en el disco duro. Este totalmente independiente de ello.
Seguridad
La disponibilidad de los datos puede ser restringida a ciertos usuarios. Segn los
privilegios que posea cada usuario de la base de datos, podr acceder a mayor
informacin que otros.
Velocidad
Los sistemas DBMS modernos poseen altas velocidades de respuesta y proceso.
Independencia del Hardware
La mayora de los sistemas DBMS estn disponibles para ser instalados en
mltiples plataformas de hardware.
2.1.1 Estructura de Memoria y Procesos de la Instancia
Introduccin
Oracle utiliza la memoria para almacenar la siguiente informacin:

Cdigo del programa

Informacin acerca de una sesin conectada, incluso si no se encuentra
activa.
Informacin necesaria durante la ejecucin del programa(por ejemplo, el
estado de las consultas)
La informacin que comparten y con la cual se comunican los procesos
Oracle (por ejemplo, la informacin de bloqueo)
La Cach de Datos

La memoria se puede estructurar en las siguientes partes:

rea Global del sistema (SGA), la cual se comparte entre todos los
servidores y los procesos en segundo plano.

reas globales de programas (PGA), que es privada para cada servidor y

proceso en segundo planos; a cada proceso se asigna un PGA.
rea de Ordenaciones (Sort Areas).
Memoria Virtual
rea de cdigo de Software (SCA).

Figura 1. Estructura de la memoria en Oracle

rea Global del Sistema (System Global Area, SGA)
El rea Global del Sistema (SGA) es un grupo de estructuras de la memoria
compartida que contiene datos e informacin de control de una instancia de una
BD. Si varios usuarios se conectan de forma concurrente a la misma instancia,
entonces los datos se comparten en el SGA, por lo que tambin se llama shared
global area.
Una instancia en Oracle se compone de un SGA y de procesos. Cuando se crea
una instancia, Oracle asigna memoria a un SGA automticamente y esta se
devuelve al sistema operativo cuando la instancia se cierra. Por tanto, cada
instancia posee su propio SGA. Adems, es de lectura/escritura. Todos los
usuarios conectados a una instancia multiproceso pueden leer la informacin
contenida en el SGA de la instancia y varios procesos pueden escribir en l
durante la ejecucin.
Una parte del SGA contiene informacin general acerca del estado de la base de
datos y de la instancia, a la que los procesos en segundo plano necesitan acceder
(SGA fija), pero no se almacenan los datos de usuario. El SGA tambin incluye
informacin de comunicacin entre procesos, como la informacin de bloqueos.
Adems, si el sistema usa una arquitectura de servidor compartido, entonces las

colas de peticin y respuesta y algunos contenidos del PGA se encuentran en el

SGA.

El SGA contiene la siguiente estructura de datos:

Cach de los Buffers de la BD (Database Buffer Cache).

Buffer del Dietario o del Registro del Rehacer (Redo Log Buffer).
El Pool Compartido (Shared Pool).
Cach de Biblioteca.
Cach del Diccionario de Datos.
Estructuras de Control.
Informacin diversa

Instancia de una Base de Datos

Cada instancia Oracle est asociada a una base de datos. Cuando se inicia una
base de datos en un servidor (independientemente del tipo de ordenador), se le
asigna un rea de memoria (SGA) y lanza uno o ms procesos. A la combinacin
del SGA y de los procesos es lo que se llama instancia. La memoria y los procesos
de una instancia gestionan los datos de la base de datos asociada de forma
eficiente y sirven a uno o varios usuarios.

Figura 2. Estructura de una instancia de Oracle

La Instancia y la Base de Datos

Cuando se inicia una instancia Oracle monta la base de datos, es decir, asocia
dicha instancia a su base de datos correspondiente. En un mismo ordenador
pueden ejecutarse varias instancias simultneamente, accediendo cada una a su
propia base de datos fsica.
nicamente el administrador de la base de datos puede iniciar una instancia y
abrir una base de datos. Si una base de datos est abierta, entonces el
administrador puede cerrarla y, cuando esto ocurre, los usuarios no pueden
acceder a la informacin que contiene.
Estructura de Datos del SGA
Cach de los Buffers (Database Buffer Cache)
La cach de los buffers de la base de datos es una parte de la SGA que contiene
copias de los bloques de datos de lectura de las pginas. Todos los procesos de
los usuarios conectados concurrentemente a la instancia comparten el acceso a
ella. Esta cach junto con la cach compartida de SQL estn lgicamente
segmentadas en varios conjuntos, lo que reduce la contencin en sistemas
multiprocesador.
Organizacin de la Cach de los Buffers
Los buffers en la cach estn organizados en dos listas: la lista en espera y la lista
LRU. La lista en espera contiene los buffers en espera (dirty buffers), los cuales
contienen datos que han sido modificados pero que an no se han escrito en
disco. La lista LRU contiene los buffers libres, buffers que estn siendo accedidos
actualmente (pinned buffers) y los buffers en espera, que an no estn
almacenados en la lista en espera. Cuando un proceso Oracle accede a un buffer,
este lo sita al final de la lista LRU.
La primera vez que un proceso de usuario necesita un dato concreto, este los
busca en los datos almacenados en la cach de los buffers. Si el proceso
encuentra el dato en uno de estos buffers, se lee directamente de la memoria
(cache hit). Si no lo encuentra, entonces debe copiar la pgina en disco a un
buffer de la cach antes de leerlo (cache miss). Acceder a los datos a travs de
un cache hit es ms rpido que hacerlo mediante un cache miss.
Antes de leer un bloque de datos dentro de la cach, el proceso debe encontrar
primero un buffer libre, empezando desde el menos usado recientemente de la
lista LRU. El proceso sigue buscando hasta que encuentra un buffer libre o hasta
que llega al final de la lista.
El Algoritmo LRU y la Lectura Completa de Tablas

Cuando un proceso de usuario realiza una exploracin completa de la tabla, lee

cada bloque de la tabla en los buffers y los pone al final de la lista LRU. Se hace
as porque normalmente la exploracin completa se necesita brevemente, por lo
que los bloques deben sacarse rpidamente para dejar espacio en la cach a los
bloques que se usan con mayor frecuencia.
Tamao de la Cach de los buffer
Oracle soporta mltiples tamaos de bloque en una base de datos. El tamao
estndar de bloque se especifica mediante la configuracin del parmetro
DB_BLOCK_SIZE. Se admiten valores desde 2K hasta 32K.
Opcionalmente, tambin se puede seleccionar el tamao de dos pool de buffer
adicionales, KEEP y RECYCLE, configurando DB_KEEP_CACHE_SIZE y
DB_RECYCLE_CACHE_SIZE. Estos tres parmetros son independientes entre s.
Mltiples Pools de Buffer
Se puede configurar la cache del buffer con buffer pools distintos, en los que
cualquiera contiene datos, o estn disponibles para nuevos datos tras usar los
bloques de datos. Objetos particulares del esquema (tablas, clusters, ndices y
particiones) se asignan al buffer pool apropiado para controlar la forma en que los
bloques de datos envejecen en la cache.
El buffer pool KEEP conserva los bloques de datos de los objetos del
esquema en memoria.

El buffer pool RECYCLE elimina bloques de datos de la memoria tan

pronto como dejan de ser necesitados.

El buffer pool DEFAULT contiene bloques de datos de los objetos del

esquema que no son asignados a ningn buffer pool, as como los
objetos del esquema que son explcitamente asignados al pool DEFAULT.

Los parmetros que configuran los buffer pools KEEP y RECYCLE son
DB_KEEP_CACHE_SIZE y DB_RECYCLE_CACHE_SIZE.
Buffer del Registro del Rehacer (Redo Log Buffer)
El redo log buffer es un buffer circular en el SGA que contiene informacin sobre
cambios hechos a la base de datos, la cual se almacena en las entradas redo.
Estas entradas contienen la informacin necesaria para reconstruir, o rehacer
cambios hechos en la base de datos mediante las operaciones INSERT, UPDATE,

DELETE, CREATE, ALTER o DROP y se usan para la recuperacin de la base de

datos, si fuera necesario.
Las entradas se copian por los procesos desde el espacio de memoria del usuario
al redo log buffer en el SGA, ocupando continuamente espacio secuencial. El
proceso en segundo plano LGWR escribe el redo log buffer en el fichero redo log
activo (o grupo de ficheros) en disco.
El parmetro LOG_BUFFER determina el tamao (en bytes) del redo log buffer.
El Pool Compartido
Es la parte del SGA que contiene la cache de biblioteca, la cache de diccionario,
los buffers para los mensajes de ejecucin paralela y las estructuras de control.
El tamao total del Pool Compartido se determina por el parmetro
SHARED_POOL_SIZE. El valor por defecto es de 8MB en plataformas de 32-bit, y
de 64MB para plataformas de 64-bit. Incrementando su valor se incrementa la
cantidad de memoria reservada para el pool compartido.
Cach de Biblioteca (Library Cache)
La cache de biblioteca incluye reas de SQL compartidas, reas SQL privadas (en
caso de una configuracin de servidor compartido), procedimientos y paquetes
PL/SQL, y estructuras de control tales como bloqueos y el manejo de la cache de
biblioteca.
Ya que las reas de SQL compartidas son accesibles para todos los usuarios, la
cach de biblioteca est contenida en el Pool compartido dentro del SGA.
reas SQL Compartidas y reas SQL Privadas
Oracle representa cada declaracin de SQL con un rea SQL compartida y un
rea SQL privada. Oracle reconoce cuando dos usuarios estn ejecutando la
misma instruccin SQL y reutiliza el rea SQL compartida para esos usuarios. Sin
embargo, cada usuario debe tener una copia separada de la declaracin del rea
SQL privada.
reas SQL Compartidas
Un rea SQL Compartida contiene el rbol de anlisis y el plan de ejecucin para
una instruccin SQL dada. Se ahorra memoria usando un solo rea SQL
compartida para instrucciones SQL ejecutndose varias veces, lo cual ocurre con
frecuencia cuando varios usuarios ejecutan la misma aplicacin.

Programas PL/SQL y el Pool Compartido

Oracle procesa programas PL/SQL (procedimientos, funciones, paquetes, bloques
annimos, triggers) tanto como procesa instrucciones SQL individuales. Oracle
asigna un rea compartida que contiene la forma analizada y compilada del
programa. Asigna un rea privada para mantener los valores especficos de la
sesin que ejecuta el programa, incluyendo variables locales, globales y de
paquete y buffers para ejecucin SQL. Si ms de un usuario ejecuta el mismo
programa, entonces una simple rea compartida es usada por todos los usuarios
siempre que tenga una copia de su rea SQL privada, manteniendo valores
especficos de su sesin.
Las instrucciones SQL individuales estn contenidas en programas PL/SQL.
Large Pool
El administrador de la base de datos puede configurar un rea de memoria
opcional llamado large pool que proporciona grandes cantidades de memoria para
asignar:
Memoria de la sesin para el servidor compartido y el Oracle XA
interface (usado donde las transacciones interactan con ms de una base
de datos)

Procesamiento de E/S
Copias de seguridad y operaciones de recuperacin

El large pool satisface mejor las peticiones de gran cantidad de memoria que el
pool compartido. Sin embargo, no posee una lista LRU.
Java Pool
La memoria java pool se usa en la memoria del servidor para almacenar todo el
cdigo y datos del JVM en las sesiones. Se usa de diferentes formas,
dependiendo del modo en que se ejecute el servidor Oracle.
El asesor de estadsticas de java pool proporciona informacin sobre la memoria
de la cache de biblioteca usada para java y predice como pueden afectar cambios
en el tamao del java pool en la tasa de anlisis. El asesor de java pool se activa
internamente cuando el statistics_level est configurado en TYPICAL o mayor.
Estas estadsticas se reinician cuando el asesor es desactivado.
Streams Pool

En una nica base de datos, se puede especificar que los flujos de memoria se
asignen desde un pool en el SGA llamado Streams pool. Para configurarlo se
especifica el tamao del pool en bytes usando el parmetro
STREAMS_POOL_SIZE. Si un streams pool no est definido, entonces se crea
automticamente cuando los flujos se usan por primera vez.
Si SGA_TARGET est activo, entonces la memoria del SGA para los Streams pool
viene del pool global del SGA. Si no est activo, entonces se transfiere desde la
cache del buffer, aunque solo tiene lugar despus del primer uso de los flujos. La
cantidad transferida es del 10% del tamao del pool compartido.
Cach de Diccionario (Dictionary Cache)
El diccionario de datos es una coleccin de tablas y vistas de la base de datos que
contienen informacin sobre la base de datos (sus estructuras y sus usuarios.
Oracle accede con frecuencia al diccionario de datos, por lo que tiene dos
localizaciones especiales en memoria designadas a mantenerlo. Una de ellas es la
cach del diccionario de datos, tambin conocida como la cache de fila porque
contiene datos sobre las filas en vez de los buffers (los cuales contienen bloques
de datos), y la otra es el cache de biblioteca.
El Parmetro SGA_MAX_SIZE
El SGA comprende un nmero de componentes de memoria, denominados pools
de memoria, que se usan para satisfacer una clase particular de asignacin de
memoria. Todos los componentes del SGA asignan y liberan espacio en unidades
(mdulos). El tamao del mdulo queda determinado por el tamao total del SGA.
En la mayora de las plataformas el tamao del mdulo es 4MB si el tamao total
del SGA es menor de 1GB, y de 16MB para SGA mayores.
La base de datos puede configurar lmites sobre cuanta memoria virtual se usa
para el SGA. Puede crear instancias con un mnimo de memoria y permitir que la
instancia use ms, expandiendo la memoria asignada a los componentes del SGA,
hasta un mximo determinado por el SGA_MAX_SIZE. Si el valor es menor que la
suma de memoria asignada para todos los componentes, la base de datos ignora
la configuracin de SGA_MAX_SIZE.
Para un rendimiento ptimo, en la mayora de los sistemas, todo el SGA debera
ajustarse a la memoria real. Si no es as, y la memoria virtual es usada para
almacenar partes del SGA, entonces el rendimiento total del sistema puede
decrementarse en gran medida. La cantidad de memoria dedicada para todas las
reas compartidas en el SGA tambin influye en el rendimiento.

El tamao del SGA queda determinado por muchos parmetros, aunque son los
siguientes los que tienen un gran efecto sobre el tamao del SGA:

Parmetro

Descripcin

DB_CACHE_SIZE

Tamao de la cache de los bloques estndar.

LOG_BUFFER

Nmero de bytes asignados al redo log buffer.

SHARED_POOL_SIZE

Tamao en bytes para el rea dedicada al SQL

compartido e instrucciones PL/SQL.

LARGE_POOL_SIZE

Tamao del large pool, por defecto es 0.

JAVA_POOL_SIZE

Tamao del java pool.

Gestin Automtica de Memoria Compartida

En versiones anteriores el administrador de la base de datos tena que especificar
manualmente los tamaos de los diferentes componentes del SGA configurando
un nmero de parmetros de inicializacin, que incluan el SHARED_POOL_SIZE,
DB_CACHE_SIZE, JAVA_POOL_SIZE, y LARGE_POOL_SIZE. En la versin 10g
se incluye la gestin automtica de la memoria compartida que simplifica la
gestin de la memoria del SGA. El administrador de la BD puede simplemente
especificar la cantidad total de memoria del SGA disponible para una instancia
usando SGA_TARGET y la base de datos automticamente distribuir esta
memoria entre varios subcomponentes para asegurar el mayor uso de memoria
efectiva.
Cuando la gestin automtica de memoria del SGA esta activada, el tamao de los
diferentes componentes del SGA es flexible y pueden adaptarse a las necesidades
del trabajo sin requerir ninguna configuracin adicional. La base de datos
automticamente distribuye la memoria disponible entre varios componentes como
se requiera, permitiendo al sistema maximizar el uso de toda la memoria del SGA
disponible.

Configurando un nico parmetro se simplifica mucho la tarea de administracin

ya que puedes especificar solo la cantidad de memoria del SGA que una instancia
tiene disponible y olvidarte de los tamaos de los componentes individuales. No se
generan errores de out of memory a menos que el sistema se haya quedado sin
memoria.
La gestin automtica del SGA puede mejorar el rendimiento sin necesidad de
recursos adicionales ni ajustes manuales. Con la configuracin manual del SGA es
posible que instrucciones SQL compiladas se saquen del pool compartido debido a
su insuficiente tamao lo que incrementa la frecuencia de anlisis difciles, que
reducen el rendimiento. Cuando la gestin automtica del SGA esta activa, el
algoritmo de ajuste interno supervisa el rendimiento del trabajo, incrementando el
tamao del pool compartido si reduce el nmero de anlisis requeridos.
El Parmetro SGA_TARGET
El parmetro SGA_TARGET refleja el tamao total del SGA e incluye la
memoria para los siguientes componentes:

SGA Fija y otras asignaciones internas necesarias para la instancia.

El log buffer
El pool compartido
El Java pool
La cach del buffer
Las cachs de los buffers keep y recycle (si son especificados)
El tamao de los bloques no estndar de las cachs de los buffer (si son
especificados)
El Streams pool

Este incluye toda la memoria del SGA, en diferencia con las versiones anteriores
en las que la memoria para la SGA interna y fija se configuraba a travs de otros
parmetros. En consecuencia, el SGA_TARGET da un control preciso sobre el
tamao de la regin de memoria compartida asignada por la base de datos. Si
est configurado con un valor mayor que SGA_MAX_SIZE al inicio, entonces este
ltimo se usa como respaldo para el SGA_TARGET.
2.1.2 Estructuras Fsicas de la Base de Datos
reas Globales de Programas PGA (Program Global Areas)
Un rea global de programa (PGA) es una regin de memoria que contiene datos
e informacin de control para los procesos de servidores. Es una memoria no

compartida creada por Oracle cuando un proceso de un servidor es iniciado. Solo

el servidor del proceso puede acceder a l y se lee y escribe solamente por un
cdigo de Oracle que acta en nombre del proceso.
Contenido de un PGA
El contenido de la memoria de un PGA vara dependiendo de dnde se est
ejecutando la instancia y de si el tipo de servidor es compartido. Pero
generalmente la memoria del PGA puede ser clasificada de la siguiente forma:
Memoria de Sesin: La memoria de sesin (Session Memory) se asigna para
mantener las variables de una sesin (logon information) y otra informacin
relativa a la sesin. Para un servidor compartido, la memoria de sesin es
compartida y no privada.
rea SQL Privada: Un rea SQL privada contiene datos como por ejemplo
consultas de informacin de ejecuciones y consultas de ejecuciones en reas de
trabajo. Cada sesin que establece una sentencia tiene un rea privada de SQL.
Cada usuario que emite la misma sentencia tiene su propia rea SQL privada que
usa un rea SQL compartida. Aunque, muchas reas SQL privadas pueden ser
asociadas con la misma rea SQL compartida.
La ubicacin de un rea privada SQL depende del tipo de conexin establecida
para una sesin. Si una sesin se conecta a travs de un servidor dedicado, las
reas privadas SQL esta localizadas en el servidor del proceso del PGA. De
cualquier forma, si una sesin se conecta a travs de un servidor compartido,
parte del rea privada SQL se mantiene en el SGA.
Cursores y reas SQL
La aplicacin de desarrollo de un programa precompilador Oracle o un programa
OCI puede explcitamente abrir cursores, o manejar algn rea privada SQL
especfica, y usarla como un recurso nombrado a travs de la ejecucin de un
programa. Los cursores recursivos de Oracle que emiten implcitamente algunas
sentencias SQL tambin usan reas SQL.
La administracin de las reas SQL privadas son responsabilidad de los procesos
del usuario. La asignacin y liberacin de las reas SQL privadas dependen de en
qu herramienta de la aplicacin se usan, aunque el nmero de reas SQL
privadas que un proceso de usuario puede asignar est siempre limitado el
parmetro OPEN_CURSORS. El valor por defecto de este parmetro es 50.

Un rea SQL privada continua existiendo hasta que el correspondiente cursor es

cerrado o la sentencia es liberada. Aunque Oracle libera el rea de ejecucin
despus de que la sentencia se complete, el rea persistente se mantiene en
espera. Las aplicaciones de desarrollo cierran todos los cursores abiertos que no
van a ser usados otra vez para liberar el rea persistente y minimizar la cantidad
de memoria requerida por el usuario de la aplicacin.
Componentes del rea SQL Privada
El rea SQL privada de un cursor se divide en 2 reas cuya duracin son
diferentes:
El rea persistente (Persistent Area), que contiene, por ejemplo,
informacin envuelta. Es liberada solamente cuando el cursor es cerrado.

El rea de ejecucin (Run-time Area), que es liberada cuando la

ejecucin, valga la redundancia, es terminada.

Oracle crea el rea de ejecucin en el primer paso que una ejecucin es pedida.
Para una sentencia INSERT, UPDATE y DELETE Oracle libera el rea de
ejecucin despus de que la sentencia ha sido ejecutada. Para las consultas,
Oracle libera el rea de ejecucin solamente cuando todas las filas han sido
recorridas, o la consulta ha sido cancelada.
reas de Trabajo SQL
Para las consultas complejas, una gran porcin del rea de ejecucin es dedicada
a reas de trabajo asignadas por operadores de memoria-intensiva como los
siguientes:
Operadores de base de clasificacin Sort-based (order by, group by,
rollup)

Hash-join
Bitmap merge
Bitmap create

Por ejemplo, un operador de clasificacin (sort operator) usa un rea de trabajo

(algunas veces llamado rea de clasificacin sort area) para la forma de
distribucin de la memoria interna (in-memory) de una serie de filas. Similarmente,
un operador hash-join usa un rea de trabajo (tambin llamada rea hash) para
construir una tabla hash desde su entrada izquierda. Si la cantidad de datos que
deben ser procesados por estos dos operadores no entran en el rea de trabajo,
entonces los datos de entrada son divididos en piezas ms pequeas. Esto

permite que alguna de las piezas se procesen en la memoria mientras el resto son
distribuidos en un disco temporal para ser procesado luego. Aunque los
operadores de bitmap no se distribuyen por el disco cuando su rea de trabajo es
muy pequea, su complejidad es inversamente proporcional al tamao de su rea
de trabajo. Estos operadores se ejecutan ms rpido en reas de trabajo ms
grandes.
Administracin de la Memoria del PGA para un Modo Dedicado
Se puede administrar el tamao de las reas de trabajo SQL globalmente y
automticamente. El administrador de la base de datos simplemente necesita que
sea especificado el tamao total dedicado a la memoria del PGA para las
instancias de configurando el parmetro PGA_AGGREGATE_TARGET. El nmero
especificado (por ejemplo 2G) es un objetivo global para la instancia, y se trata de
asegurar que la cantidad total de memoria del PGA asignada por toda la base de
datos de los procesos del servidor nunca exceda esa meta.
Con PGA_AGGREGATE_TARGET, modificar el tamao de las reas de trabajo
para todas las sesiones dedicadas es automtico, y todos los parmetros
*_AREA_SIZE se ignoran en estas sesiones.
rea de Ordenaciones (Sort Areas)
Las reas de ordenaciones (Sort Areas) de Oracle son las zonas de memoria en
las que se ordenan los datos, es decir el espacio en memoria que necesita la
organizacin y ordenacin de las filas.
El tamao por defecto, expresado en bytes, es especfico de cada SO. Sin
embargo, hay muchas razones importantes por las que este tamao influye en el
rendimiento. En el manual de Oracle 10i encontramos cuatro de ellas:

Aumentar el SORT_AREA_SIZE mejora la eficiencia de ordenaciones

grandes.
Cada ordenacin en una consulta puede consumir la cantidad de
memoria especificada en el SORT_AREA_SIZE, y pueden haber
mltiples ordenaciones en una consulta. De esta forma, si otra consulta
se ejecuta en paralelo, cada ordenacin puede consumir la memoria
especificada en este campo.
El SORT_AREA_SIZE tambin se utiliza para selecciones y
actualizaciones en los ndices de las tablas. Seleccionar un valor
apropiado aqu, puede dar como resultado que la tabla se actualice una
nica vez en cada operacin DML, pudiendo incluso haber cambiado
varias filas a la vez.

Grandes valores en este campo nos permitirn realizar mayores

bsquedas en memoria. Si se necesitase ms espacio para la ordenacin
del que tenemos, los datos se dividirn en trozos y se utilizarn
segmentos de disco temporales como apoyo en la ordenacin.

En ste ltimo caso, en el que los datos a ordenar no quepan en el rea de

ordenaciones, se dividen en trozos que s quepan, se ordenan y se mezclan
(merge). A esto hace referencia tambin el manual de Oracle9i, que si bien lo hace
en trozos separados, a continuacin se muestran las dos referencias juntas:

Para un mejor rendimiento del SGBD, la mayora de las ordenaciones

deberan tener lugar nicamente en memoria ya que en caso de tener que
escribir a disco, obtendremos un claro efecto adverso sobre ste. Si las
aplicaciones que acceden a la base de datos suelen realizar bsquedas
que no caben en el rea de ordenaciones, o incluso si las aplicaciones
realizan demasiadas bsquedas innecesarias, entonces sera conveniente
modificar el parmetro de SORT_AREA SIZE.

El SORT_AREA_SIZE es un parmetro que se puede

inicializar y modificar dinmicamente y que especifica la cantidad de memoria que
se tiene disponible al realizar las ordenaciones. Si una cantidad importante de
ordenaciones requiere acceso a disco para almacenar segmentos temporales,
entonces la aplicacin se ver claramente beneficiada al ampliar el
SORT_AREA_SIZE. De forma alternativa, en un entorno DSS, aumentar este
parmetro no tiene por qu hacer que la ordenacin se realice nicamente en
memoria, pero s es cierto que dependiendo del valor actual y del nuevo elegido,
se puede aumentar drsticamente la velocidad de la ordenacin.

Por lo tanto, como conclusin, alterar este parmetro, se puede considerar

como un paso importante para asegurarnos el rendimiento en ciertas
circunstancias y situaciones. Sin embargo, determinar qu valor es el ms
apropiado, es por supuesto, la parte ms complicada.
Memoria Virtual en Oracle
Oracle puede utilizar la memoria virtual proporcionada por el SO para simular
memoria a base de algn dispositivo de almacenamiento como el disco duro.
La memoria virtual est mapeada en la RAM. Cuando no hay suficiente
memoria con sta para ejecutar los programas (en caso de Oracle las sentencias,
bsquedas, etc) se necesita un espacio auxiliar que normalmente suele ser el
disco duro. Para el traspaso de informacin se utilizan dos tcnicas principales: el
Paging o paginacin y el Swapping.

Paginacin
La paginacin consiste en dividir los programas en pequeos bloques o
pginas, de manera que sea ms fcil moverlos de memoria a disco y viceversa.
De la misma forma, la memoria se divide en marcos de pgina. De esta forma, la
cantidad de memoria desperdiciada por un proceso es el final de su ltima pgina,
minimizando as la fragmentacin interna y evitando la externa.
En un momento cualquiera, la memoria se encuentra ocupada con pginas de
diferentes procesos, mientras que algunos marcos estn disponibles para su uso.
El sistema operativo mantiene una lista de estos ltimos marcos, y una tabla por
cada proceso, donde consta en qu marco se encuentra cada pgina del proceso.
De esta forma, las pginas de un proceso pueden no estar contiguamente
ubicadas en memoria, y pueden intercalarse con las pginas de otros procesos.
En la tabla de pginas de un proceso, se encuentra la ubicacin del marco que
contiene a cada una de sus pginas. Las direcciones lgicas ahora se forman
como un nmero de pgina y de un desplazamiento dentro de esa pgina
(conocido comnmente como offset). El nmero de pgina es usado como un
ndice dentro de la tabla de pginas, y una vez obtenida la direccin del marco de
memoria, se utiliza el desplazamiento para componer la direccin real o direccin
fsica. Este proceso se realiza en una parte del ordenador especficamente
diseada para esta tarea, es decir, es un proceso hardware y no software.
De esta forma, cuando un proceso es cargado en memoria, se cargan todas sus
pginas en marcos libres y se completa su tabla de pginas.
Swapping
El Swapping es el procedimiento de mover los bloques de memoria en los que
estn algunos procesos que no se estn utilizando, desde la memoria principal a
un espacio Swap dejando as hueco libre para poder cargar en memoria otros
procesos que s se van a utilizar.
El espacio Swap o espacio de intercambio es una zona de disco (un fichero o
una particin) que se usa para guardar las imgenes de los procesos que no han
de mantenerse en memoria fsica.
Este procedimiento es muy similar a la paginacin, con la diferencia principal de
que el directorio Swap funciona exactamente igual que la memoria RAM, por lo
que puede almacenar datos privados, contraseas y todo lo que almacena sta.
Sin embargo, en la paginacin, nicamente se sacan de memoria pginas
pertenecientes a procesos que no se estn utilizando, adems de que se pueden

sacar solo algunas pginas de los procesos y no stos enteros como se hace en el
Swapping.
Con respecto al tamao que debe tener el directorio Swap, hay muchas
discusiones sobre ello como por ejemplo la antigua creencia de El Swap debe
tener el doble de tamao que la RAM. cosa que no es vlida hoy da debido a la
gran capacidad de la memoria RAM de la mayora de ordenadores.
Como conclusin, hay que destacar que el uso de la memoria virtual por parte
de Oracle, va a influir bastante en el rendimiento, disminuyndolo drsticamente
en comparacin con el uso nicamente de la memoria RAM.
rea de Cdigo de Software (Sca)
El rea de cdigo de software son zonas de memoria destinadas a almacenar el
cdigo de Oracle en ejecucin o que puede ejecutarse. Este cdigo de Oracle se
almacena en una zona distinta, y ms protegida, que las zonas dedicadas a
almacenar los cdigos de programas de usuarios.
La SCA suele ser de tamao esttico, cambiando nicamente cuando el
software se reinstala o actualiza. El tamao requerido para este rea puede variar
en funcin del SO. Son reas de slo lectura y pueden ser instalas de forma
compartida o no compartida. Cuando es posible, el cdigo de Oracle se comparte,
por lo que todos los usuarios pueden acceder a l sin tener mltiples copias en
memoria. El resultado es un ahorro considerable de memoria y una mejora del
rendimiento general.
Por otra parte, los programas de usuario tambin pueden ser compartidos o no.
Algunas utilidades y herramientas de Oracle (como ocurre con Oracle Forms y
SQL*Plus) pueden ser instalados de forma compartida, pero otras no. Mltiples
instancias de Oracle pueden usar la misma SCA con diferentes bases de datos si
estn corriendo en la misma mquina.
Hay que tener en cuenta que la opcin de instalar software compartido puede
no estar disponible en funcin del sistema operativo, como ocurre por ejemplo en
mquinas con Windows.
Estructura de los Procesos
Cuando un usuario se conecta a una base de datos de Oracle ejecuta dos
mdulos de cdigo diferentes, que adems el encargado de gestionar estos
procesos es el sistema operativo, estos dos mdulos diferentes son:

 Aplicacin o Herramienta Oracle: normalmente son programas

clientes que se conectan a la base de datos y permiten ejecutar sentencias SQL.
Ej.: SQL*Plus, SQL developer
Cdigo del Servidor de Oracle: son los diferentes procesos que
se han de ejecutar en el servidor para atender las peticiones del usuario.
La base de datos Oracle es un sistema multiproceso, lo que significa que no
toda la base de datos est corriendo en un mismo proceso, si no que varias partes
de la base de datos se ejecuta concurrentemente. Permitiendo a mltiples
usuarios conectarse a la misma vez, y mayor rapidez en el tiempo de respuesta,
puesto que siempre que pueda va a utilizar al mximo al ordenador, por ejemplo si
tiene ocho ncleos el servidor, y resulta que una peticin se puede paralelizar se
ejecutara esa peticin por partes en cada ncleo.
De los procesos que se ejecutan en el servidor podemos hacer dos grandes
grupos:
Procesos de Usuarios: Cada vez que un usuario ejecuta una aplicacin, ya
sea propia o de Oracle se crea un proceso, que puede ser de dos tipos.
Conexin: Que es la va de comunicacin entre la aplicacin y la
instancia de la base de datos a la que se ha conectado.
Sesin: Es la conexin especfica con la base de datos
proporcionando un usuario y su contrasea.
Esto permite que desde un mismo equipo se puedan conectar varios usuarios
simultneamente, y que un usuario se pueda conectar desde diferentes equipos
simultneamente.
Procesos de Oracle: Son propios de la base de datos, y el usuario no tiene
control sobre ellos, pueden ser de dos tipos:
Procesos de Servidor: Se crea cuando una aplicacin intenta acceder a la base
de datos, para atender a las peticiones de la aplicacin y devolver los resultados
que se precisen.
Procesos de Background: Se crean cuando se inicia una instancia de la base
de datos, solo hay un proceso de cada tipo de los que especificaremos a
continuacin, y no han de estar todos siempre presentes en el servidor. Se utilizan
para realizar labores de mantenimiento, y para guardar la integridad de la base de
datos. Los diferentes tipos de procesos son los siguientes:

Database Writer Process (DBWn)

El (DBWn) escribe el contenido de los buffers en los archivos de datos. El proceso
DBWn es responsable por la escritura de los buffers modificados del buffer cache
al disco. El proceso DBWn escribe buffers modificados al disco bajo las siguientes
condiciones:
Cuando un proceso no puede encontrar un buffer limpio reusable despus de
haber recorrido un nmero de determinado de buffers en el buffer cach, ste
enva una seal al DBWn para la escritura. El DBWn escribe los buffers sucios al
disco.
El DBWn peridicamente escribe los buffers cuando se lleva a cabo un checkpoint.
Chekpoint es una posicin en el hilo de redo (log) donde se iniciar luego la
recuperacin. La posicin en el log est determinada por el ltimo buffer sucio en
el buffer cach.

Log Writer Process (LGWR)

El proceso LGWR es responsable del manejo del redo log buffer, las escrituras del
redo log buffer al archivo de redo log en el disco. El LGWR escribe todos los
registros de redo que han sido copiados en el buffer desde la ltima vez que ste
se escribi. El redo log buffer es un buffer circular. Cuando LGWR escribe los
registros del redo log buffer al redo log file, el proceso servidor puede copiar
nuevos registros sobre aquellos que se pasaron a disco. LGWR normalmente
escribe lo suficientemente rpido para asegurar que el espacio est siempre
disponible en el buffer para nuevos registros, aun cuando la escritura al redo log
file sea lenta.
LGWR escribe en porciones contiguas del buffer al disco. El LGRW escribe:
Un registro de commit cuando un usuario hace commit de una
transaccin
Redo log buffers:

Cada tres segundos

Cuando el redo log tenga un tercio lleno

 Cuando un proceso de DBWn escriba los buffers modificados a

disco, si es necesario.
Cuando un usuario lleva a cabo una instruccin de commit, el LGWR coloca el
registro de commit en el log buffer y escribe la transaccin a disco inmediatamente
en el redo log. Los cambios correspondientes a los bloques de datos en el buffer
cach, son dejados hasta que se tenga una escritura ms eficiente que hacer.
Esto se denomina el mecanismo de fast commit. La escritura de un registro de
redo del commit de la transaccin es un evento atmico.
Existe un mito con respecto a la escritura en el redo log buffer, se dice que en el
redo log buffer o redo log file aparecern slo las transacciones comprometidas.
En el redo log file se escriben todas las transacciones, no slo las comprometidas,
es por ello que el redo log permite rehacer los segmentos de undo del cualquier
punto en el tiempo cuando se hace recuperacin incompleta (point in time
recovery).
Redo Log Files
Los Redo Log Files se agrupan en grupos de Redo Log. Todos los miembros de
un Redo Log Group son idnticos, es decir contendrn la misma informacin.
Dentro de un grupo de Redo Log se "multiplexan" los archivos para evitar los
puntos de fallas, es decir si se perdiera un archivo de Redo Log habra otro que
contendra la informacin y que permitiera la recuperacin de la base de datos.
Los redo log se utilizan de forma circular, mediante grupos de archivos. Por
defecto la base de datos Oracle genera 3 grupos de archivos. Se considerar el
grupo current (actual) aquel donde se est utilizando para escribir las
transacciones actuales de la base de datos. Se considera un grupo active (activo),
aquel que no es el actual y que posea transacciones cuyos cambios no se han
hecho permanentes en los archivos de datos e inactivo aquel que contenga
transacciones que han sido completamente escritas a disco, finalmente tambin se
puede tener que un grupo de redo log est limpio porque nunca haya sido escrito.
Los archivos de redo log trabajan de forma circular porque se sobrescriben,
generalmente con los tres grupos se tendr que uno de ellos se encontrar activo,
el siguiente en enumeracin ser el actual y el siguiente estar inactivo listo para
que se escriba en l. Una vez llenado el grupo actual se comenzar a escribir en
el inactivo, que ahora ser el actual, el que anteriormente era el actual pasar a
ser activo si an no se han escrito todas sus transacciones a disco y
eventualmente el que inicialmente estaba activo pasar a ser inactivo y permitir
que al llenarse el grupo actual se escriban las transacciones en l.

Si se llenara el grupo actual de los archivos de redo y el resto de los grupos se

encontraran activos, la base de datos no permitira ninguna transaccin hasta que
se escriban todas las transacciones a disco del siguiente grupo de redo log y que
este quedase inactivo. Cuando se trabaja con una base de datos en modo
ARCHIVELOG, antes de sobrescribir el archivo se hace una copia de ese grupo
de redo log al destino de los archivos.
Checkpoint Process (CKPT)
El CKPT lleva a cabo un checkpoint, entendindose como tal a la escritura parcial
o completa de los buffers de memoria a disco. El CKPT no es el responsable de
escribir los bloques a disco, para ello llama al DBWn y como en esa escritura
podran almacenarse en disco buffers de transacciones no comprometidas el
CKPT tambin llama al LGWR para que registre en los redo log files esta escritura
que permita generar los segmentos de undo de transacciones no comprometidas
cuando se realice una recuperacin incompleta. Tambin si en la escritura del
checkpoint hay transacciones que no se haban terminado de escribir en disco se
escriben, se actualiza la cola de transacciones activas y un grupo de redo log que
estaba activo podra pasar a inactivo.
Cuando un checkpoint ocurre, Oracle debe actualizar todas las cabeceras de los
archivos de datos con los detalles del checkpoint, sta es una tarea del CKPT.
System Monitor Process (SMON)
El proceso SMON lleva a cabo la recuperacin, si es necesaria, de la instancia en
el inicio de la misma, es decir rehacer cualquier transaccin comprometida en el
redo log file que no haya sido escrita a disco. SMON tambin es responsable de
limpiar los segmentos temporales que no estn en uso por algn tiempo y de
desfragmentar si cree oportuno alguna zona de los discos.
Process Monitor (PMON)
PMON lleva a cabo procesos de recuperacin cuando un proceso de usuario falla.
Es responsable de la limpieza del buffer cach, tambin de deshacer los cambios
que se hayan hecho desde el ultimo commit y de la liberacin de recursos que el
proceso estaba usando. Por ejemplo este restaura el status de la tabla de
transacciones activas, libera los locks y remueve el ID del proceso de la lista de
procesos activos, asociados a un proceso usuario que pudo haber perdido la
conexin de red.
Recoverer (RECO)

Este proceso solo se observa cuando la base de datos ejecuta la opcin

distribuida de Oracle. La transaccin distribuida es una en la que dos o ms
emplazamientos de datos deben mantenerse sincronizados, Por ejemplo cuando
se tiene una copia de los datos en diferentes ciudades y por fallas en una lnea
telefnica se pierde una transaccin en la mitad de su actualizacin. El proceso
recuperador entonces resuelve las transacciones que hayan quedado
inconsistentes en las dos ciudades.
Archiver Processes (ARCn)
El ARCn copia los archivos de redo log llenos a un espacio de almacenamiento
distinto para no perderlos al ser sobreescritos. El ARCn slo est habilitado
cuando la base de datos est en el modo ARCHIVELOG. En Oracle 10g para
colocar la base de datos en modo archive basta con colocarla en modo
ARCHIVELOG y especificar los destinos de "archive". En Oracle 9i se distingua
entre el "archive" manual y automtico. Con "archive" manual el DBA deba
ordenar hacer la copia de los redo log a los "archives", en el modo automtico se
copiaban automticamente antes de ser sobrescritos. En Oracle 10g al poner una
base de datos en modo ARCHIVELOG automticamente se coloca en el modo
automtico.

Lock (LCKn)
Es un proceso opcional, configurado para manejar los bloqueos entre bases de
datos Oracle cuando estas se encuentran en distintos computadores y
compartiendo el mismo conjunto de discos (es decir en modo servidor en
paralelo).
Job Queue (SNPn)
Es un proceso opcional, que se encarga de planificar los procesos que se deben
ejecutar y asegurar que todos deben de terminar en algn momento.
Queue Monitor (QMNn)
QMNn es un proceso opcional de background para el encolamiento avanzado de
Oracle, que monitorea las colas de mensajes. El encolamiento avanzado se usa

con comunicacin asncrona. Los procesos envan los mensajes y en lugar de

esperar por la respuesta siguen con su trabajo.
Dispatcher (Dnnn)
Es un proceso opcional que permite a los usuarios compartir procesos de servidor.
Permitiendo que se conecten mltiples usuarios al mismo servidor.
Shared Server (Snnn)
Este tipo de proceso se encarga de atender a cada uno de los clientes conectados
a la base de datos compartiendo los procesos del servidor.
2.1.3 Requerimientos para Instalacin de la Base de Datos
Antes de instalar cualquier SGBD es necesario conocer los requerimientos de
hardware y software, el posible software a desinstalar previamente, verificar el
registro de Windows y el entorno del sistema, as como otras caractersticas de
configuracin especializadas como pueden ser la reconfiguracin de los servicios
TCP/IP y la modificacin de los tipos archivos HTML para los diversos
navegadores.
Se presenta a continuacin una serie de requerimientos mnimos de hardware y
software para instalar oracle 11g Express y MySQL estndar versin 5.1. En
Windows Seven y Ubuntu 10.

Requerimiento

RAM

Memoria virtual

Oracle

512 MB

1024
MB

MySQL

512 MB

1024 MB

Espacio disco duro

1.5 GB

1 GB

Tamao mximo de la base de datos

4 GB

Sin limite

Requerimiento

Oracle

MySQL

Sistema Operativo: Windows Server, Windows

Seven, Linux, Unix

Arquitectura del Sistema 32/64-bit

Protocolo de red TCP/IP

Protocolo de red TCP/IP con SSL

La regla general para determinar el tamao de la memoria virtual depende del

tamao de memoria RAM instalada. Si su sistema tiene menos de 4 GB de RAM
por lo general el espacio de intercambio debe ser de al menos dos veces este
tamao. Si usted tiene ms de 8 GB de memoria RAM instalada puede considerar
usar el mismo tamao como espacio de intercambio. Cuanta ms memoria RAM
tenga instalada, es menos probable usar el espacio de intercambio, a menos que
tenga un proceso inadecuado.
2.1.4 Instalacin del Software de Base de Datos en ModoTransaccional
Debido al constante crecimiento de datos que generan las empresas hoy en da,
se ha vuelto muy necesaria la bsqueda de nuevas plataformas para almacenar y
analizar la informacin, ambientes que consuman menos recursos, que sean ms
escalables y que provean una alta disponibilidad. La solucin consiste en el
procesamiento paralelo de los datos de una base de datos.
Una base de datos en modo transaccional significa que la BD ser capaz de que
las operaciones de insercin y actualizacin se hagan dentro de una transaccin,
es un componente que procesa informacin descomponindola de forma unitaria

en operaciones indivisibles, llamadas transacciones, esto quiere decir que todas

las operaciones se realizan o no, si sucede algn error en la operacin se omite
todo el proceso de modificacin de la base de datos, si no sucede ningn error se
hacen toda la operacin con xito.
Una transaccin es un conjunto de lneas de un programa que llevan insert o
update o delete. Todo aqul software que tiene un log de transacciones (que es la
"bitcora" que permite hacer operaciones de commit o rollback), propiamente es
un software de BD; aqul que no lo tiene (v.g. D-Base), propiamente no lo es. Todo
software de base de datos es transaccional; si el software de la BD no es
"transaccional", en realidad NO es un "software" de BD; en todo caso, es un
software que emula el funcionamiento de un verdadero software de BD. Cada
transaccin debe finalizar de forma correcta o incorrecta como una unidad
completa. No puede acabar en un estado intermedio.
Se usan los siguientes mtodos:

Begin TRans para iniciar la transaccin

CommitTrans para efectuar los cambios con xito

RollbackTrans para deshacer los cambios

Y depende que base de datos uses para efectuar las operaciones pero, es la
misma teora para cualquier BD.
Instalacin de MySQl en Windows 7
1. Comprobar que no existe una versin anterior, si existe desinstalarla.
2. Descargar el archivo de instalacin, en nuestro caso MySQL Enterprise.
3. Ejecute el archivo:

4. Procesa a instalar en el modo por defecto. Es necesario tener conexin a

Internet
5. Configure el servidor segn sus necesidades

6. Es este punto se configura como se comportar nuestro servidor y el

servicio. Adems se descargan e instalan los paquetes necesarios.

7. Ahora proceda a configurar MySQL Workbench; es una herramienta

visual de diseo de bases de datos que integra desarrollo de software,
administracin de bases de datos, diseo de bases de datos, creacin y
mantenimiento para el sistema de base de datos MySQL. Es el sucesor de
DBDesigner 4 de fabFORCE.net, y reemplaza el anterior conjunto de
software, MySQL GUI Tools Bundle.
En MySQL 5.x se soporta por defecto el modo transaccional mediante el motor
InnoDB
Dos recursos basados en disco muy importantes que gestiona el motor de
almacenamiento InnoDB son sus archivos de datos de espacios de tablas y sus
archivos de registro (log).
Si no se especifican opciones de configuracin para InnoDB, MySQL 5.0 crea en
el directorio de datos de MySQL un archivo de datos de 10MB (autoextensible)
llamado ibdata1 y dos archivos de registro (log) de 5MB llamados ib_logfile0 e
ib_logfile1.
2.1.5 Variables de Ambiente y Archivos Importantes para Instalacin
Variable: Es un espacio en memoria al cual se le da un nombre Hay variables
especficas que se crean al momento de entrar al sistema, pero tambin hay
variables que pueden ser definidas por el usuario. Las variables son una forma de
pasar informacin a los programas al momento de ejecutarlos.

Variables de Ambiente: Se usan para personalizar el entorno en el que se

ejecutan los programas y para ejecutar en forma correcta los comandos del shell.
Toman su valor inicial generalmente de un archivo .profile, pero hay veces en que
el usuario tiene que modificar los valores de alguna variable de ambiente cuando
est tratando de instalar o ejecutar un nuevo programa
A continuacin se comentan las opciones ms utilizadas de la seccin mysqld
(afectan al funcionamiento del servidor MySQL), se almacenan en el archivo
my.cnf (o my.ini)
basedir = ruta: Ruta a la raz MySQL
console: Muestra los errores por consola independientemente de lo que se
configure para log_error.
datadir = ruta: Ruta al directorio de datos.
default-table-type = tipo: Tipo de la Tabla InnoDB o, MyISAM.
flush: Graba en disco todos los comandos SQL que se ejecuten (modo de trabajo,
sin transaccin).
general-log = valor: Con valor uno, permite que funcione el archivo LOG para
almacenar las consultas realizadas.
general-log-file = ruta: Indica la ruta al registro general de consultas.
language: Especifica el idioma de los lenguajes de error, normalmente esots
archivos de lenguaje, estn bajo /usr/local/share.
log-error = ruta: Permite indicar la ruta al registro de errores.
log = ruta: Indica la ruta al registro de consultas.
long-query-time = n: Segundos a partir de los cuales una consulta que tardes
ms, se considerar una consulta lenta.
og-bin = ruta: Permite indicar la ruta al registro binario.
pid-file = ruta: Ruta al archivo que almacena el identificador de proceso de
MySQL.
port = puerto: Puerto de escucha de MySQL.

skip-grant-tables: Entra al servidor saltndose las tablas de permisos, es decir

todo el mundo tiene privilegios absolutos.
skip-networking: El acceso a MySQL se har solo desde el servidor local.
slow-query-log = 0|1: Indica si se hace LOG de las consultas lentas.
slow-query-log-file = ruta: Ruta al archivo que hace LOG de las consultas lentas.
socket = ruta: Archivo o nombre de socket a usar en las conexiones locales.
standalone: Para Windows, hace que el servidor no pase a ser un servicio.
user = usuario: Indica el nombre de usuario con el que se iniciar sesin en
MySQL.
tmpdir = ruta: Ruta al directorio para archivos temporales.
Archivos LOG en MySQL
Hay cuatro registros (logs):
Registro de Errores (Error Log): Indica cuando arranc y se detuvo el servidor.
Se graba por defecto en la carpeta de datos de MySQL (archivo host_name.err,
donde host_name es el nombre del servidor), pero la variable de sistema log_error
permite indicar otra ruta si fuera necesario.
Registro General de Consultas (General Log File): Est en la carpeta de datos
de MySQL, salvo que se indique la variable general-log-file. Contiene las consultas
realizadas. Es el archivo host_name.log.
Registro Binario (Binary Log): Registra instrucciones DML. Los archivos binarios
se almacenan por defecto en el directorio de datos. Sirve para intentar restaurar
una base de datos en caso de desastre. Es binario, por lo que su manejo es
complicado, para ver el contenido se usa la utilidad mysqlbinlog de esta forma:
mysqlbinlog archivoLOG
Registro de Consultas Lentas (Slow Query Log File): Registra las consultas
que tardaron ms del tiempo mnimo establecido. El archivo est (salvo quese
especifique slow-log-file como parmetro) en la carpeta de datos de MySQL con el
nombre host_name-slow.log

2.1.6 Procedimiento General de Instalacin de un DBMS

MySQL Enterprise Edition
MySQL Enterprise Edition incluye el conjunto ms completo de caractersticas
avanzadas y herramientas de gestin para alcanzar los ms altos niveles de
escalabilidad, seguridad, fiabilidad y tiempo de actividad. Reduce el riesgo, costo y
complejidad en el desarrollo, implementacin y administracin de aplicaciones
crticas de negocio MySQL.
El MySQL Enterprise incluye las siguientes opciones:
Backup: Realiza copias de seguridad de bases de datos MySQL en lnea, de los
subconjuntos de tablas InnoDB, y la recuperacin mediante puntos de
restauracin.
Alta Disponibilidad: es proporcionada con soluciones certificadas que incluyen
replicacin de MySQL.
Escalabilidad: permite alcanzar el rendimiento sostenido y la escalabilidad de
cada vez mayor de usuarios, consulta, y las cargas de datos
MySQL Enterprise Security: Proporciona listas para utilizar los mdulos de
autenticacin externos para integrar fcilmente las infraestructuras existentes de
seguridad, incluyendo Pluggable Authentication Modules y el directorio activo de
Windows
MySQL Enterprise Monitor: supervisa continuamente su base de datos y de
forma proactiva le asesora sobre cmo implementar las mejores prcticas de
MySQL, incluyendo consejos y alertas de seguridad
MySQL Query Analyzer: Mejora el rendimiento de las aplicaciones mediante el
control de rendimiento de las consultas y precisa localizacin de cdigo SQL que
est causando una desaceleracin
MySQL Workbench: Cuenta con ofertas de modelado de datos, desarrollo de
SQL y herramientas de administracin integral para la administracin del servidor
de configuracin del usuario, y mucho ms.
El proceso de instalacin es muy simple y prcticamente no requiere intervencin
por parte del usuario.
Comienza el proceso; slo nos llevar un par de minutos

Cada vez que veo la pantalla de la GNU GPL me lleno de felicidad. No slo por las
condiciones y el precio: es adems, para m, una garanta de profesionalidad.

Estadsticamente, la instalacin tpica ser la que mejor se adapte a tus

necesidades.

Todo listo; presiona Install cuando quieras.

Una vez instalado MySQL, la siguiente fase es la configuracin del servidor en s

mismo. Asegrate de que la marca Launch the MySQL Instance Configuration
Wizard est activa.

2.1.7 Procedimiento para Configuracin de un DBMS

Para configurar nuestro DBMS podemos acceder a las siguientes pantallas, para
Oracle o MySQL.
El esquema de una base de datos (en ingls, Database Schema) describe la
estructura de una Base de datos, en un lenguaje formal soportado por un Sistema
administrador de Base de datos (DBMS). En una Base de datos Relacional, el
Esquema define sus tablas, sus campos en cada tabla y las relaciones entre cada
campo y cada tabla.
Oracle generalmente asocia un 'username' como esquemas en este caso
SYSTEM y HR (Recursos humanos).
Por otro lado MySQL presenta dos esquemas information_schema y MySQL
ambos guardan informacin sobre privilegios y procedimientos del gestor y no
deben ser eliminados.

Optamos por Detailed Configuration, de modo que se optimice la configuracin del

servidorMySQL.

Ha llegado un momento crucial. Dependiendo del uso que vayamos a darle a

nuestro servidor deberemos elegir una opcin u otra, cada una con sus propios
requerimientos de memoria. Puede que te guste la opcin Developer Machine,
para desarrolladores, la ms apta para un uso de propsito general y la que
menos recursos consume. Si vas a compartir servicios en esta mquina,
probablemente Server Machine sea tu eleccin o, si vas a dedicarla
exclusivamente como servidor SQL, puedes optar por Dedicated MySQL Server
Machine, pues no te importar asignar la totalidad de los recursos a esta funcin.

De nuevo, para un uso de propsito general, te recomiendo la opcin por defecto,

Multifunctional Database.

InnoDB es el motor subyacente que dota de toda la potencia y seguridad

a MySQL. Su funcionamiento requiere de unas tablas e ndices cuya ubicacin
puedes configurar. Sin causas de fuerza mayor, acepta la opcin por defecto.

Esta pantalla nos permite optimizar el funcionamiento del servidor en previsin del
nmero de usos concurrentes. La opcin por defecto, Decisin Support (DSS) /
OLAP ser probablemente la que ms te convenga.

Deja ambas opciones marcadas, tal como vienen por defecto. Es la ms adecuada
para un uso de propsito general o de aprendizaje, tanto si eres desarrollador
como no. Aceptar conexiones TCP te permitir conectarte al servidor desde otras
mquinas (o desde la misma simulando un acceso web tpico).

Hora de decidir qu codificacin de caracteres emplears, salvo que quieras

empezar a trabajar con Unicode porque necesites soporte multilenguaje,
probablemente Latin1 te sirva (opcin por defecto).

Instalamos MySQL como un servicio de Windows (la opcin ms limpia) y lo

marcamos para que el motor de la base de datos arranque por defecto y est
siempre a nuestra disposicin. La alternativa es hacer esto manualmente.
Adems, me aseguro de marcar que los ejecutables estn en la variable PATH,
para poder invocar a MySQL desde cualquier lugar en la lnea de comandos.

Pon una contrasea al usuario root. Esto siempre es lo ms seguro.

Si lo deseas, puedes indicar que el usuario root pueda acceder desde una
mquina diferente a esta, aunque debo advertirte de que eso tal vez no sea una
buena prctica de seguridad.

ltima etapa, listos para generar el fichero de configuracin y arrancar el servicio.

Slo damos al botn de Finalizar y terminamos con la configuracin del DBMS.

2.1.8 Comandos Generales de Alta y Baja del DBMS

Una tabla es un sistema de elementos de datos (atributo - valores) que se
organizan que usando un modelo vertical - columnas (que son identificados por su
nombre)- y horizontal filas. Una tabla tiene un nmero especfico de columnas,
pero puede tener cualquier nmero de filas. Cada fila es identificada por los
valores que aparecen en un subconjunto particular de la columna que se ha
identificado por una llave primaria.
Una tabla de una base de datos es similar en apariencia a una hoja de clculo, en
cuanto a que los datos se almacenan en filas y columnas. Como consecuencia,
normalmente es bastante fcil importar una hoja de clculo en una tabla de una
base de datos. La principal diferencia entre almacenar los datos en una hoja de
clculo y hacerlo en una base de datos es la forma de organizarse los datos.
MySQL
MySQL soporta varios motores de almacenamiento que tratan con distintos tipos
de tabla. Los motores de almacenamiento de MySQL incluyen algunos que tratan
con tablas transaccionales y otros que no lo hacen:
MyISAM: trata tablas no transaccionales. Proporciona almacenamiento y
recuperacin de datos rpida, as como posibilidad de bsquedas fulltext. MyISAM
se soporta en todas las configuraciones MySQL, y es el motor de almacenamiento
por defecto a no ser que tenga una configuracin distinta a la que viene por
defecto con MySQL.
El motor de almacenamiento MEMORY proporciona tablas en memoria. El motor
de almacenamiento MERGE permite una coleccin de tablas MyISAM idnticas
ser tratadas como una simple tabla. Como MyISAM, los motores de
almacenamiento MEMORY y MERGE tratan tablas no transaccionales y ambos se
incluyen en MySQL por defecto.
Nota: El motor de almacenamiento MEMORY anteriormente se conoca como
HEAP.
Los
motores
de
almacenamiento InnoDB y BDB proporcionan
tablas
transaccionales. BDB se incluye en la distribucin binaria MySQL-Max en aquellos
sistemas operativos que la soportan. InnoDB tambin se incluye por defecto en
todas las distribuciones binarias de MySQL 5.0. En distribuciones fuente, puede
activar o desactivar estos motores de almacenamiento configurando MySQL a su
gusto.

El motor de almacenamiento EXAMPLE es un motor de almacenamiento 'tonto'

que no hace nada. Puede crear tablas con este motor, pero no puede almacenar
datos ni recuperarlos. El objetivo es que sirva como ejemplo en el cdigo MySQL
para ilustrar cmo escribir un motor de almacenamiento. Como tal, su inters
primario es para desarrolladores.
NDB Cluster es el motor de almacenamiento usado por MySQL Cluster para
implementar tablas que se particionan en varias mquinas. Est disponible en
distribuciones binarias MySQL-Max 5.0. Este motor de almacenamiento est
disponible para Linux, Solaris, y Mac OS X. Los autores mencionan que se aadir
soporte para este motor de almacenamiento en otras plataformas, incluyendo
Windows en prximas versiones.
El motor de almacenamiento ARCHIVE se usa para guardar grandes cantidades
de datos sin ndices con una huella muy pequea.
El motor de almacenamiento CSV guarda datos en archivos de texto usando
formato de valores separados por comas.
El motor de almacenamiento FEDERATED se aadi en MySQL 5.0.3. Este motor
guarda datos en una base de datos remota. En esta versin slo funciona con
MySQL a travs de la API MySQL C Client. En futuras versiones, ser capaz de
conectar con otras fuentes de datos usando otros drivers o mtodos de conexin
clientes.
La versin 5 de MySQL crea por defecto tablas InnoDB que permiten el manejo de
integridad referencial, transacciones. Al igual que las tablas regulares de Oracle.
Para saber si el gestor de base de datos de MySQL que tenemos las soporta es
necesario ejecutar la siguiente sentencia.
SHOW VARIABLES like '%innodb%';
Comando Describe
MySQL proporciona este comando que resulta til para conocer la estructura de
una tabla, las columnas que la forman y su tipo y restricciones. La sintaxis es la
siguiente:
DESCRIBE nombre Tabla.
DESCRIBE f1;

Comando SHOW TABLES y SHOW CREATE TABLE

El comando SHOW TABLES muestra las tablas dentro de una base de datos y
SHOW CREATE TABLES muestra la estructura de creacin de la tabla.
Tablas Temporales
Las tablas temporales solo existen mientras la sesin est viva. Si se corre este
cdigo en un script de PHP (Cualquier otro lenguaje), la tabla temporal se
destruir automticamente al trmino de la ejecucin de la pgina. Si no especfica
MEMORY, la tabla se guardar por defecto en el disco.
CREATE TEMPORARY TABLE temporal (
Ife INTEGER (13) PRIMARY KEY,
nombre CHAR (30) NOT NULL UNIQUE
);
Este tipo de tabla solo puede ser usada por el usuario que la crea.
Si creamos una tabla que tiene el mismo nombre que una existente en la base de
datos, la que existe quedar oculta y trabajaremos sobre la temporal.
Tablas Memory (Head)
Se almacenan en memoria
Una tabla head no puede tener ms de 1600 campos
Las tablas MEMORY usan una longitud de registro fija.
MEMORY no soporta columnas BLOB o TEXT.
MEMORY en MySQL 5.0 incluye soporte para columnas AUTO_INCREMENT e
ndices en columnas que contengan valores NULL.
Las tablas MEMORY se comparten entre todos los clientes (como cualquier otra
tabla no-TEMPORARY).
CREATE TEMPORARY TABLE temporal (

ife INTEGER (13) PRIMARY KEY,

nombre CHAR (30) NOT NULL UNIQUE
) ENGINE = MEMORY;
Modificacin
Esta operacin se puede realizar con el comando ALTER TABLE. Para usar
ALTER TABLE, necesita permisos ALTER, INSERT y CREATE para la tabla. La
sintaxis para MySQL es
ALTER [IGNORE] TABLE tbl_name
alter_specification [, alter_specification] ...;
alter_specification:
ADD [COLUMN] column_definition [FIRST | AFTER col_name]
| ADD [COLUMN] (column_definition,)
| ADD INDEX [index_name] [index_type] (index_col_name,)
| ADD [CONSTRAINT [symbol]]
PRIMARY KEY [index_type] (index_col_name,)
| ADD [CONSTRAINT [symbol]]
UNIQUE [index_name] [index_type] (index_col_name,)
| ADD [FULLTEXT|SPATIAL] [index_name] (index_col_name,)
| ADD [CONSTRAINT [symbol]]
FOREIGN KEY [index_name] (index_col_name,)
[reference_definition]
| ALTER [COLUMN] col_name {SET DEFAULT literal | DROP DEFAULT}
| CHANGE [COLUMN] old_col_name column_definition

[FIRST|AFTER col_name]
| MODIFY [COLUMN] column_definition [FIRST | AFTER col_name]
| DROP [COLUMN] col_name
| DROP PRIMARY KEY
| DROP INDEX index_name
| DROP FOREIGN KEY fk_symbol
| DISABLE KEYS
| ENABLE KEYS
| RENAME [TO] new_tbl_name
| ORDER BY col_name
| CONVERT TO CHARACTER SET charset_name [COLLATE collation_name]
| [DEFAULT] CHARACTER SET charset_name [COLLATE collation_name]
| DISCARD TABLESPACE
| IMPORT TABLESPACE
| table_options