Arquitectura del gestor 2.1.

1 Estructura de memoria y procesos de la instancia

ORACLE
Introduccin

Oracle utiliza la memoria para almacenar la siguiente informacin:

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

La memoria se puede estructurar en las siguientes partes:

rea Global del sistema (SGA), la cual se comparte entre todos los servidores y los procesos en segundo plano. reas globales de programas (PGA), que es privada para cada servidor y proceso en segundo planos; a cada proceso se asigna un PGA. rea de Ordenaciones (Sort Areas). Memoria Virtual rea de cdigo de Software (SCA).

Figura 1. Estructura de la memoria en Oracle

rea Global del Sistema (System Global Area, SGA)

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

plano necesitan acceder (SGA fija), pero no se almacenan los datos de usuario. El SGA tambin incluye informacin de comunicacin entre procesos, como la informacin de bloqueos. Adems, si el sistema usa una arquitectura de servidor compartido, entonces las colas de peticin y respuesta y algunos contenidos del PGA se encuentran en el SGA. El SGA contiene la siguiente estructura de datos: Cach de los Buffers de la BD (Database Buffer Cache). Buffer del Dietario o del Registro del Rehacer (Redo Log Buffer). El Pool Compartido (Shared Pool). o Cach de Biblioteca. o Cach del Diccionario de Datos. o Estructuras de Control.

Informacin diversa

Instancia de una Base de Datos

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

Figura 2. Estructura de una instancia de Oracle

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

(cache miss). Acceder a los datos a travs de un cache hit es ms rpido que hacerlo mediante un cache miss. Antes de leer un bloque de datos dentro de la cach, el proceso debe encontrar primero un buffer libre, empezando desde el menos usado recientemente de la lista LRU. El proceso sigue buscando hasta que encuentra un buffer libre o hasta que llega al final de la lista. EL algoritmo LRU y la lectura completa de tablas Cuando un proceso de usuario realiza una exploracin completa de la tabla, lee cada bloque de la tabla en los buffers y los pone al final de la lista LRU. Se hace as porque normalmente la exploracin completa se necesita brevemente, por lo que los bloques deben sacarse rpidamente para dejar espacio en la cach a los bloques que se usan con mayor frecuencia. Tamao de la cache del los buffer Oracle soporta mltiples tamaos de bloque en una base de datos. El tamao estndar de bloque se especifica mediante la configuracin del parmetro DB_BLOCK_SIZE. Se admiten valores desde 2K hasta 32K. Opcionalmente, tambin se puede seleccionar el tamao de dos pool de buffer adicionales, KEEP y RECYCLE, configurando DB_KEEP_CACHE_SIZE y DB_RECYCLE_CACHE_SIZE. Estos tres parmetros son independientes entre s. Mltiple Pools de Buffer Se puede configurar la cache del buffer con buffer pools distintos, en los que cualquiera contiene datos, o estn disponibles para nuevos datos tras usar los bloques de datos. Objetos particulares del esquema (tablas, clusters, ndices y particiones) se asignan al buffer pool apropiado para controlar la forma en que los bloques de datos envejecen en la cache.

El buffer pool KEEP conserva los bloques de datos de los objetos del esquema en memoria.

El buffer pool RECYCLE elimina bloques de datos de la memoria tan pronto como dejan de ser necesitados. El buffer pool DEFAULT contiene bloques de datos de los objetos del esquema que no son asignados a ningn buffer pool, as como los objetos del esquema que son explcitamente asignados al pool DEFAULT.

Los parmetros que configuran los buffer pools KEEP y RECYCLE son DB_KEEP_CACHE_SIZE y DB_RECYCLE_CACHE_SIZE. Buffer del registro del Rehacer (Redo Log Buffer) El redo log buffer es un buffer circular en el SGA que contiene informacin sobre cambios hechos a la base de datos, la cual se almacena en las entradas redo. Estas entradas contienen la informacin necesaria para reconstruir, o rehacer cambios hechos en la base de datos mediante las operaciones INSERT, UPDATE, DELETE, CREATE, ALTER o DROP y se usan para la recuperacin de la base de datos, si fuera necesario. Las entradas se copian por los procesos desde el espacio de memoria del usuario al redo log buffer en el SGA, ocupando continuamente espacio secuencial. El proceso en segundo plano LGWR escribe el redo log buffer en el fichero redo log activo (o grupo de ficheros) en disco. El parmetro LOG_BUFFER determina el tamao (en bytes) del redo log buffer. El Pool Compartido Es la parte del SGA que contiene la cache de biblioteca, la cache de diccionario, los buffers para los mensajes de ejecucin paralela y las estructuras de control. El tamao total del Pool Compartido se determina por el parmetro SHARED_POOL_SIZE. El valor por defecto es de 8MB en plataformas de 32-bit, y de 64MB para plataformas de 64-bit. Incrementando su valor se incrementa la cantidad de memoria reservada para el pool compartido.

Cache de Biblioteca (Library Cache) La cache de biblioteca incluye reas de SQL compartidas, reas SQL privadas (en caso de una configuracin de servidor compartido), procedimientos y paquetes PL/SQL, y estructuras de control tales como bloqueos y el manejo de la cache de biblioteca. Ya que las reas de SQL compartidas son accesibles para todos los usuarios, la cach de biblioteca est contenida en el Pool compartido dentro del SGA. reas SQL compartidas y reas SQL privadas Oracle representa cada declaracin de SQL con un rea SQL compartida y un rea SQL privada. Oracle reconoce cuando dos usuarios estn ejecutando la misma instruccin SQL y reutiliza el rea SQL compartida para esos usuarios. Sin embargo, cada usuario debe tener una copia separada de la declaracin del rea SQL privada. reas SQL compartidas Un rea SQL Compartida contiene el rbol de anlisis y el plan de ejecucin para una instruccin SQL dada. Se ahorra memoria usando un solo rea SQL compartida para instrucciones SQL ejecutndose varias veces, lo cual ocurre con frecuencia cuando varios usuarios ejecutan la misma aplicacin. Programas PL/SQL y el Pool compartido Oracle procesa programas PL/SQL (procedimientos, funciones, paquetes, bloques annimos, triggers) tanto como procesa instrucciones SQL individuales. Oracle asigna un rea compartida que contiene la forma analizada y compilada del programa. Asigna un rea privada para mantener los valores especficos de la sesin que ejecuta el programa, incluyendo variables locales, globales y de paquete y buffers para ejecucin SQL. Si ms de un usuario ejecuta el mismo programa, entonces una simple rea compartida es usada por todos

los usuarios siempre que tenga una copia de su rea SQL privada, manteniendo valores especficos de su sesin. Las instrucciones SQL individuales estn contenidas en programas PL/SQL. Large Pool El administrador de la base de datos puede configurar un rea de memoria opcional llamado large pool que proporciona grandes cantidades de memoria para asignar:

Memoria de la sesin para el servidor compartido y el Oracle XA interface (usado donde las transacciones interactan con ms de una base de datos) Procesamiento de E/S Copias de seguridad y operaciones de recuperacin

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

