arquitectura del gestor
DESCRIPTION
Base de DatosTRANSCRIPT
Unidad 2: Arquitectura del Gestor2.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).
Figura 1. Estructura de la memoria en Oracle
Área Global del Sistema (System Global Area, SGA)
El Área Global del Sistema (SGA) es un grupo de estructuras de la memoria compartida que contiene datos e 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.
Figura 2. Estructura de una instancia de Oracle
La Instancia y la Base de Datos
Cuando se inicia una instancia Oracle monta la base de datos, es decir, asocia dicha instancia a su base de datos correspondiente. En un mismo ordenador pueden ejecutarse varias instancias 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ámetroDescripció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.
ParámetroDescripción
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.
RequerimientoOracle MySQL
RAM 512 MB
512 MB
RequerimientoOracle MySQL
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;
Modificación
Esta operación 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