2.1 Características del DBMS
Los sistemas de administración de bases de datos son usados
para:
· Permitir a los usuarios acceder y manipular la base de
datos proveyendo métodos 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 administración de los datos.
Algunas de sus características son:
Control de la Redundancia de Datos
Este consiste en lograr una mínima cantidad de espacio de
almacenamiento para almacenar los datos evitando la duplicación de la
información. De esta manera se logran ahorros en el tiempo de procesamiento de
la información, se tendrán menos inconsistencias, menores costos operativos y
hará el mantenimiento más fácil.
Compartimiento de Datos
Una de las principales características de las bases de
datos, es que los datos pueden ser compartidos entre muchos usuarios
simultáneamente, proveyendo, de esta manera, máxima eficiencia.
Mantenimiento de la Integridad
La integridad de los datos es la que garantiza la precisión
o exactitud de la información contenida en una base de datos. Los datos
interrelacionados deben siempre representar información correcta a los
usuarios.
Soporte para Control de Transacciones y Recuperación de
Fallas
Se conoce como transacción toda operación 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 recuperación de
fallas tiene que ver con la capacidad de un sistema DBMS de recuperar la información
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
aplicación debe conocer tanto la organización de los datos como las técnicas
que el permiten acceder a los datos. En los sistemas DBMS los programas de
aplicación no necesitan conocer la organización de los datos en el disco duro.
Este totalmente independiente de ello.
Seguridad
La disponibilidad de los datos puede ser restringida a
ciertos usuarios. Según los privilegios que posea cada usuario de la base de
datos, podrá acceder a mayor información que otros.
Velocidad
Los sistemas DBMS modernos poseen altas velocidades de respuesta
y proceso.
Independencia del Hardware
La mayoría de los sistemas DBMS están disponibles para ser
instalados en múltiples plataformas de hardware.
2.1.1 Estructura de Memoria y Procesos de la Instancia
Introducción
Oracle utiliza la memoria para almacenar la siguiente
información:
· Código del
programa
· Información acerca de una sesión conectada,
incluso si no se encuentra activa.
· Información necesaria durante la
ejecución del programa(por ejemplo, el estado de las consultas
· La información que comparten y con la
cual se comunican los procesos Oracle (por ejemplo, la información 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 código de Software (SCA).
El Área Global del Sistema (SGA) es un grupo de estructuras
de la memoria compartida que contiene datos e información 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 también
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 automáticamente y
esta se devuelve al sistema operativo cuando la instancia se cierra. Por tanto,
cada instancia posee su propio SGA.
Además, es de lectura/escritura. Todos los usuarios
conectados a una instancia multiproceso pueden leer la información contenida en
el SGA de la instancia y varios procesos pueden escribir en él durante la
ejecución.
Una parte del SGA contiene información 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 también incluye información de comunicación entre procesos, como la
información de bloqueos. Además, si el sistema usa una arquitectura de servidor
compartido, entonces las colas de petición 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.
· Información 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 más
procesos. A la combinación 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.
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 simultáneamente,
accediendo cada una a su propia base de datos física.
Ú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 información 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 páginas.
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
están lógicamente segmentadas en varios conjuntos, lo que reduce la contención
en sistemas multiprocesador.
Organización de la Caché de los Buffers
Los buffers en la caché están 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 aún no se han escrito en disco. La lista LRU contiene los buffers
libres, buffers que están siendo accedidos actualmente (pinned buffers) y los
buffers en espera, que aún no están almacenados en la lista en espera. Cuando
un proceso Oracle accede a un buffer, este lo sitúa 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 página en
disco a un buffer de la caché antes de leerlo (cache miss). Acceder a los datos
a través de un ‘cache hit’ es más rápido 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 exploración
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 exploración completa
se necesita brevemente, por lo que los bloques deben sacarse rápidamente para
dejar espacio en la caché a los bloques que se usan con mayor frecuencia.
Tamaño de la Caché de los buffer
Oracle soporta múltiples tamaños de bloque en una base de
datos. El tamaño estándar de bloque se especifica mediante la configuración del
parámetro DB_BLOCK_SIZE. Se admiten valores desde 2K hasta 32K.
Opcionalmente, también se puede seleccionar el tamaño de dos
pool de buffer adicionales, KEEP y RECYCLE, configurando DB_KEEP_CACHE_SIZE y
DB_RECYCLE_CACHE_SIZE. Estos tres parámetros son independientes entre sí.
Múltiples Pools de Buffer
Se puede configurar la cache del buffer con “buffer pools”
distintos, en los que cualquiera contiene datos, o están 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 ningún
buffer pool, así como los objetos del esquema que son explícitamente asignados
al pool DEFAULT.
Los parámetros 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
información sobre cambios hechos a la base de datos, la cual se almacena en las
‘entradas redo’. Estas entradas contienen la información 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
recuperación 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 parámetro LOG_BUFFER determina el tamaño (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 ejecución paralela y las
estructuras de control.
El tamaño total del Pool Compartido se determina por el
parámetro 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 configuración 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 declaración de SQL con un área SQL
compartida y un área SQL privada. Oracle reconoce cuando dos usuarios están
ejecutando la misma instrucción SQL y reutiliza el área SQL compartida para
esos usuarios. Sin embargo, cada usuario debe tener una copia separada de la
declaración del área SQL privada.
Áreas SQL Compartidas
Un área SQL Compartida contiene el árbol de análisis y el
plan de ejecución para una instrucción SQL dada. Se ahorra memoria usando un
solo área SQL compartida para instrucciones SQL ejecutándose varias veces, lo
cual ocurre con frecuencia cuando varios usuarios ejecutan la misma aplicación.
Programas PL/SQL y el Pool Compartido
Oracle procesa programas PL/SQL (procedimientos, funciones,
paquetes, bloques anónimos, 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
específicos de la sesión que ejecuta el programa, incluyendo variables locales,
globales y de paquete y buffers para ejecución SQL. Si más 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 específicos de su sesión.
Las instrucciones SQL individuales están 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 sesión para el servidor compartido y el Oracle XA interface (usado donde las
transacciones interactúan con más de una base de datos)
· Procesamiento de E/S
· Copias de seguridad y operaciones de
recuperación
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 código 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 estadísticas de java pool proporciona
información sobre la memoria de la cache de biblioteca usada para java y
predice como pueden afectar cambios en el tamaño del java pool en la tasa de
análisis. El asesor de java pool se activa internamente cuando el
statistics_level está configurado en TYPICAL o mayor. Estas estadísticas 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 tamaño del pool en bytes usando el parámetro
STREAMS_POOL_SIZE. Si un streams pool no está definido, entonces se crea
automáticamente 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 después del
primer uso de los flujos. La cantidad transferida es del 10% del tamaño del
pool compartido.
Caché de Diccionario (Dictionary Cache)
El diccionario de datos es una colección de tablas y vistas
de la base de datos que contienen información 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, también 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 Parámetro SGA_MAX_SIZE
El SGA comprende un número de componentes de memoria,
denominados pools de memoria, que se usan para satisfacer una clase particular
de asignación de memoria. Todos los componentes del SGA asignan y liberan
espacio en unidades (módulos). El tamaño del módulo queda determinado por el
tamaño total del SGA. En la mayoría de las plataformas el tamaño del módulo es
4MB si el tamaño total del SGA es menor de 1GB, y de 16MB para SGA mayores.
La base de datos puede configurar límites sobre cuanta
memoria virtual se usa para el SGA. Puede crear instancias con un mínimo de
memoria y permitir que la instancia use más, expandiendo la memoria asignada a
los componentes del SGA, hasta un máximo 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 configuración de SGA_MAX_SIZE.
Para un rendimiento óptimo, en la mayoría de los sistemas,
todo el SGA debería 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 también influye en el rendimiento.
El tamaño del SGA queda determinado por muchos parámetros,
aunque son los siguientes los que tienen un gran efecto sobre el tamaño del
SGA:
Parámetro
Descripción
DB_CACHE_SIZE
Tamaño de la cache de los bloques estándar.
LOG_BUFFER
Número de bytes asignados al redo log buffer.
SHARED_POOL_SIZE
Tamaño en bytes para el área dedicada al SQL compartido e
instrucciones PL/SQL.
LARGE_POOL_SIZE
Tamaño del large pool, por defecto es 0.
JAVA_POOL_SIZE
Tamaño del java pool.
Gestión Automática de Memoria Compartida
En versiones anteriores el administrador de la base de datos
tenía que especificar manualmente los tamaños de los diferentes componentes del
SGA configurando un número de parámetros de inicialización, que incluían el
SHARED_POOL_SIZE, DB_CACHE_SIZE, JAVA_POOL_SIZE, y LARGE_POOL_SIZE. En la
versión 10g se incluye la gestión automática de la memoria compartida que
simplifica la gestión 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 automáticamente distribuirá
esta memoria entre varios subcomponentes para asegurar el mayor uso de memoria
efectiva.
Cuando la gestión automática de memoria del SGA esta
activada, el tamaño de los diferentes componentes del SGA es flexible y pueden
adaptarse a las necesidades del trabajo sin requerir ninguna configuración
adicional. La base de datos automáticamente 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 parámetro se simplifica mucho la tarea
de administración ya que puedes especificar solo la cantidad de memoria del SGA
que una instancia tiene disponible y olvidarte de los tamaños de los
componentes individuales. No se generan errores de “out of memory” a menos que
el sistema se haya quedado sin memoria.
La gestión automática del SGA puede mejorar el rendimiento
sin necesidad de recursos adicionales ni ajustes manuales. Con la configuración
manual del SGA es posible que instrucciones SQL compiladas se saquen del pool
compartido debido a su insuficiente tamaño lo que incrementa la frecuencia de
análisis difíciles, que reducen el rendimiento. Cuando la gestión automática
del SGA esta activa, el algoritmo de ajuste interno supervisa el rendimiento
del trabajo, incrementando el tamaño del pool compartido si reduce el número de
análisis requeridos.
El Parámetro SGA_TARGET
El parámetro SGA_TARGET refleja el tamaño 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 cachés de los buffers keep y
recycle (si son especificados)
· El tamaño de los bloques no estándar
de las cachés 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 través de otros parámetros. En consecuencia, el SGA_TARGET da un
control preciso sobre el tamaño de la región 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 dinámicamente el SGA_TARGET. Debería ser
configurado solo al inicio.
Limitando el Tamaño de la SGA
El parámetro SGA_MAX_SIZE especifica el tamaño máximo del
SGA durante la duración de la instancia. Puedes modificar dinámicamente los
parámetros que afectan al tamaño 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 tamaños y los tamaños de los otros componentes del SGA no
exceden el valor especificado por SGA_MAX_SIZE.
2.1.2 Estructuras Físicas de la Base de Datos
Áreas Globales de Programas PGA (Program Global Areas)
Un área global de programa (PGA) es una región de memoria
que contiene datos e información 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 código de Oracle que actúa en nombre del proceso.
Contenido de un PGA
El contenido de la memoria de un PGA varía dependiendo de
dónde 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 Sesión: La memoria de sesión (Session Memory) se
asigna para mantener las variables de una sesión (logon information) y otra
información relativa a la sesión. Para un servidor compartido, la memoria de
sesión es compartida y no privada.
Área SQL Privada: Un área SQL privada contiene datos como
por ejemplo consultas de información de ejecuciones y consultas de ejecuciones
en áreas de trabajo. Cada sesión 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 ubicación de un área privada SQL depende del tipo de
conexión establecida para una sesión. Si una sesión se conecta a través de un
servidor dedicado, las áreas privadas SQL esta localizadas en el servidor del
proceso del PGA. De cualquier forma, si una sesión se conecta a través de un
servidor compartido, parte del área privada SQL se mantiene en el SGA.
Cursores y Áreas SQL
La aplicación de desarrollo de un programa precompilador
Oracle o un programa OCI puede explícitamente abrir cursores, o manejar algún
área privada SQL específica, y usarla como un recurso nombrado a través de la
ejecución de un programa. Los cursores recursivos de Oracle que emiten
implícitamente algunas sentencias SQL también usan áreas SQL.
La administración de las áreas SQL privadas son
responsabilidad de los procesos del usuario. La asignación y liberación de las
áreas SQL privadas dependen de en qué herramienta de la aplicación se usan,
aunque el número de áreas SQL privadas que un proceso de usuario puede asignar
está siempre limitado el parámetro OPEN_CURSORS. El valor por defecto de este
parámetro 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 ejecución después 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
aplicación.
Componentes del Área SQL Privada
El área SQL privada de un cursor se divide en 2 áreas cuya
duración son diferentes:
· El área
persistente (Persistent Area), que contiene, por ejemplo, información envuelta.
Es liberada solamente cuando el cursor es cerrado.
· El área de ejecución (Run-time Area),
que es liberada cuando la ejecución, valga la redundancia, es terminada.
Oracle crea el área de ejecución en el primer paso que una
ejecución es pedida. Para una sentencia INSERT, UPDATE y DELETE Oracle libera
el área de ejecución después de que la sentencia ha sido ejecutada. Para las
consultas, Oracle libera el área de ejecución solamente cuando todas las filas
han sido recorridas, o la consulta ha sido cancelada.
Áreas de Trabajo SQL
Para las consultas complejas, una gran porción del área de
ejecución es dedicada a áreas de trabajo asignadas por operadores de
memoria-intensiva como los siguientes:
· Operadores de base de clasificación
“Sort-based” (order by, group by, rollup)
· Hash-join
· Bitmap merge
· Bitmap create
Por ejemplo, un operador de clasificación (sort operator)
usa un área de trabajo (algunas veces llamado área de clasificación “sort
area”) para la forma de distribución de la memoria interna (in-memory) de una
serie de filas. Similarmente, un operador hash-join usa un área de trabajo
(también 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 más pequeñas. 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 pequeña, su complejidad es
inversamente proporcional al tamaño de su área de trabajo. Estos operadores se
ejecutan más rápido en áreas de trabajo más grandes.
El tamaño 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 tamaño 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
tamaño del área de trabajo es muy pequeño comparado con el tamaño del dato de
entrada, múltiples procesos se ejecutan sobre la parte de los datos. Esto puede
aumentar el tiempo de respuesta de un operador considerablemente.
Administración de la Memoria del PGA para un Modo Dedicado
Se puede administrar el tamaño de las áreas de trabajo SQL
globalmente y automáticamente. El administrador de la base de datos simplemente
necesita que sea especificado el tamaño total dedicado a la memoria del PGA
para las instancias de configurando el parámetro PGA_AGGREGATE_TARGET. El
número 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 tamaño de las áreas
de trabajo para todas las sesiones dedicadas es automático, y todos los
parámetros *_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 organización y ordenación de las filas.
El tamaño por defecto, expresado en bytes, es específico de
cada SO. Sin embargo, hay muchas razones importantes por las que este tamaño
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 ordenación en una consulta puede
consumir la cantidad de memoria especificada en el SORT_AREA_SIZE, y pueden
haber múltiples ordenaciones en una consulta. De esta forma, si otra consulta
se ejecuta en paralelo, cada ordenación puede consumir la memoria especificada
en este campo.
· El SORT_AREA_SIZE también 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 operación DML, pudiendo incluso haber cambiado
varias filas a la vez.
· Grandes valores en este campo nos
permitirán realizar mayores búsquedas en memoria. Si se necesitase más espacio
para la ordenación del que tenemos, los datos se dividirán en trozos y se
utilizarán segmentos de disco temporales como apoyo en la ordenación.
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 también el manual de Oracle9i, que si
bien lo hace en trozos separados, a continuación se muestran las dos
referencias juntas:
· Para un mejor rendimiento del SGBD, la
mayoría de las ordenaciones deberían 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
búsquedas que no caben en el área de ordenaciones, o incluso si las
aplicaciones realizan demasiadas búsquedas innecesarias, entonces sería
conveniente modificar el parámetro de SORT_AREA SIZE.
· El SORT_AREA_SIZE es un parámetro que
se puede inicializar y modificar dinámicamente 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 aplicación se verá claramente beneficiada al ampliar el
SORT_AREA_SIZE. De forma alternativa, en un entorno DSS, aumentar este
parámetro no tiene por qué hacer que la ordenación se realice únicamente en
memoria, pero sí es cierto que dependiendo del valor actual y del nuevo
elegido, se puede aumentar drásticamente la velocidad de la ordenación.
Por lo tanto, como conclusión, alterar este parámetro, se
puede considerar como un paso importante para asegurarnos el rendimiento en
ciertas circunstancias y situaciones. Sin embargo, determinar qué valor es el
más apropiado, es por supuesto, la parte más complicada.
Memoria Virtual en Oracle
Oracle puede utilizar la memoria virtual proporcionada por
el SO para simular memoria a base de algún 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, búsquedas, etc) se necesita un espacio auxiliar que normalmente
suele ser el disco duro. Para el traspaso de información se utilizan dos
técnicas principales: el Paging o paginación y el Swapping.
Paginación
La paginación consiste en dividir los programas en pequeños
bloques o páginas, de manera que sea más fácil moverlos de memoria a disco y
viceversa. De la misma forma, la memoria se divide en marcos de página. De esta
forma, la cantidad de memoria desperdiciada por un proceso es el final de su
última página, minimizando así la fragmentación interna y evitando la externa.
En un momento cualquiera, la memoria se encuentra ocupada
con páginas de diferentes procesos, mientras que algunos marcos están
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 página del proceso. De esta forma, las páginas de un proceso
pueden no estar contiguamente ubicadas en memoria, y pueden intercalarse con
las páginas de otros procesos.
En la tabla de páginas de un proceso, se encuentra la
ubicación del marco que contiene a cada una de sus páginas. Las direcciones
lógicas ahora se forman como un número de página y de un desplazamiento dentro
de esa página (conocido comúnmente como offset). El número de página es usado
como un índice dentro de la tabla de páginas, y una vez obtenida la dirección
del marco de memoria, se utiliza el desplazamiento para componer la dirección
real o dirección física. Este proceso se realiza en una parte del ordenador
específicamente diseñada 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 páginas en marcos libres y se completa su tabla de páginas.
Swapping
El Swapping es el procedimiento de mover los bloques de memoria
en los que están algunos procesos que no se están 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 partición) que se usa para guardar las imágenes de los
procesos que no han de mantenerse en memoria física.
Este procedimiento es muy similar a la paginación, con la
diferencia principal de que el directorio Swap funciona exactamente igual que
la memoria RAM, por lo que puede almacenar datos privados, contraseñas y todo
lo que almacena ésta. Sin embargo, en la paginación, únicamente se sacan de
memoria páginas pertenecientes a procesos que no se estén utilizando, además de
que se pueden sacar solo algunas páginas de los procesos y no éstos enteros
como se hace en el Swapping.
Con respecto al tamaño 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 tamaño que la RAM.” cosa que no es válida hoy día
debido a la gran capacidad de la memoria RAM de la mayoría de ordenadores.
Como conclusión, hay que destacar que el uso de la memoria
virtual por parte de Oracle, va a influir bastante en el rendimiento,
disminuyéndolo drásticamente en comparación con el uso únicamente de la memoria
RAM.
Área de Código de Software (Sca)
El área de código de software son zonas de memoria
destinadas a almacenar el código de Oracle en ejecución o que puede ejecutarse.
Este código de Oracle se almacena en una zona distinta, y más protegida, que
las zonas dedicadas a almacenar los códigos de programas de usuarios.
La SCA suele ser de tamaño estático, cambiando únicamente
cuando el software se reinstala o actualiza. El tamaño requerido para este área
puede variar en función del SO. Son áreas de sólo lectura y pueden ser instalas
de forma compartida o no compartida. Cuando es posible, el código de Oracle se
comparte, por lo que todos los usuarios pueden acceder a él sin tener múltiples
copias en memoria. El resultado es un ahorro considerable de memoria y una
mejora del rendimiento general.
Por otra parte, los programas de usuario también 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. Múltiples instancias de Oracle pueden usar la misma SCA con diferentes
bases de datos si están corriendo en la misma máquina.
Hay que tener en cuenta que la opción de instalar software
compartido puede no estar disponible en función del sistema operativo, como
ocurre por ejemplo en máquinas con Windows.
Estructura de los Procesos
Cuando un usuario se conecta a una base de datos de Oracle
ejecuta dos módulos de código diferentes, que además el encargado de gestionar
estos procesos es el sistema operativo, estos dos módulos diferentes son:
· Aplicación 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
· Código 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 múltiples usuarios conectarse a la misma vez, y mayor rapidez en
el tiempo de respuesta, puesto que siempre que pueda va a utilizar al máximo al
ordenador, por ejemplo si tiene ocho núcleos el servidor, y resulta que una
petición se puede paralelizar se ejecutara esa petición por partes en cada
núcleo.
De los procesos que se ejecutan en el servidor podemos hacer
dos grandes grupos:
Procesos de Usuarios: Cada vez que un usuario ejecuta una
aplicación, ya sea propia o de Oracle se crea un proceso, que puede ser de dos
tipos.
· Conexión: Que es la vía de
comunicación entre la aplicación y la instancia de la base de datos a la que se
ha conectado.
· Sesión: Es la conexión específica con
la base de datos proporcionando un usuario y su contraseña.
Esto permite que desde un mismo equipo se puedan conectar
varios usuarios simultáneamente, y que un usuario se pueda conectar desde
diferentes equipos simultáneamente.
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 aplicación intenta acceder a la base de datos,
para atender a las peticiones de la aplicación 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 continuación, 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 después de haber recorrido un número de determinado de buffers en el
buffer caché, éste envía una señal al DBWn para la escritura. El DBWn escribe
los buffers sucios al disco.
El DBWn periódicamente escribe los buffers cuando se lleva a
cabo un checkpoint. Chekpoint es una posición en el hilo de redo (log) donde se
iniciará luego la recuperación. La posición 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 rápido 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 transacción
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 instrucción de commit, el
LGWR coloca el registro de commit en el log buffer y escribe la transacción 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 más
eficiente que hacer. Esto se denomina el mecanismo de fast commit. La escritura
de un registro de redo del commit de la transacción es un evento atómico.
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 aparecerán sólo las
transacciones comprometidas. En el redo log file se escriben todas las
transacciones, no sólo las comprometidas, es por ello que el redo log permite
rehacer los segmentos de undo del cualquier punto en el tiempo cuando se hace
recuperación 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 idénticos, es decir contendrán la misma
información. 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 habría otro que contendría la información y que permitiera la
recuperación 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 también 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 enumeración 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 aún 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 permitiría
ninguna transacción 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, entendiéndose 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 podrían almacenarse en disco buffers de transacciones no
comprometidas el CKPT también 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 recuperación incompleta. También si en
la escritura del checkpoint hay transacciones que no se habían terminado de
escribir en disco se escriben, se actualiza la cola de transacciones activas y
un grupo de redo log que estaba activo podría 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 recuperación, si es
necesaria, de la instancia en el inicio de la misma, es decir rehacer cualquier
transacción comprometida en el redo log file que no haya sido escrita a disco.
SMON también es responsable de limpiar los segmentos temporales que no estén en
uso por algún tiempo y de desfragmentar si cree oportuno alguna zona de los
discos.
Process Monitor (PMON)
PMON lleva a cabo procesos de recuperación cuando un proceso
de usuario falla. Es responsable de la limpieza del buffer caché, también de
deshacer los cambios que se hayan hecho desde el ultimo commit y de la
liberación 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 conexión de red.
Recoverer (RECO)
Este proceso solo se observa cuando la base de datos ejecuta
la opción distribuida de Oracle. La transacción distribuida es una en la que
dos o más emplazamientos de datos deben mantenerse sincronizados, Por ejemplo
cuando se tiene una copia de los datos en diferentes ciudades y por fallas en
una línea telefónica se pierde una transacción en la mitad de su actualización.
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 sólo
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
distinguía entre el "archive" manual y automático. Con
"archive" manual el DBA debía ordenar hacer la copia de los redo log
a los "archives", en el modo automático se copiaban automáticamente
antes de ser sobrescritos. En Oracle 10g al poner una base de datos en modo
ARCHIVELOG automáticamente se coloca en el modo automático.
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 algún
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 comunicación asíncrona. Los procesos envían
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 múltiples 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 Instalación 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 características de configuración especializadas como pueden ser la
reconfiguración de los servicios TCP/IP y la modificación de los tipos archivos
HTML para los diversos navegadores.
Se presenta a continuación una serie de requerimientos
mínimos de hardware y software para instalar oracle 11g Express y MySQL
estándar versión 5.1. En
Windows Seven y Ubuntu 10.
Requerimiento
Oracle
MySQL
RAM
512 MB
512 MB
Memoria virtual
1024 MB
1024 MB
Espacio disco duro
1.5 GB
1 GB
Tamaño máximo de la base de datos
4 GB
Sin limite
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 tamaño de la memoria
virtual depende del tamaño 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 tamaño. Si usted tiene más de 8 GB de memoria RAM instalada
puede considerar usar el mismo tamaño como espacio de intercambio. Cuanta más
memoria RAM tenga instalada, es menos probable usar el espacio de intercambio,
a menos que tenga un proceso inadecuado.
2.1.4 Instalación del Software de Base de Datos en
ModoTransaccional
Debido al constante crecimiento de datos que generan las
empresas hoy en día, se ha vuelto muy necesaria la búsqueda de nuevas
plataformas para almacenar y analizar la información, ambientes que consuman
menos recursos, que sean más escalables y que provean una alta disponibilidad.
La solución 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 inserción y actualización se hagan dentro
de una transacción, es un componente que procesa información descomponiéndola
de forma unitaria en operaciones indivisibles, llamadas transacciones, esto
quiere decir que todas las operaciones se realizan o no, si sucede algún error
en la operación se omite todo el proceso de modificación de la base de datos,
si no sucede ningún error se hacen toda la operación con éxito.
Una transacción es un conjunto de líneas de un programa que
llevan insert o update o delete. Todo aquél software que tiene un log de
transacciones (que es la "bitácora" que permite hacer operaciones de
commit o rollback), propiamente es un software de BD; aquél 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 transacción debe finalizar
de forma correcta o incorrecta como una unidad completa. No puede acabar en un
estado intermedio.
Se usan los siguientes métodos:
· Begin TRans
para iniciar la transacción
· 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 teoría para cualquier BD.
Instalación de MySQl en Windows 7
1. Comprobar que no
existe una versión anterior, si existe desinstalarla.
2. Descargar el
archivo de instalación, en nuestro caso MySQL Enterprise.
3. Ejecute el
archivo:
4. Procesa a
instalar en el modo por defecto. Es necesario tener conexión a Internet
5. Configure el
servidor según sus necesidades
6. Es este punto se
configura como se comportará nuestro servidor y el servicio. Además se
descargan e instalan los paquetes necesarios.
7. Ahora proceda a
configurar MySQL Workbench; es una herramienta visual de diseño de bases de
datos que integra desarrollo de software, administración de bases de datos,
diseño de bases de datos, creación 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 configuración 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
Instalación
Variable: Es un espacio en memoria al cual se le da un
nombre Hay variables específicas que se crean al momento de entrar al sistema,
pero también hay variables que pueden ser definidas por el usuario. Las
variables son una forma de pasar información 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 continuación se comentan las opciones más utilizadas de la
sección mysqld (afectan al funcionamiento del servidor MySQL), se almacenan en
el archivo my.cnf (o my.ini)
basedir = ruta: Ruta a la raíz 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 transacción).
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, están 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 más, 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 saltándose 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á sesión 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 más del tiempo mínimo establecido. El archivo está
(salvo quese especifique slow-log-file como parámetro) en la carpeta de datos
de MySQL con el nombre host_name-slow.log
2.1.6 Procedimiento General de Instalación de un DBMS
MySQL Enterprise Edition
MySQL Enterprise Edition incluye el conjunto más completo de
características avanzadas y herramientas de gestión para alcanzar los más altos
niveles de escalabilidad, seguridad, fiabilidad y tiempo de actividad. Reduce
el riesgo, costo y complejidad en el desarrollo, implementación y
administración de aplicaciones críticas de negocio MySQL.
El MySQL Enterprise incluye las siguientes opciones:
Backup: Realiza copias de seguridad de bases de datos MySQL
en línea, de los subconjuntos de tablas InnoDB, y la recuperación mediante
puntos de restauración.
Alta Disponibilidad: es proporcionada con soluciones
certificadas que incluyen replicación 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 módulos de autenticación externos para integrar fácilmente 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 cómo implementar las mejores
prácticas 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
localización de código SQL que está causando una desaceleración
MySQL Workbench: Cuenta con ofertas de modelado de datos,
desarrollo de SQL y herramientas de administración integral para la
administración del servidor de configuración del usuario, y mucho más.
El proceso de instalación es muy simple y prácticamente no
requiere intervención por parte del usuario.
Comienza el proceso; sólo nos llevará un par de minutos…
Cada vez que veo la pantalla de la GNU GPL me lleno de
felicidad. No sólo por las condiciones y el precio: es además, para mí, una
garantía de profesionalidad.
Estadísticamente, la instalación típica será la que mejor se
adapte a tus necesidades.
Todo listo; presiona Install cuando quieras.
Una vez instalado MySQL, la siguiente fase es la
configuración del servidor en sí mismo. Asegúrate de que la marca Launch the
MySQL Instance Configuration Wizard esté activa.
2.1.7 Procedimiento para Configuración 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 inglés, 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 información sobre privilegios y procedimientos del gestor
y no deben ser eliminados.
Adelante, sin miedo…
Optamos por Detailed Configuration, de modo que se optimice
la configuración del servidorMySQL.
Ha llegado un momento crucial. Dependiendo del uso que
vayamos a darle a nuestro servidor deberemos elegir una opción u otra, cada una
con sus propios requerimientos de memoria. Puede que te guste la opción
Developer Machine, para desarrolladores, la más apta para un uso de propósito
general y la que menos recursos consume. Si vas a compartir servicios en esta
máquina, probablemente Server Machine sea tu elección 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
función.
De nuevo, para un uso de propósito general, te recomiendo la
opción 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
ubicación puedes configurar. Sin causas de fuerza mayor, acepta la opción por
defecto.
Esta pantalla nos permite optimizar el funcionamiento del
servidor en previsión del número de usos concurrentes. La opción por defecto,
Decision Support (DSS) / OLAP será probablemente la que más te convenga.
Deja ambas opciones marcadas, tal como vienen por defecto.
Es la más adecuada para un uso de propósito general o de aprendizaje, tanto si
eres desarrollador como no. Aceptar conexiones TCP te permitirá conectarte al
servidor desde otras máquinas (o desde la misma simulando un acceso web
típico).
Hora de decidir qué codificación de caracteres emplearás,
salvo que quieras empezar a trabajar con Unicode porque necesites soporte
multilenguaje, probablemente Latin1 te sirva (opción por defecto).
Instalamos MySQL como un servicio de Windows (la opción más
limpia) y lo marcamos para que el motor de la base de datos arranque por
defecto y esté siempre a nuestra disposición. La alternativa es hacer esto
manualmente.
Además, me aseguro de marcar que los ejecutables estén en la
variable PATH, para poder invocar a MySQL desde cualquier lugar en la línea de
comandos.
Pon una contraseña al usuario root. Esto siempre es lo más
seguro.
Si lo deseas, puedes indicar que el usuario root pueda
acceder desde una máquina diferente a esta, aunque debo advertirte de que eso
tal vez no sea una buena práctica de seguridad.
Última etapa, listos para generar el fichero de
configuración y arrancar el servicio.
Sólo damos al botón de Finalizar y terminamos con la
configuración 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 número
específico de columnas, pero puede tener cualquier número 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 cálculo, en cuanto a que los datos se almacenan en filas y
columnas. Como consecuencia, normalmente es bastante fácil importar una hoja de
cálculo en una tabla de una base de datos. La principal diferencia entre
almacenar los datos en una hoja de cálculo 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 recuperación de datos rápida, así como posibilidad de
búsquedas fulltext. MyISAM se soporta en todas las configuraciones MySQL, y es
el motor de almacenamiento por defecto a no ser que tenga una configuración
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 colección de tablas
MyISAM idénticas 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
conocía como HEAP.
Los motores de almacenamiento InnoDB y BDB proporcionan
tablas transaccionales. BDB se incluye en la distribución binaria MySQL-Max en
aquellos sistemas operativos que la soportan. InnoDB también 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 código MySQL para ilustrar cómo escribir un motor de
almacenamiento. Como tal, su interés primario es para desarrolladores.
NDB Cluster es el motor de almacenamiento usado por MySQL
Cluster para implementar tablas que se particionan en varias máquinas. 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
añadirá soporte para este motor de almacenamiento en otras plataformas,
incluyendo Windows en próximas versiones.
El motor de almacenamiento ARCHIVE se usa para guardar
grandes cantidades de datos sin índices con una huella muy pequeña.
El motor de almacenamiento CSV guarda datos en archivos de
texto usando formato de valores separados por comas.
El motor de almacenamiento FEDERATED se añadió en MySQL
5.0.3. Este motor guarda datos en una base de datos remota. En esta versión
sólo funciona con MySQL a través de la API MySQL C Client. En futuras
versiones, será capaz de conectar con otras fuentes de datos usando otros
drivers o métodos de conexión clientes.
La versión 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 sintáxis 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 creación de la tabla.
Tablas Temporales
Las tablas temporales
solo existen mientras la sesión está viva. Si se corre este código en un script
de PHP (Cualquier otro lenguaje), la tabla temporal se destruirá
automáticamente al término de la ejecución de la página. Si no específica
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 más 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;