parmetro STREAMS_POOL_SIZE. Si un streams pool no est definido, entonces se crea automticamente cuando los flujos se usan por primera vez. Si SGA_TARGET est activo, entonces la memoria del SGA para los Streams pool viene del pool global del SGA. Si no est activo, entonces se transfiere desde la cache del buffer, aunque solo tiene lugar despus del primer uso de los flujos. La cantidad transferida es del 10% del tamao del pool compartido. Cache de diccionario (Dictionary Cache) El diccionario de datos es una coleccin de tablas y vistas de la base de datos que contienen informacin sobre la base de datos (sus estructuras y sus usuarios. Oracle accede con frecuencia al diccionario de datos, por lo que tiene dos localizaciones especiales en memoria designadas a mantenerlo. Una de ellas es la cach del diccionario de datos, tambin conocida como la cache de fila por que contiene datos sobre las filas en vez de los buffers (los cuales contienen bloques de datos), y la otra es el cache de biblioteca.

El parmetro SGA_MAX_SIZE El SGA comprende un nmero de componentes de memoria, denominados pools de memoria, que se usan para satisfacer una clase particular de asignacin de memoria. Todos los componentes del SGA asignan y liberan espacio en unidades (mdulos). El tamao del mdulo queda determinado por el tamao total del SGA. En la mayora de las plataformas el tamao del mdulo es 4MB si el tamao total del SGA es menor de 1GB, y de 16MB para SGA mayores. La base de datos puede configurar lmites sobre cuanta memoria virtual se usa para el SGA. Puede crear instancias con un mnimo de memoria y permitir que la instancia use ms, expandiendo la memoria asignada a los componentes del SGA, hasta un mximo determinado por el SGA_MAX_SIZE. Si el valor es menor que la suma de memoria

asignada para todos los componentes, la base de datos ignora la configuracin de SGA_MAX_SIZE. Para un rendimiento ptimo, en la mayora de los sistemas, todo el SGA debera ajustarse a la memoria real. Si no es as, y la memoria virtual es usada para almacenar partes del SGA, entonces el rendimiento total del sistema puede decrementarse en gran medida. La cantidad de memoria dedicada para todas las reas compartidas en el SGA tambin influye en el rendimiento. El tamao del SGA queda determinado por muchos parmetros, aunque son los siguientes los que tienen un gran efecto sobre el tamao del SGA: Parmetro DB_CACHE_SIZE LOG_BUFFER Descripcin Tamao de la cache de los bloques estndar. Nmero de bytes asignados al redo log buffer.

SHARED_POOL_SIZE Tamao en bytes para el rea dedicada al SQL compartido e instrucciones PL/SQL. LARGE_POOL_SIZE JAVA_POOL_SIZE Tamao del large pool, por defecto es 0. Tamao del java pool.

Gestin automtica de memoria compartida En versiones anteriores el administrador de la base de datos tena que especificar manualmente los tamaos de los diferentes componentes del SGA configurando un nmero de parmetros de inicializacin, que incluan el SHARED_POOL_SIZE, DB_CACHE_SIZE, JAVA_POOL_SIZE, y LARGE_POOL_SIZE. En la versin 10g se incluye la gestin automtica de la memoria compartida que simplifica la gestin de la memoria del SGA. El administrador de la BD puede simplemente especificar la cantidad total de memoria del SGA

disponible para una instancia usando SGA_TARGET y la base de datos automticamente distribuir esta memoria entre varios subcomponentes para asegurar el mayor uso de memoria efectiva. Cuando la gestin automtica de memoria del SGA esta activada, el tamao de los diferentes componentes del SGA es flexible y pueden adaptarse a las necesidades del trabajo sin requerir ninguna configuracin adicional. La base de datos automticamente distribuye la memoria disponible entre varios componentes como se requiera, permitiendo al sistema maximizar el uso de toda la memoria del SGA disponible. Configurando un nico parmetro se simplifica mucho la tarea de administracin ya que puedes especificar solo la cantidad de memoria del SGA que una instancia tiene disponible y olvidarte de los tamaos de los componentes individuales. No se generan errores de out of memory a menos que el sistema se haya quedado sin memoria. La gestin automtica del SGA puede mejorar el rendimiento sin necesidad de recursos adicionales ni ajustes manuales. Con la configuracin manual del SGA es posible que instrucciones SQL compiladas se saquen del pool compartido debido a su insuficiente tamao lo que incrementa la frecuencia de anlisis difciles, que reducen el rendimiento. Cuando la gestin automtica del SGA esta activa, el algoritmo de ajuste interno supervisa el rendimiento del trabajo, incrementando el tamao del pool compartido si reduce el nmero de anlisis requeridos. El parmetro SGA_TARGET El parmetro SGA_TARGET refleja el tamao total del SGA e incluye la memoria para los siguientes componentes:

SGA Fija y otras asignaciones internas necesarias para la instancia. El log buffer El pool compartido El Java pool La cach del buffer Las cachs de los buffers keep y recycle (si son especificados)

El tamao de los bloques no estndar de las cachs de los buffer (si son especificados) El Streams pool

Este incluye toda la memoria del SGA, en diferencia con las versiones anteriores en las que la memoria para la SGA interna y fija se configuraba a travs de otros parmetros. En consecuencia, el SGA_TARGET da un control preciso sobre el tamao de la regin de memoria compartida asignada por la base de datos. Si est configurado con un valor mayor que SGA_MAX_SIZE al inicio, entonces este ltimo se usa como respaldo para el SGA_TARGET. Nota: No configurar dinmicamente el SGA_TARGET. Debera ser configurado solo al inicio. Limitando el tamao de la SGA El parmetro SGA_MAX_SIZE especifica el tamao mximo del SGA durante la duracin de la instancia. Puedes modificar dinmicamente los parmetros que afectan al tamao de las caches de los buffers, del pool compartido, large pool, java pool, y streams pool pero solo para controlar que la suma de estos tamaos y los tamaos de los otros componentes del SGA no exceden el valor especificado por SGA_MAX_SIZE.

REAS GLOBALES DE PROGRAMAS (PGA) reas Globales de Programas PGA (Program Global Areas) Un rea global de programa (PGA) es una regin de memoria que contiene datos e informacin de control para los procesos de servidores. Es una memoria no compartida creada por Oracle cuando un proceso de un servidor es iniciado. Solo el servidor del proceso puede acceder a l y se lee y escribe solamente por un cdigo de Oracle que acta en nombre del proceso. Contenido de un PGA El contenido de la memoria de un PGA vara dependiendo de donde se est ejecutando la instancia y de si el tipo de servidor es compartido. Pero generalmente la memoria del PGA puede ser clasificada de la siguiente forma: -Memoria de sesin: La memoria de sesin (Session Memory) se asigna para mantener las variables de una sesin (logon information) y otra informacin relativa a la sesin. Para un servidor compartido, la memoria de sesin es compartida y no privada. -rea SQL privada: Un rea SQL privada contiene datos como por ejemplo consultas de informacin de ejecuciones y consultas de ejecuciones en reas de trabajo. Cada sesin que establece una sentencia tiene un rea privada de SQL. Cada usuario que emite la misma sentencia tiene su propia rea SQL privada que usa un rea SQL compartida. Aunque, muchas reas SQL privadas pueden ser asociadas con la misma rea SQL compartida. La ubicacin de un rea privada SQL depende del tipo de conexin establecida para una sesin. Si una sesin se conecta a travs de un servidor dedicado, las reas privadas SQL esta localizadas en el servidor del proceso del PGA. De cualquier forma, si una sesin se conecta a travs de un servidor compartido, parte del rea privada SQL se mantiene en el SGA. Cursores y reas SQL

La aplicacin de desarrollo de un programa precompilador Oracle o un programa OCI puede explcitamente abrir cursores, o manejar algn rea privada SQL especfica, y usarla como un recurso nombrado a travs de la ejecucin de un programa. Los cursores recursivos de Oracle que emiten implcitamente algunas sentencias SQL tambin usan reas SQL. La administracin de las reas SQL privadas son responsabilidad de los procesos del usuario. La asignacin y liberacin de las reas SQL privadas dependen de en que herramienta de la aplicacin se usan, aunque el numero de reas SQL privadas que un proceso de usuario puede asignar est siempre limitada el parmetro OPEN_CURSORS. El valor por defecto de este parmetro es 50. Un rea SQL privada continua existiendo hasta que el correspondiente cursor es cerrado o la sentencia es liberada. Aunque Oracle libera el rea de ejecucin despus de que la sentencia se complete, el rea persistente se mantiene en espera. Las aplicaciones de desarrollo cierran todos los cursores abiertos que no van a ser usados otra vez para liberar el rea persistente y minimizar la cantidad de memoria requerida por el usuario de la aplicacin. Componentes del rea SQL privada El rea SQL privada de un cursor se divide en 2 reas cuya duracin son diferentes:

El rea persistente (Persistent Area), que contiene, por ejemplo, informacin envuelta. Es liberada solamente cuando el cursor es cerrado. El rea de ejecucin (Run-time Area), que es liberada cuando la ejecucin, valga la redundancia, es terminada.

Oracle crea el rea de ejecucin en el primer paso que una ejecucin es pedida. Para una sentencia INSERT, UPDATE y DELETE Oracle libera el rea de ejecucin despus de que la sentencia ha sido ejecutada. Para las consultas, Oracle libera el rea de ejecucin solamente cuando todas las filas han sido recorridas, o la consulta ha sido cancelada. reas de trabajo SQL

Para las consultas complejas, una gran porcin del rea de ejecucin es dedicada a reas de trabajo asignadas por operadores de memoriaintensiva como los siguientes:

Operadores de base de clasificacin Sort-based (order by, group by, rollup) Hash-join Bitmap merge Bitmap create

Por ejemplo, un operador de clasificacin (sort operator) usa un rea de trabajo (algunas veces llamado rea de clasificacin sort area) para la forma de distribucin de la memoria interna (in-memory) de una serie de filas. Similarmente, un operador hash-join usa un rea de trabajo (tambin llamada rea hash) para construir una tabla hash desde su entrada izquierda. Si la cantidad de datos que deben ser procesados por estos dos operadores no entran en el rea de trabajo, entonces los datos de entrada son divididos en piezas ms pequeas. Esto permite que alguna de las piezas se procesen en la memoria mientras el resto son distribuidos en un disco temporal para ser procesado luego. Aunque los operadores de bitmap no se distribuyen por el disco cuando su rea de trabajo es muy pequea, su complejidad es inversamente proporcional al tamao de su rea de trabajo. Estos operadores se ejecutan ms rpido en reas de trabajo ms grandes. El tamao del rea de trabajo puede ser controlado y modificado. Generalmente, reas de bases de datos grandes pueden mejorar significativamente el rendimiento de un operador respecto al coste de consumo de memoria. Opcionalmente, el tamao de un rea de trabajo puede ser lo bastante grande como para almacenar los datos de entradas y las estructuras auxiliares de memoria asignadas por el operador SQL asociado. De lo contrario, el tiempo de respuesta aumenta, porque parte de los datos de entrada deben ser distribuidos por un disco de almacenamiento temporal. En caso extremo, si el tamao del rea de trabajo es muy pequeo comparado con el tamao del dato de entrada, mltiples procesos se ejecutan sobre la parte de los datos. Esto puede aumentar el tiempo de respuesta de un operador considerablemente.

Administracin de la memoria del PGA para un modo dedicado Se puede administrar el tamao de las reas de trabajo SQL globalmente y automticamente. El administrador de la base de datos simplemente necesita que sea especificado el tamao total dedicado a la memoria del PGA para las instancias de configurando el parmetro PGA_AGGREGATE_TARGET. El nmero especificado (por ejemplo 2G) es un objetivo global para la instancia, y se trata de asegurar que la cantidad total de memoria del PGA asignada por toda la base de datos de los procesos del servidor nunca exceda esa meta. Con PGA_AGGREGATE_TARGET, modificar el tamao de las reas de trabajo para todas las sesiones dedicadas es automtico, y todos los parmetros *_AREA_SIZE se ignoran en estas sesiones.

AREA DE ORDENACIONES (SORT AREAS) Las reas de ordenaciones (Sort Areas) de Oracle son las zonas de memoria en las que se ordenan los datos, es decir el espacio en memoria que necesita la organizacin y ordenacin de las filas. El tamao por defecto, expresado en bytes, es especfico de cada SO. Sin embargo, hay muchas razones importantes por las que este tamao influye en el rendimiento. En el manual de Oracle 10i encontramos cuatro de ellas:

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

Grandes valores en este campo nos permitirn realizar mayores bsquedas en memoria. Si se necesitase ms espacio para la ordenacin del que tenemos, los datos se dividirn en trozos y se utilizarn segmentos de disco temporales como apoyo en la ordenacin.

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

Para un mejor rendimiento del SGBD, la mayora de las ordenaciones deberan tener lugar nicamente en memoria ya que en caso de tener que escribir a disco, obtendremos un claro efecto adverso sobre ste. Si las aplicaciones que acceden a la base de datos suelen realizar bsquedas que no caben en el rea de ordenaciones, o incluso si las aplicaciones realizan demasiadas bsquedas innecesarias, entonces sera conveniente modificar el parmetro de SORT_AREA SIZE. El SORT_AREA_SIZE es un parmetro que se puede inicializar y modificar dinmicamente y que especifica la cantidad de memoria que se tiene disponible al realizar las ordenaciones. Si una cantidad importante de ordenaciones requiere acceso a disco para almacenar segmentos temporales, entonces la aplicacin se ver claramente beneficiada al ampliar el SORT_AREA_SIZE. De forma alternativa, en un entorno DSS, aumentar este parmetro no tiene por qu hacer que la ordenacin se realice nicamente en memoria, pero s es cierto que dependiendo del valor actual y del nuevo elegidos, se puede aumentar drsticamente la velocidad de la ordenacin.

Por lo tanto, como conclusin, alterar este parmetro, se puede considerar como un paso importante para asegurarnos el rendimiento en ciertas circunstancias y situaciones. Sin embargo, determinar qu valor es el ms apropiado, es por supuesto, la parte ms complicada. MEMORIA VIRTUAL EN ORACLE

Oracle puede utilizar la memoria virtual proporcionada por el SO para simular memoria a base de algn dispositivo de almacenamiento como el disco duro. La memoria virtual est mapeada en la RAM. Cuando no hay suficiente memoria con sta para ejecutar los programas (en caso de Oracle las sentencias, bsquedas, etc) se necesita un espacio auxiliar que normalmente suele ser el disco duro. Para el traspaso de informacin se utilizan dos tcnicas principales: el Paging o paginacin y el Swapping.

Paginacin La paginacin consiste en dividir los programas en pequeos bloques o pginas, de manera que sea ms fcil moverlos de memoria a disco y viceversa. De la misma forma, la memoria se divide en marcos de pgina. De esta forma, la cantidad de memoria desperdiciada por un proceso es el final de su ltima pgina, minimizando as la fragmentacin interna y evitando la externa. En un momento cualquiera, la memoria se encuentra ocupada con pginas de diferentes procesos, mientras que algunos marcos estn disponibles para su uso. El sistema operativo mantiene una lista de estos ltimos marcos, y una tabla por cada proceso, donde consta en qu marco se encuentra cada pgina del proceso. De esta forma, las pginas de un proceso pueden no estar contiguamente ubicadas en memoria, y pueden intercalarse con las pginas de otros procesos. En la tabla de pginas de un proceso, se encuentra la ubicacin del marco que contiene a cada una de sus pginas. Las direcciones lgicas ahora se forman como un nmero de pgina y de un desplazamiento dentro de esa pgina (conocido comnmente como offset). El nmero de pgina es usado como un ndice dentro de la tabla de pginas, y una vez obtenida la direccin del marco de memoria, se utiliza el desplazamiento para componer la direccin real o direccin fsica. Este proceso se realiza en una parte del ordenador especficamente diseada para esta tarea, es decir, es un proceso hardware y no software.

De esta forma, cuando un proceso es cargado en memoria, se cargan todas sus pginas en marcos libres y se completa su tabla de pginas.

Swapping El Swapping es el procedimiento de mover los bloques de memoria en los que estn algunos procesos que no se estn utilizando, desde la memoria principal a un espacio Swap dejando as hueco libre para poder cargar en memoria otros procesos que s se van a utilizar. El espacio Swap o espacio de intercambio es una zona de disco (un fichero o una particin) que se usa para guardar las imgenes de los procesos que no han de mantenerse en memoria fsica. Este procedimiento es muy similar a la paginacin, con la diferencia principal de que el directorio Swap funciona exactamente igual que la memoria RAM, por lo que puede almacenar datos privados, contraseas y todo lo que almacena sta. Sin embargo, en la paginacin, nicamente se sacan de memoria pginas pertenecientes a procesos que no se estn utilizando, adems de que se pueden sacar solo algunas pginas de los procesos y no stos enteros como se hace en el Swapping. Con respecto al tamao que debe tener el directorio Swap, hay muchas discusiones sobre ello como por ejemplo la antigua creencia de El Swap debe tener el doble de tamao que la RAM. cosa que no es vlida hoy da debido a la gran capacidad de la memoria RAM de la mayora de ordenadores. Como conclusin, hay que destacar que el uso de la memoria virtual por parte de Oracle, va a influir bastante en el rendimiento, disminuyndolo drsticamente en comparacin con el uso nicamente de la memoria RAM.

REA DE CDIGO DE SOFTWARE (SCA) El rea de cdigo de software son zonas de memoria destinadas a almacenar el cdigo de Oracle en ejecucin o que puede ejecutarse. Este cdigo de Oracle se almacena en una zona distinta, y ms protegida, que las zonas dedicadas a almacenar los cdigos de programas de usuarios. La SCA suele ser de tamao esttico, cambiando nicamente cuando el software se reinstala o actualiza. El tamao requerido para este rea puede variar en funcin del SO. Son reas de slo lectura y pueden ser instalas de forma compartida o no compartida. Cuando es posible, el cdigo de Oracle se comparte, por lo que todos los usuarios pueden acceder a l sin tener mltiples copias en memoria. El resultado es un ahorro considerable de memoria y una mejora del rendimiento general. Por otra parte, los programas de usuario tambin pueden ser compartidos o no. Algunas utilidades y herramientas de Oracle (como ocurre con Oracle Forms y SQL*Plus) pueden ser instalados de forma compartida, pero otras no. Mltiples instancias de Oracle pueden usar la misma SCA con diferentes bases de datos si estn corriendo en la misma mquina. Hay que tener en cuenta que la opcin de instalar software compartido puede no estar disponible en funcin del sistema operativo, como ocurre por ejemplo en mquinas con Windows.

Estructura de los procesos Cuando un usuario se conecta a una base de datos de Oracle ejecuta dos mdulos de cdigo diferentes, que adems el encargado de gestionar estos procesos es el sistema operativo, estos dos mdulos diferentes son: -Aplicacin o Herramienta Oracle: normalmente son programas clientes que se conectan a la base de datos y permiten ejecutar sentencias SQL. Ej.: SQL*Plus, SQL developer -Cdigo del servidor de Oracle: son los diferentes procesos que se han de ejecutar en el servidor para atender las peticiones del usuario. La base de datos Oracle es un sistema multiproceso, lo que significa que no toda la base de datos est corriendo en un mismo proceso, si no que varias partes de la base de datos se ejecuta concurrentemente. Permitiendo a mltiples usuarios conectarse a la misma vez, y mayor rapidez en el tiempo de respuesta, puesto que siempre que pueda va a utilizar al mximo al ordenador, por ejemplo si tiene ocho ncleos el servidor, y resulta que una peticin se puede paralelizar se ejecutara esa peticin por partes en cada ncleo. De los procesos que se ejecutan en el servidor podemos hacer dos grandes grupos: -Procesos de usuarios: Cada vez que un usuario ejecuta una aplicacin, ya sea propia o de Oracle se crea un proceso, que puede ser de dos tipos. >conexin: Que es la va de comunicacin entre la aplicacin y la instancia de la base de datos a la que se ha conectado.

>sesin: Es la conexin especfica con la base de datos proporcionando un usuario y su contrasea. Esto permite que desde un mismo equipo se puedan conectar varios usuarios simultneamente, y que un usuario se pueda conectar desde diferentes equipos simultneamente. -Procesos de Oracle: Son propios de la base de datos, y el usuario no tiene control sobre ellos, pueden ser de dos tipos: >Procesos de servidor: Se crea cuando una aplicacin intenta acceder a la base de datos, para atender a las peticiones de la aplicacin y devolver los resultados que se precisen.

>Procesos de background: Se crean cuando se inicia una instancia de la base de datos, solo hay un proceso de cada tipo de los que especificaremos a continuacin, y no han de estar todos siempre presentes en el servidor. Se utilizan para realizar labores de mantenimiento, y para guardar la integridad de la base de datos. Los diferentes tipos de procesos son los siguientes:

Database Writer Process (DBWn) El (DBWn) escribe el contenido de los buffers en los archivos de datos. El proceso DBWn es responsable por la escritura de los buffers modificados del buffer cache al disco. El proceso DBWn escribe buffers modificados al disco bajo las siguientes condiciones:

- Cuando un proceso no puede encontrar un buffer limpio reusable despus de haber recorrido un nmero de determinado de buffers en el buffer cach, ste enva una seal al DBWn para la escritura. El DBWn escribe los buffers sucios al disco. -El DBWn peridicamente escribe los buffers cuando se lleva a cabo un checkpoint. Chekpoint es una posicin en el hilo de redo (log) donde se iniciar luego la recuperacin. La posicin en el log est determinada por el ltimo buffer sucio en el buffer cach. Log Writer Process (LGWR) El proceso LGWR es responsable del manejo del redo log buffer, las escrituras del redo log buffer al archivo de redo log en el disco. El LGWR escribe todos los registros de redo que han sido copiados en el buffer desde la ltima vez que ste se escribi. El redo log buffer es un buffer circular. Cuando LGWR escribe los registros del redo log buffer al redo log file, el proceso servidor puede copiar nuevos registros sobre aquellos que se pasaron a disco. LGWR normalmente escribe lo suficientemente rpido para asegurar que el espacio est siempre disponible en el buffer para nuevos registros, an cuando la escritura al redo log file sea lenta. LGWR escribe en porciones contiguas del buffer al disco. El LGRW escribe: - Un registro de commit cuando un usuario hace commit de una transaccin - Redo log buffers: -cada tres segundos -cuando el redo log tenga un tercio lleno -cuando un proceso de DBWn escriba los buffers modificados a disco, si es necesario.

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

Los archivos de redo log trabajan de forma circular porque se sobrescriben, generalmente con los tres grupos se tendr que uno de ellos se encontrar activo, el siguiente en enumeracin ser el actual y el siguiente estar inactivo listo para que se escriba en l. Una vez llenado el grupo actual se comenzar a escribir en el inactivo, que ahora ser el actual, el que anteriormente era el actual pasar a ser activo si an no se han escrito todas sus transacciones a disco y eventualmente el que inicialmente estaba activo pasar a ser inactivo y permitir que al llenarse el grupo actual se escriban las transacciones en l. Si se llenara el grupo actual de los archivos de redo y el resto de los grupos se encontraran activos, la base de datos no permitira ninguna transaccin hasta que se escriban todas las transacciones a disco del siguiente grupo de redo log y que este quedase inactivo. Cuando se trabaja con una base de datos en modo ARCHIVELOG, antes de sobrescribir el archivo se hace una copia de ese grupo de redo log al destino de los archivos. Checkpoint Process (CKPT) El CKPT lleva a cabo un checkpoint, entendindose como tal a la escritura parcial o completa de los buffers de memoria a disco. El CKPT no es el responsable de escribir los bloques a disco, para ello llama al DBWn y como en esa escritura podran almacenarse en disco buffers de transacciones no comprometidas el CKPT tambin llama al LGWR para que registre en los redo log files esta escritura que permita generar los segmentos de undo de transacciones no comprometidas cuando se realice una recuperacin incompleta. Tambin si en la escritura del checkpoint hay transacciones que no se haban terminado de escribir en disco se escriben, se actualiza la cola de transacciones activas y un grupo de redo log que estaba activo podra pasar a inactivo. Cuando un checkpoint ocurre, Oracle debe actualizar todas las cabeceras de los archivos de datos con los detalles del checkpoint, sta es una tarea del CKPT.

System Monitor Process (SMON) El proceso SMON lleva a cabo la recuperacin, si es necesaria, de la instancia en el inicio de la misma, es decir rehacer cualquier transaccin comprometida en el redo log file que no haya sido escrita a disco. SMON tambin es responsable de limpiar los segmentos temporales que no estn en uso por algn tiempo y de desfragmentar si cree oportuno alguna zona de los discos. Process Monitor (PMON) PMON lleva a cabo procesos de recuperacin cuando un proceso de usuario falla. Es responsable de la limpieza del buffer cach, tambin de deshacer los cambios que se hayan hecho desde el ultimo commit y de la liberacin de recursos que el proceso estaba usando. Por ejemplo este restaura el status de la tabla de transacciones activas, libera los locks y remueve el ID del proceso de la lista de procesos activos, asociados a un proceso usuario que pudo haber perdido la conexin de red. Recoverer (RECO) Este proceso solo se observa cuando la base de datos ejecuta la opcin distribuida de Oracle. La transaccin distribuida es una en la que dos o ms emplazamientos de datos deben mantenerse sincronizados, Por ejemplo cuando se tiene una copia de los datos en diferentes ciudades y por fallas en una lnea telefnica se pierde una transaccin en la mitad de su actualizacin. El proceso recuperador entonces resuelve las transacciones que hayan quedado inconsistentes en las dos ciudades. Archiver Processes (ARCn) El ARCn copia los archivos de redo log llenos a un espacio de almacenamiento distinto para no perderlos al ser sobreescritos. El ARCn slo est habilitado cuando la base de datos est en el modo ARCHIVELOG. En Oracle 10g para colocar la base de datos en modo

archive basta con colocarla en modo ARCHIVELOG y especificar los destinos de "archive". En Oracle 9i se distingua entre el "archive" manual y automtico. Con "archive" manual el DBA deba ordenar hacer la copia de los redo log a los "archives", en el modo automtico se copiaban automticamente antes de ser sobrescritos. En Oracle 10g al poner una base de datos en modo ARCHIVELOG automticamente se coloca en el modo automtico. Lock (LCKn) Es un proceso opcional, configurado para manejar los bloqueos entre bases de datos Oracle cuando estas se encuentran en distintos computadores y compartiendo el mismo conjunto de discos (es decir en modo servidor en paralelo). Job Queue (SNPn) Es un proceso opcional, que se encarga de planificar los procesos que se deben ejecutar y asegurar que todos deben de terminar en algn momento. Queue Monitor (QMNn) QMNn es un proceso opcional de background para el encolamiento avanzado de Oracle, que monitorea las colas de mensajes. El encolamiento avanzado se usa con comunicacin asncrona. Los procesos envan los mensajes y en lugar de esperar por la respuesta siguen con su trabajo. Dispatcher (Dnnn) Es un proceso opcional que permite a los usuarios compartir procesos de servidor. Permitiendo que se conecten mltiples usuarios al mismo servidor. Shared Server (Snnn)

Este tipo proceso se encarga de atender a cada uno de los clientes conectados a la base de datos compartiendo los procesos del servidor.

EJERCICIOS
Ejercicio 1
En cuntas partes se divide la memoria? En 5 partes: SGA, PGA, rea de ordenaciones, memoria virtual y SCA.

Ejercicio 2
Qu es el SGA? Con qu otro nombre se le conoce? Es el System Global Area, un grupo de estructuras de la memoria compartida que contiene datos e informacin de control de una instancia de una base de datos. Tambin es conocido como Shared Global Area.

Ejercicio 3
Qu es una instancia? Es una combinacin del SGA y todos los procesos de una base de datos.

Ejercicio 4
De qu se compone el SGA? El SGA se compone de: -Cach de los Buffers de la BD - Redo Log Buffer -Pool compartido -Large Pool -Java Pool

-Streams Pool -Cach de diccionario

Ejercicio 5
Indica tres parmetros que influyan en el tamao del SGA. Los parmetros que influyen en el tamao del SGA son: SGA_MAX_SIZE, DB_CACHE_SIZE, LOG_BUFFER, SHARED_POOL_SIZE, LARGE_POOL_SIZE, JAVA_POOL_SIZE, SGA_TARGET.

Ejercicio 6
En qu dos listas estn organizados la cach de los buffers? En la lista en espera (contiene los buffers en espera o dirty buffers) y la lista LRU (contiene los buffers libres, los pinned buffers y los buffers en espera que an no estn en la lista en espera)

Ejercicio 7
De forma general nombrar cual es el contenido de la memoria de un PGA rea SQL privada y Memoria de sesin

Ejercicio 8
Conteste Verdadero o Falso 1. Es necesario conocer todos los tamaos de la PGA a la hora de administrar la BD Falso. El administrador solo necesita conocer el tamao global del PGA configurando el parmetro inicial PGA_AGGREGATE_TARGET de tal forma que el administrador de la base de datos 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. 2. Existen vistas que contengan las estadsticas de uso de la memoria del PGA Cierto. La mayora de estas estadsticas se permiten cuando se activa PGA_AGGREGATE_TARGET 3. La forma de distribucin de memoria puede afectar en el rendimiento de un operador

Cierto. Vase reas de trabajo SQL.

Ejercicio 9
Define brevemente como puede influir el tamao del rea de ordenacin en el rendimiento del sistema. El tamao del rea de ordenacin, SORT_AREA_SIZE influye debido a que, en caso de que los datos a ordenar no quepan en el rea de ordenacin, se tienen que dividir en trozos que s quepan y para luego ordenarlos por separado y mezclarlos. Por tanto, el rendimiento es menor.

Ejercicio 10
Diferencias entre Paging y Swapping En el Paging se dividen los programas en pginas y la memoria en marcos de pgina que hacen referencia a ellas. Esto no ocurre en el Swapping, en el que toda la memoria se divide en bloques y se tiene un directorio Swap con el que se intercambian dichos bloques. Adems, en el Swapping se mueven al directorio Swap procedimientos completos que no estn activos o se activan poco, en vez de nicamente trozos de estos como pasa en el Paging.

Ejercicio 11
Caractersticas del rea de cdigo en Oracle Suele ser de tamao esttico, cambiando nicamente cuando se actualiza o reinstala el software. El tamao requerido puede variar en funcin del SO. Son reas de slo lectura y pueden ser instaladas de forma compartida o no compartida.

Permite que el cdigo de Oracle est instalado una sola vez para mltiples usuarios sin necesidad de ms tener ms copias en memoria. Permite que los usuarios compartan aplicaciones y utilidades de Oracle para ahorrar memoria y mejorar el rendimiento.

Ejercicio 12
En qu dos grandes grupos se dividen los procesos en Oracle? Se dividen en procesos de usuario y procesos de Oracle.

Ejercicio 13
Test 1-Qu nombre recibe la lectura directa de memoria cuando un proceso busca en la Buffer Cach? A-Cach miss B-Cach hit C-Cach win 2-Qu parmetro determina el tamao total del SGA? A-SGA_TARGET B-SGA_MAX_SIZE C-SGA_TARGET_SIZE 3-Las dos reas en las que se divide el rea SQL privada son: A-Persistent Area y SQL Area B-Run-time Area y Persistent Area C-Run-time Area y Super Area 4-Dnde se mapea la memoria virtual en Oracle?

A-En la ROM B-En la SRAM C-En la RAM 5-Qu dos tcnicas se utilizan para el traspaso de informacin? A-La paginacin y el traspasing B-El traspasing y el swapping C-Ninguna de las anteriores 6-Cul es el tamao requerido para el SCA? A-Depende del tamao de la memoria B-Depende del Sistema Operativo C-4Gb 7-Qu es una conexin? A-El puente entre la base de datos y el cliente. B-La conexin con un usuario especifico. C-Cada hoja abierta en el SQL developer. 8-Qu es una sesin? A-El puente entre la base de datos y el cliente. B-La conexin con un usuario especifico. C-Cada hoja abierta en el SQL developer. 9-Qu procesos se crean en el servidor cada vez que se intenta acceder a la base de datos? A-Procesos de usuario.

B-Procesos de servidor. C-Procesos de background. 10-Qu procesos son los encargados del mantenimiento de la base de datos? A-Procesos de usuario. B-Procesos de servidor. C-Procesos de background.

11-El proceso log writter process escribe los buffers de redo cada vez que A-Cada tres segundos. B-Cada vez que se hace un commit. C-Las dos anteriores son correctas. 12-Proceso de checkpoint A-Se encarga de grabar los cambios al disco duro. B-Manda seales a otros procesos para que realicen sus tareas. C-Guarda los buffers de redo en el disco. 13-Los ficheros de redo log A-Siempre se sobrescriben. B-Cuando se llenan son guardados en otro disco automticamente. C-Son tres: activo, actual e inactivo. 14-Los procesos en background

A-Son controlados por el usuario. B-Han de estar siempre presentes en el servidor. C-Ninguna es correcta.

MySQL Arquitectura de MySQL

La arquitectura de MySQL1 tiene como caracterstica ms notable el separar el motor de almacenamiento (que se encarga de los detalles de entrada-salida y representacin de la informacin en memoria secundaria) del resto de los componentes de la arquitectura. Es decir, el diseo del gestor est preparado para que se pueda cambiar el gestor de almacenamiento. Esto permite incluso crear nuevos motores de almacenamiento especializados para ciertas tareas o tipos de aplicaciones.

Arquitectura lgica de MySQL

La siguiente figura es una visin abstracta de la arquitectura lgica de MySQL. La figura hace una divisin entre los componentes que conforman el servidor, las aplicaciones cliente que lo utilizan y las partes del sistema operativo en las que se basa el almacenamiento fsico.

Las utilidades y herramientas de MySQL son los programas y aplicaciones que se incluyen con la distribucin del gestor, o que pueden instalarse como aplicaciones adicionales. Estas incluyen las herramientas de backup, el navegador de consultas (QueryBrowser),

las aplicaciones administrativas de interfaz grfico y la herramienta de diseo MySQL Workbench, entre otras Motores de almacenamiento
El elemento ms notable de la arquitectura de MySQL es la denominada arquitectura de motores de almacenamiento reemplazables (pluggable storage engine architecture). La idea de esa arquitectura es hacer una interfaz abstracta con funciones comunes de gestin de datos en el nivel fsico. De ese modo, el gestor de almacenamiento puede intercambiarse, e incluso un mismo servidor MySQL puede utilizar diferentes motores de almacenamiento para diferentes bases de datos o para diferentes tablas en la misma base de datos. Esto permite utilizar el motor de almacenamiento ms adecuado para cada necesidad concreta. Tambin permite que terceros puedan implementar motores de almacenamiento nuevos para necesidades especficas, o adaptar el cdigo de los existentes a ciertos requisitos de almacenamiento. As, las interfaces definidas por MySQL aslan el resto de los componentes de la arquitectura de las complejidades de la gestin fsica de datos, facilitando el mantenimiento de los motores de almacenamiento. Tambin esto permite que ciertos motores de almacenamiento no implementen parte de los servicios, lo cual les hace inapropiados para algunas aplicaciones pero ms eficientes para otros. Por ejemplo, un motor de almacenamiento que no implementa bloqueos en la base de datos no debe utilizarse en aplicaciones multi-usuario, pero la ausencia de sobrecarga de procesamiento en la gestin de los bloqueos para el acceso concurrente lo har mucho ms eficiente para una aplicacin monousuario. En consecuencia, una primera tarea de diseo fsico en MySQL es la de decidir el motor de almacenamiento ms apropiado. Los elementos que puede implementar un motor de almacenamiento son los siguientes:

Concurrencia. Es responsabilidad del motor implementar una poltica de bloqueos (o no implementar ninguna). Una estrategia de bloqueos por fila permite una mayor concurrencia, pero tambin consume ms tiempo de procesamiento en aplicaciones en las que la concurrencia no es realmente grande. Soporte de transacciones. No todas las aplicaciones necesitan soporte de transacciones. Comprobacin de la integridad referencial, declarada como restricciones en el DDL de SQL. Almacenamiento fsico, incluyendo todos los detalles de la representacin en disco de la informacin. Soporte de ndices. Dado que la forma y tipo de los ndices depende mucho de los detalles del almacenamiento fsico, cada

motor de almacenamiento proporciona sus propios mtodos de indexacin (aunque algunos como los rboles B casi siempre se utilizan). Cachs de memoria. La eficiencia de los cachs de datos en memoria depende mucho de cmo procesan los datos las aplicaciones. MySQL implementa cachs comunes en el gestor de conexiones y la cach de consultas, pero algunos motores de almacenamiento pueden implementar cachs adicionales. Otros elementos para ayudar al rendimiento, como puede ser el uso de mltiples hilos para operaciones paralelas o mejoras de rendimiento para la insercin masiva.

Adems de lo anterior, los motores de almacenamiento pueden implementar caractersticas no comunes, como la gestin de tipos de datos geoespaciales, o cualquier funcin adicional especfica de cierto tipo de aplicaciones. La implementacin de un gestor de almacenamiento implica escribir un software con una interfaz en lenguaje C, que implemente una biblioteca de funciones (storage engine API) que es la que el servidor MySQL invoca para pedir los servicios al gestor. Por ejemplo, si estamos implementando un gestor de almacenamiento, una de las funciones es la que crea una nueva tabla, que tiene la siguiente signatura.
int ha_tina::create(const char *name, TABLE *table_arg, HA_CREATE_INFO *create_info) { ... }

El parmetro name es, como cabe esperar, el nombre de la nueva tabla, y TABLE es una estructura que representa el esquema de la tabla. Las opciones de creacin estn en create_info, que incluye, por ejemplo, la asociacin con ndices, restricciones en el tamao de la tabla, etc. MySQL crea una representacin del esquema de las tablas independiente del motor de almacenamiento, en ficheros denominados nombretabla.frm, uno por cada tabla del esquema. TABLE es una referencia a esa representacin.

Cmo seleccionar el motor de almacenamiento?

No hay una receta nica que permita definir el motor de almacenamiento. La seleccin debe hacerse una vez tenemos el modelo lgico de la base de datos y conocemos los

requisitos de rendimiento y no funcionales de la aplicacin o aplicaciones que vamos a construir. La sentencia SHOW ENGINES nos muestra la lista de motores en MySQL, incluyendo el motor por defecto y los que no estn disponibles con la configuracin actual. El resultado para MySQL 5.1. es el siguiente:

Engine MyISAM

Comment Default engine as of MySQL 3.23 with great performance MEMORY YES Hash based, stored in memory, useful for temporary tables InnoDB DEFAULT Supports transactions, row-level locking, and foreign keys BerkeleyDB NO Supports transactions and page-level locking BLACKHOLE YES /dev/null storage engine (anything you write to it disappears) EXAMPLE NO Example storage engine ARCHIVE YES Archive storage engine CSV NO CSV storage engine ndbcluster NO Clustered, fault-tolerant, memory-based tables FEDERATED YES Federated MySQL storage engine MRG_MYISAM YES Collection of identical MyISAM tables ISAM NO Obsolete storage engine De la tabla anterior solo podemos tener nociones iniciales del tipo de gestor, y dirigirnos a alguno de ellos para casos concretos, por ejemplo, ndbcluster tiene caractersticas nicas si necesitamos soporte para alta disponibilidad. No obstante, hace falta conocer ms en profundidad las caractersticas de cada uno para tomar decisiones, y en ocasiones es necesario hacer pruebas de rendimiento con varios de ellos para compararlos y seleccionar el que mejor se ajusta a nuestras necesidades.

Support YES

Los conectores
Los conectores son bibliotecas en diferentes lenguajes de programacin que permiten la conexin (remota o local) con servidores MySQL y la ejecucin de consultas. Por ejemplo, el conector Connector/J permite conectarse a MySQL desde cualquier aplicacin programada en lenguaje Java, y utilizando el Java Database Connectivity (JDBC) API.

El gestor de conexiones
La gestin de conexiones es responsable de mantener las mltiples conexiones de los clientes. Un gestor de conexiones inexistente o laxo simplemente creara una conexin por cada cliente conectado. No obstante, las conexiones consumen recursos de mquina, y crearlas y destruirlas son tambin procesos costosos. Por eso, el gestor de conexiones de MySQL puede configurarse para limitar el nmero de conexiones concurrentes, y tambin implementa un pool de conexiones. La idea es que muchas aplicaciones abren una conexin y la mantienen abierta y ociosa durante mucho tiempo (por ejemplo, durante toda la sesin de un usuario, que de vez en cuando se levanta para diferentes tareas mundanas como tomar caf), y solo de vez en cuando se utiliza un hilo de ejecucin para ejecutar una consulta, que adems, tpicamente tarda como mucho unos milisegundos. No tiene sentido mantener una conexin ociosa para cada usuario. De aqu proviene la idea de los pools de conexiones: hay un nmero de conexiones disponibles, y cada vez que una aplicacin hace una solicitud, se le asigna una conexin del pool que no est ocupada. Lgicamente, la aplicacin cliente no es consciente de este mecanismo. En trminos por ejemplo, de las interfaces JDBC, esto quiere decir que cada vez que enviamos una sentencia con llamadas como Statement.executeQuery() realmente puede que se cree una nueva coleccin, o quiz se tome una del pool. Es decir, las llamadas a Driver.getConnection() y a Connection.close() no siempre determinan el tiempo de vida de una conexin real en MySQL. Adems de la reduccin en el tiempo de establecimiento de conexin (si se reusa una conexin ya creada del pool), la tcnica permite limitar el nmero de conexiones simultneas. Dado que las conexiones consumen recursos, es mejor limitar este nmero que llevar a una carga excesiva en el servidor, que podra acabar en una cada del sistema o un comportamiento impredecible. Ntese que gracias a los pools de conexiones, puede darse servicio a muchas conexiones concurrentes con un nmero limitado de conexiones que se reutilizan. El gestor de conexiones tambin se ocupa de la autentificacin de los usuarios. La autentificacin por defecto se basa en el nombre de usuario, la mquina desde la que se conecta y la password. El servidor puede tambin configurarse para soportar certificados X.509.

El procesamiento y optimizacin de consultas

Cada vez que una consulta llega al gestor de MySQL, se analiza sintcticamente y se produce una representacin intermedia de la misma. A partir de esa representacin, MySQL toma una serie de decisiones, que pueden incluir el determinar el orden de lectura de las tablas, el uso de ciertos ndices, o la re-escritura de la consulta en una forma ms eficiente. Existe la posibilidad de utilizar ciertas clusulas en las consultas para ayudar al optimizador en su tarea, o bien podemos pedirle al servidor ciertas explicaciones sobre cmo ha planificado nuestras consultas, para entender mejor su funcionamiento. Dado que la optimizacin de las consultas depende de las capacidades del gestor de almacenamiento que se est utilizando, el optimizador pregunta al gestor si soporta ciertas caractersticas, y de este modo, puede decidir el tipo de optimizacin ms adecuado.

La cach de consultas
MySQL implementa un cach de consultas, donde guarda consultas y sus resultados enteros. De este modo, el procesador de consultas, antes ni siquiera de plantear la optimizacin, busca la consulta en la cach, para evitarse realizar el trabajo en el caso de que tenga suerte y encuentre la consulta en la cach.

El Control de Concurrencia
El control de concurrencia en un gestor de bases de datos es simplemente el mecanismo que se utiliza para evitar que lecturas o escrituras simultneas a la misma porcin de datos terminen en inconsistencias o efectos no deseados. El mecanismo que se utiliza para controlar este acceso es el de los bloqueos (locks). La idea es muy simple, cada vez que una aplicacin quiere acceder a una porcin de los datos, se le proporciona un bloqueo sobre los mismos. Lgicamente, varias aplicaciones que quieran leer simultneamente no tienen ningn problema en hacerlo, de modo que para la lectura se proporcionan bloqueos compartidos (shared locks). Sin embargo, varios escritores o un escritor simultneo con lectores puede producir problemas. Por eso, para la escritura se proporcionan bloqueos exclusivos (exclusive locks). Aunque la idea parece simple, hay que tener en cuenta que la obtencin y liberacin de los bloqueos se realiza continuamente, y esto produce una sobrecarga en el procesamiento dentro del servidor. Adems, hay diferentes polticas de bloqueo, por ejemplo, es mejor bloquear cada tabla completa afectada o solo las filas de la tabla a las que quiere acceder una consulta?. Dada la existencia de diferentes tcnicas, el control de concurrencia en MySQL se divide entre el servidor y cada gestor de almacenamiento.

La gestin de transacciones y recuperacin

La gestin de transacciones permite dotar de semntica todo o nada a una consulta o a un conjunto de consultas que se declaran como una sola transaccin. Es decir, si hay algn problema y parte de la consulta o algunas de las consultas no consiguen llevarse a cabo, el

servidor anular el efecto parcial de la parte que ya haya sido ejecutada. La recuperacin permite volver hacia atrs (rollback) partes de una transaccin. Para complicarlo an ms, puede que una transaccin implique ms de una base de datos, y en ocasiones, a ms de un servidor (transacciones distribuidas). MySQL proporciona soporte para todos estos tipos de transacciones, siempre que los gestores de almacenamiento utilizados en las bases de datos implicadas tambin lo soporten.

Arquitectura de Bases de Datos SQL Server

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

Estructura Lgica: Desde el punto de vista lgico, la base de datos debe tener al menos 1 FileGroup el cual contiene a toda la metadata de la misma base de datos, es decir tablas y vistas de sistema, a este FileGroup inicial se le conoce como Primario y est presente en todas las bases de datos. Todos los objetos de usuario que contengan data, ya sean tablas o ndices, deben estar ligados a un FileGroup, esto se puede definir al momento de ejecutar la sentencia DDL de creacin del objeto, si no se indica a que FileGroup estar ligado ese objeto, este pertenecer al FileGroup por defecto definido en la base de datos. La base de datos solo puede tener definido 1 solo default FileGroup. Las bases de datos pueden tener hasta 32767 FileGroups definidos, segn los lmites establecidos para la ltima versin de SQL Server, la cual es SQL Server 2008 R2. Uno de los propsitos de los FileGroups es poder distribuir la data a travs de varios discos duros fsicos, de esta manera se puede obtener mayor rendimiento en las operaciones de I/O debido a que ms de un disco trabajara al mismo tiempo. Otro de los propsitos es poder

esconder la ubicacin fsica real de la informacin a los programadores, ya que para ellos la tabla X pertenece al FileGroup A, pero no saben en que data files fsicamente se encuentra la informacin de la tabla X. Los FileGroups pueden contener 1 o ms Datafiles, y cada uno de estos datafiles se pude encontrar en un discos diferentes, lo cual tambin agilizara las consultas y los ingresos de informacin a las tablas que se encuentren asignadas a este FileGroup, debido a que SQL Server distribuir la informacin uniformemente a travs de todos los DataFiles del FileGroup. Estructura Fsica: Desde el punto de vista fsico, como ya hemos visto, tenemos los DataFiles que los en realidad los archivos de datos, es decir donde se guarda toda la informacin de la base de datos. Un DataFile solo puede pertenecer a 1 FileGroup. Internamente los DataFiles estn divididos en Extends y estos a su vez en Pages. Las Pages son la unidad minima de almacenamiento dentro de la base de datos. Un Page tiene 8 Kb de tamao en espacio de disco. Un Extend tiene 8 Pages contiguas que lo conforman, es decir, un Extend tiene como tamao 64 Kb de espacio en disco. En un Page solo puede haber informacin de 1 sola tabla, es decir el espacio de un Page no es compartido entre tablas o ndices. En el caso de los Extends, estos pueden ser de dos tipos:

Mixed: Los cuales son compartidos hasta por 8 objetos, uno por cada Page. Uniform: Los cuales solo pertenecen a un solo objeto, es decir que todos los Pages pertenecen a un solo objeto.

Normalmente cuando se crea una nueva tabla esta es asignada a un Extend de tipo Mixed, hasta alcanzar la utilizacin de hasta 8 Pages, a partir de ese momento se asignan Extends de tipo Uniform para optimizar el uso del espacio en la tabla. Los DataFiles normalmente tienen 2 extensiones de archivo, las cuales son estandar mas no obligarias, la extencion mdf que se utiliza para el primer Datafile perteneciente al FileGroup primario, y la extension ndf que se utiliza para los demas datafiles que se agregan posteriormente a los demas FileGroups de la base de datos. En el caso del LogFile, este no pertenece a un FileGroup en especifico, en cambio archivo esta ligado directamente a la base de datos. Las bases de datos de SQL Server solo pueden tener un solo LogFile activo al mismo tiempo, si bien se pueden crear multiples LogFiles en la base de datos, solo uno podra ser escrito, ya que solo uno puede estar activo, cuando este archivo se llene, la base de datos pasara a escribir al siguiente archivo de transacciones, y asi sucesivamente. Por esta razon no es muy conveniente ni util tener mas de un LogFile.
SQL Server 2008

SQL Server SQL Server adquiere y libera memoria de manera dinmica segn sea preciso. Normalmente, no es necesario que un administrador especifique la cantidad de memoria que se debe asignar a SQL Server, aunque todava existe esta opcin y es necesaria en algunos entornos. SQL Server es compatible con AWE (Extensiones de ventana de direccin), que permite utilizar ms de 4 gigabytes (GB) de memoria fsica en las versiones de 32 bits de los sistemas operativos Microsoft Windows. Se admiten hasta 64 GB de memoria fsica. Las instancias de SQL Server que se ejecutan en MicrosoftWindows 2000 utilizan la asignacin de memoria AWE esttica y las instancias que se ejecutan en MicrosoftWindows Server 2003 usan la asignacin de memoria AWE dinmica. La compatibilidad con AWE slo est disponible en las ediciones Enterprise, Standard y Developer de SQL Server, y slo se aplica a los sistemas operativos de 32 bits. Analysis Services no puede beneficiarse de la memoria asignada de AWE. Si la memoria fsica disponible es menor que el espacio de direcciones virtuales del modo de usuario, AWE no se puede habilitar. Uno de los principales objetivos de diseo de todo el software de base de datos es minimizar la E/S de disco porque las operaciones de lectura y escritura del disco realizan un uso muy intensivo de los recursos. SQL Server crea un grupo de bferes en la memoria para contener las pginas ledas en la base de datos. Gran parte del cdigo de SQL Server est dedicado a minimizar el nmero de lecturas y escrituras fsicas entre el disco y el grupo de bferes. SQL Server intenta encontrar un equilibrio entre dos objetivos:

Evitar que el grupo de bferes sea tan grande que todo el sistema se quede con poca memoria. Minimizar la E/S fsica a los archivos de base de datos al maximizar el tamao del grupo de bferes.

Administracin de bfer.

Administracin de bfer
SQL Server 2008 Otras versiones

Este tema an no ha recibido ninguna valoracin - Valorar este tema

El propsito principal de una base de datos de SQL Server es almacenar y recuperar datos, por lo que una E/S de disco intensiva es una de las caractersticas principales de Database Engine (Motor de base de datos). Debido a que las operaciones de E/S de disco pueden consumir muchos recursos y tardar bastante tiempo en completarse, SQL Server se centra en hacer la E/S muy eficaz. La administracin de bfer es un componente clave para lograr esta eficacia. El componente de administracin de bfer consta de dos partes: el administrador de bfer para obtener acceso a las pginas de bases de datos y actualizarlas y la cach del bfer (tambin conocida como grupo de bferes) para reducir la E/S de archivos de base de datos.
Cmo funciona la administracin de bfer

Un bfer es un pgina de 8 KB en memoria (el mismo tamao que una pgina de ndice o de datos). Por lo tanto, la cach del bfer est dividida en pginas de 8 KB. El administrador de bfer administra las funciones para la lectura de pginas de ndice o de datos de los archivos de disco de base de datos en la cach del bfer y para la escritura de pginas modificadas nuevamente en el disco. Una pgina permanece en la cach del bfer hasta que el administrador del bfer necesite el rea del bfer para leer en ella nuevos datos. Los datos slo vuelven a escribirse en el disco si se han modificado. Los datos de la cach del bfer se pueden modificar varias veces antes de que se vuelvan a escribir en el disco. Para obtener ms informacin, vea Leer pginas y Escribir pginas. Cuando SQL Server se inicia, calcula el tamao del espacio de direcciones virtuales para la cach del bfer basndose en varios parmetros, como la cantidad de memoria fsica en el sistema, el nmero mximo configurado de subprocesos de servidor y diferentes parmetros de inicio. SQL Server reserva la cantidad calculada de su espacio de direcciones virtuales del proceso (llamada memoria objetivo) para la cach del bfer, pero slo adquiere (confirma) la cantidad necesaria de memoria fsica para la carga actual. Puede realizar una consulta en las columnas bpool_commit_target y bpool_committed en la vista de catlogo sys.dm_os_sys_info para devolver el nmero de pginas reservadas como memoria objetivo y el nmero de pginas actualmente confirmadas en la cach del bfer, respectivamente. El intervalo entre el inicio de SQL Server y el momento en que la cach del bfer obtiene su memoria objetivo se llama arranque. Durante este perodo, las solicitudes de lectura llenan los bferes segn sea necesario. Por ejemplo, una solicitud de lectura de una pgina llena una nica pgina de bfer. Esto significa que el arranque depende del nmero y el tipo de solicitudes del cliente. El arranque se agiliza mediante la transformacin de solicitudes de lectura de una pgina en solicitudes de ocho pginas alineadas. Esto permite que el arranque finalice mucho ms rpido, especialmente en equipos con mucha memoria. Debido a que el administrador de bfer utiliza la mayor parte de la memoria en el proceso de SQL Server, coopera con el administrador de memoria para permitir que otros componentes utilicen sus bferes. El administrador de bfer interacta principalmente con los siguientes componentes:

Administrador de recursos, para controlar la utilizacin de memoria general y, en plataformas de 32 bits, para controlar el uso del espacio de direcciones. Administrador de bases de datos y SQL Server Operating System (SQLOS), para operaciones de E/S de archivos de bajo nivel. Administrador de registros, para registros de escritura anticipada.

Caractersticas admitidas

El administrador de bfer admite las caractersticas siguientes:

El administrador de bfer est preparado para el acceso no uniforme a memoria (NUMA, Non-Uniform Memory Access). Las pginas de la cach del bfer se distribuyen por los nodos NUMA de hardware, que permiten que un subproceso tenga acceso a una pgina de bfer que est asignada en el nodo NUMA local y no desde una memoria externa. Para obtener ms informacin, vea Cmo SQL Server es compatible con NUMA. Para entender cmo se asignan las pginas de memoria desde la cach del bfer cuando se utiliza NUMA, vea Aumentar o reducir el grupo de bferes en NUMA. El administrador de bfer admite la funcin de Agregar memoria sin interrupcin, que permite a los usuarios agregar memoria fsica sin reiniciar el servidor. Para obtener ms informacin, vea Agregar memoria sin interrupcin. El administrador de bfer admite la asignacin de memoria dinmica en plataformas Microsoft Windows XP de 32 bits y Windows 2003 de 32 bits si AWE est habilitada. La asignacin dinmica de memoria permite que Database Engine (Motor de base de datos) adquiera y libere memoria eficazmente en la cach del bfer para admitir la carga de trabajo actual. Para obtener ms informacin, vea Administracin dinmica de memoria. El administrador de bfer admite pginas grandes en plataformas de 64 bits. El tamao de pgina es especfico de la versin de Windows. Para obtener ms informacin, consulte la documentacin de Windows. El administrador de bfer proporciona diagnsticos adicionales que se muestran mediante vistas de administracin dinmica. Puede utilizar estas vistas para supervisar diversos recursos del sistema operativo especficos de SQL Server. Por ejemplo, puede usar la vista sys.dm_os_buffer_descriptors para supervisar las pginas de la cach del bfer. Para obtener ms informacin, vea Vistas de administracin dinmica relacionadas con el sistema operativo de SQL Server (Transact-SQL).

E/S de disco

El administrador de bfer slo realiza tareas de lectura y escritura en la base de datos. Las otras operaciones con archivos, como la apertura, el cierre, la extensin y la reduccin, las realizan el administrador de base de datos y los componentes del administrador de archivos.

Las operaciones de E/S de disco que realiza el administrador de bfer tienen las siguientes caractersticas:

Todas las operaciones de E/S se realizan de forma asincrnica, lo que permite que el subproceso de llamada siga con el procesamiento mientras la operacin de E/S se realiza en segundo plano. Todas las operaciones de E/S se emiten en los subprocesos de llamada a menos que la opcin de afinidad de E/S est en uso. La opcin de mscara de afinidad de E/S enlaza la E/S del disco de SQL Server a un subconjunto especfico de unidades CPU. En entornos de procesamiento de transacciones en lnea (OLTP) de SQL Server de grandes prestaciones, esta extensin puede mejorar el rendimiento de los subprocesos de SQL Server que emiten E/S. Las operaciones de E/S de mltiples pginas se logran con E/S por dispersin y recopilacin, que permite transferir datos a reas no contiguas de memoria, o desde ellas. Esto significa que SQL Server puede llenar o vaciar rpidamente la cach del bfer y, a la vez, evitar mltiples solicitudes de E/S fsica.

Solicitudes de E/S largas

El administrador de bfer informa sobre cualquier solicitud de E/S que haya quedado pendiente durante al menos 15 segundos. Esto ayuda al administrador del sistema a distinguir entre problemas de SQL Server y problemas del subsistema de E/S. El mensaje de error 833 se notifica y aparece en el registro de errores de SQL Server de la siguiente forma: SQL Server ha detectado %d instancias de peticiones de E/S que estn tardando ms de %d segundos en completarse en el archivo [%ls] de la base de datos [%ls] (%d). El identificador de archivo del SO es 0x%p. El desplazamiento de la operacin de E/S ms reciente y ms larga es: %#016I64x. Una E/S larga puede ser de lectura o de escritura, pero esto no se indica actualmente en el mensaje. Los mensajes de E/S larga son advertencias, no errores. No indican problemas con SQL Server. Los mensajes se notifican para ayudar a los administradores del sistema a encontrar la causa de los tiempos de respuesta largos de SQL Server con mayor rapidez y a distinguir problemas que estn fuera del control de SQL Server. Por eso, no es necesario tomar ninguna accin, pero el administrador del sistema debe investigar por qu la solicitud de E/S tard tanto tiempo y si ese tiempo es justificable. Causas de solicitudes de E/S largas Un mensaje de E/S larga puede indicar que una E/S est permanente bloqueada y que nunca se completar (tambin llamada E/S perdida), o que simplemente no se complet an. No es posible saber con los datos del mensaje de qu caso se trata, aunque una E/S perdida casi siempre llevar a un tiempo de espera de bloqueo temporal.

Las E/S largas suelen indicar una carga de trabajo de SQL Server demasiado intensa para el subsistema de disco. Se puede indicar un subsistema de disco inadecuado cuando:

Aparecen mltiples mensajes de E/S largas en el registro de errores durante una carga de trabajo pesada de SQL Server. Los contadores de rendimiento muestran latencias de disco prolongadas, colas de disco largas o no muestran el tiempo de inactividad de disco.

Otra posible causa de las E/S largas es que un componente de la ruta de acceso de E/S (por ejemplo, un controlador o el firmware) posponga de forma continua el servicio para una solicitud de E/S antigua en favor de dar servicio a solicitudes nuevas que estn ms cerca de la posicin actual del cabezal del disco. La tcnica corriente de procesar solicitudes segn su prioridad sobre la base de las que estn ms cerca de la posicin actual del cabezal de lectura/escritura se conoce como "bsqueda de elevador". Esto puede resultar difcil de corroborar con la herramienta Monitor del sistema de Windows (PERFMON.EXE) porque a la mayor parte de las E/S se las da servicio inmediatamente. Las solicitudes de E/S largas pueden agravarse con cargas de trabajo que realicen un gran nmero de operaciones de E/S secuenciales, como copias de seguridad y restauracin, recorridos de tablas, ordenaciones, creacin de ndices, cargas masivas y puestas a cero de archivos. Las E/S largas aisladas que no estn relacionadas con ninguna de las situaciones anteriores pueden estar causadas por un problema con el hardware o el controlador. El registro de eventos del sistema puede contener un evento relacionado que ayude a diagnosticar el problema.

Deteccin de errores
Las pginas de bases de datos pueden utilizar uno de los dos mecanismos opcionales que ayudan a garantizar la integridad de la pgina desde el momento en que se escribe en el disco hasta que se vuelve a leer: proteccin contra pgina rasgada y proteccin de suma de comprobacin. Estos mecanismos permiten emplear un mtodo independiente para verificar la correccin, no slo del almacenamiento de datos, sino tambin de los componentes de hardware, como controladores, cables e incluso el sistema operativo. La proteccin se agrega a la pgina justo antes de escribirla en el disco y se comprueba despus de que se lee desde el disco. Proteccin contra pgina rasgada La proteccin contra pgina rasgada, caracterstica implementada en SQL Server 2000, es bsicamente una forma de detectar errores en las pginas a causa de problemas con el suministro elctrico. Por ejemplo, es posible que por un problema con el suministro elctrico slo se escriba una parte de la pgina en el disco. Cuando se utiliza la proteccin contra pgina rasgada, se coloca una firma de 2 bits al final de cada segmento de 512 bytes en la pgina (despus de haber copiado los dos bits originales en el encabezado de la pgina). La firma alterna entre 01 y 10 binarios con cada escritura, por lo que siempre es posible saber cundo slo una parte de los sectores se escribieron en el disco: si hay un bit con el estado incorrecto cuando la pgina se lee posteriormente, la pgina se escribi de

forma incorrecta y se detecta una pgina rasgada. La deteccin de pgina rasgada utiliza un mnimo de recursos; sin embargo, no detecta todos los errores causados por fallos del hardware del disco. Proteccin de suma de comprobacin La proteccin de suma de comprobacin, caracterstica implementada en SQL Server 2005, proporciona una comprobacin de integridad de datos ms slida. Se calcula una suma de comprobacin para los datos de cada pgina que se escribe y se almacena en el encabezado de la pgina. Cada vez que se lee desde disco una pgina con una suma de comprobacin almacenada, el motor de base de datos vuelve a calcular la suma de comprobacin para los datos de la pgina y muestra el error 824 cuando la nueva suma de comprobacin no coincide con la suma almacenada. La proteccin de suma de comprobacin puede detectar ms errores que la proteccin contra pgina rasgada porque tiene en cuenta cada byte de la pgina; sin embargo, consume una cantidad de recursos considerable. Cuando la suma de comprobacin est habilitada, los errores que cause cualquier problema con el suministro elctrico y cualquier problema de hardware o firmware pueden detectarse cada vez que el administrador de bfer lea una pgina del disco. El tipo de proteccin de pgina que se utilice es un atributo de la base de datos que contiene la pgina. La proteccin de suma de comprobacin es la proteccin predeterminada para bases de datos creadas en SQL Server 2005 y en versiones posteriores. El mecanismo de proteccin de pginas se especifica al crear la base de datos y se puede modificar con ALTER DATABASE. La configuracin de proteccin de pgina actual se puede determinar consultando la columna page_verify_option de la vista de catlogo sys.databases o la propiedad IsTornPageDetectionEnabled de la funcin DATABASEPROPERTYEX. Si se modifica la configuracin de proteccin de pgina, la nueva configuracin no afecta a toda la base de datos de forma inmediata. En cambio, las pginas adoptan el nivel de proteccin actual de la base de datos cuando se vuelven a escribir. Esto significa que la base de datos puede estar compuesta de pginas con distintos tipos de proteccin.

De forma predeterminada, las ediciones de SQL Server 2005 administran dinmicamente la memoria para cada instancia. Existen diferencias en la forma en que SQL Server administra la memoria asignada de AWE en Windows 2000 y las versiones posteriores de los sistemas operativos.
Nota

En un sistema con mucha carga, algunas consultas grandes que necesitan una gran cantidad de memoria para ejecutarse no pueden obtener la cantidad mnima de memoria solicitada y

reciben un error de tiempo de espera agotado mientras esperan los recursos de memoria. Para solucionarlo, aumente la opcin query wait. Para una consulta en paralelo, considere la posibilidad de reducir la opcin max degree of parallelism.
Nota

En un sistema con mucha carga y mucha presin de la memoria, las consultas con combinaciones de mezcla, orden y mapa de bits en el plan de consulta pueden quitar el mapa de bits si no obtienen la memoria mnima necesaria para dicho mapa de bits. Esto puede afectar al rendimiento de la consulta y, si el proceso de ordenacin no cabe en la memoria, puede aumentar el uso de las tablas de trabajo en la base de datos tempdb, lo que hace que tempdb crezca. Para resolver este problema, agregue memoria fsica u optimice las consultas para que usen otro plan de consulta ms rpido. Para obtener informacin sobre la optimizacin, vea Optimizar el rendimiento de tempdb y Cmo optimizar una base de datos.

Proporcionar la cantidad mxima de memoria a SQL Server

Mediante AWE y el privilegio Lock Pages in Memory, puede proporcionar las siguientes cantidades de memoria a SQL Server Database Engine (Motor de base de datos de SQL Server). 32 bits 64 bits Todas las ediciones de SQL Server: hasta el lmite de espacio de direcciones virtuales del proceso: Todas las ediciones de SQL Server: hasta el lmite de espacio de direcciones virtuales del proceso: Memoria convencional.

7 terabytes en la arquitectura IA64 8 terabytes en la arquitectura x64

2 GB 3 GB con el parmetro de inicio /3gb1 4 GB en WOW642

Nota En Windows Server 2003 la limitacin es de 512 GB; en Service Pack 1 de Windows Server 2003, un 1 terabyte. Si Windows admite memoria adicional, SQL Server puede llegar a los lmites mencionados.

Mecanismo AWE (permite a SQL Server superar el lmite del espacio de direcciones virtuales del proceso en plataformas de 32 bits).

Ediciones Standard, Enterprise y Developer de SQL Server: el grupo de No aplicable3 bferes puede tener acceso a un mximo de 64 GB de memoria.

Ediciones Standard, Enterprise y Developer de SQL Server: requerido para que el proceso de SQL Privilegio del sistema Server utilice el mecanismo operativo (OS) Lock AWE. La memoria Pages in Memory asignada a travs del (permite bloquear memoria fsica e impedir mecanismo AWE no se puede paginar. la paginacin en el sistema operativo de la memoria bloqueada).4 Si se concede este privilegio sin habilitar AWE, no tiene efecto en el servidor.

Ediciones Enterprise y Developer de SQL Server: recomendado para evitar la paginacin del sistema operativo. Puede proporcionar una ventaja de rendimiento en funcin de la carga de trabajo. La cantidad de memoria a la que se puede tener acceso es similar al caso de memoria convencional.

2.1.2 Estructuras fsicas de la base de datos

2.1.3 Requerimientos para instalacin. 2.1.4 Instalacin del software de BD en modo transaccional 2.1.5 Variables de Ambiente y archivos importantes para instalacin. 2.1.6 Procedimiento general de instalacin 2.1.7 Procedimiento para configuracin de un DBMS 2.1.8 Comandos generales de alta y baja del DBMS