Professional Documents
Culture Documents
Resumen de la unidad
Cuadro sinptico de los puntos ms relevantes (no copiar y pegar)
Red hospitales
3.
INE
Aspectos a considerar
Manual de instalacin:
40%
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:
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.
Memoria Virtual
Buffer del Dietario o del Registro del Rehacer (Redo Log Buffer).
Cach de Biblioteca.
Estructuras de Control.
Informacin diversa
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 ejecutnd ose 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
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
LOG_BUFFER
SHARED_POOL_SIZE
LARGE_POOL_SIZE
JAVA_POOL_SIZE
Gestin
Automtica
Compartida
de
Memoria
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:
El log buffer
El pool compartido
El Java pool
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.
Nota: No configurar dinmicamente el SGA_TARGET. Debera ser configurado solo al
inicio.
Limitando el Tamao de la SGA
El parmetro SGA_MAX_SIZE especifica el tamao mximo del SGA durante la duracin de la instancia.
Puedes modificar dinmicamente los parmetros que afectan al tamao de las caches de los buffers, del pool
compartido, large pool, java pool, y streams pool pero solo para controlar que la suma de estos tamaos y los
tamaos de los otros componentes del SGA no exceden el valor especificado por SGA_MAX_SIZE.
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.
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.
El tamao del rea de trabajo puede ser controlado y modificado. Generalmente, reas de
bases
de datos grandes pueden mejorar significativamente el rendimiento de un operador respecto al coste de
consumo de memoria. Opcionalmente, el tamao de un rea de trabajo puede ser lo bastante grande como
para almacenar los datos de entradas y las estructuras auxiliares de memoria asignadas por el operador SQL
asociado. De lo contrario, el tiempo de respuesta aumenta, porque parte de los datos de entrada deben ser
distribuidos por un disco de almacenamiento temporal. En caso extremo, si el tamao del rea de trabajo es
muy pequeo comparado con el tamao del dato de entrada, mltiples procesos se ejecutan sobre la parte de
los datos. Esto puede aumentar el tiempo de respuesta de un operador considerablemente.
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:
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.
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:
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.
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 aq uellos 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:
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
Oracle
MySQL
RAM
512 MB
512 MB
Memoria virtual
1024 MB
1024 MB
1.5 GB
1 GB
4 GB
Sin limite
Software
de
Base
de
Datos
en
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:
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
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.
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.
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, Decision 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.
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 Clie nt. 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 sintxis 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 noTEMPORARY). 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