Estrategias para Optimizacin del Acceso a Bases de Datos Relacionales1

Jos A. Martnez Flores* y Rodolfo A. Pazos Rangel * Instituto Tecnolgico de Cd. Madero Centro Nacional de Investigacin y Desarrollo Tecnolgico E-mail: (jam, pazos) @sd-cenidet.com.mx Resumen Hoy en da es normal que las consultas realizadas por grandes empresas involucren una gran cantidad de informacin, por tal motivo el tiempo de respuesta por parte del sistema manejador de bases de datos (SMBD) a tales consultas puede ser intolerable para algunos usuarios. Es comn que los SMBDs corran sobre un sistema operativo (SO), renunciando con esto al control del acceso a los datos, tarea del sistema de archivos del SO, el cual est desafortunadamente diseado para propsitos generales, por lo que sus algoritmos son para tales fines. En el rea de los SOs, aun cuando se ha trabajado extensamente, las tcnicas usadas ignoran informacin muy valiosa que est disponible, lo cual le impide un desempeo ptimo en la administracin de sus pginas (datos) en relacin a la informacin que se obtendra del planificador de consultas de un SMBD. Por lo antes descrito ciertos SMBDs construyen su propio administrador de archivos relegando al del SO. En este artculo se presentan algunas estrategias para optimizar el acceso a los datos en el rea de bases de datos (BDs). Palabras clave: bases de datos relacionales, optimizacin de estrategias de acceso. 1. Introduccin Actualmente es comn que las grandes empresas tengan enormes bases de datos, por tal motivo es normal que sus consultas involucren una gran cantidad de informacin. Debido a lo anterior es de suponer que el tiempo de respuesta del SMBD puede llegar a ser abrumador [1, 2]. De todos es conocido que los datos slo pueden ser manipulados en la memora principal, por consiguiente la informacin de la base de datos debe ser cargada en sta antes de ser manipulada. Comnmente el acceso a los datos es de forma reactiva, de tal manera que la carga de stos (de disco a memoria principal) se inicia en respuesta a una solicitud [3, 4]. Se han venido desarrollando nuevos mtodos (principalmente en el rea de los sistemas operativos) para recuperar la informacin de una manera ms eficaz. Debido a que no es posible mantener en memoria principal todos los datos de una relacin cuando sta es ms grande que aqulla, se han creado algoritmos de remplazo de pginas para su administracin.

Esta investigacin fue financiada en parte por el convenio COSNET No. 640.01-P

Es ampliamente conocido por la comunidad de bases de datos que la administracin del contenedor juega un rol clave en proveer acceso eficiente a datos residentes en disco y en el uso ptimo de la memoria principal [5, 6]. Debido a que en el rea de BDs es posible conocer en ciertas consultas el patrn de acceso a los datos, por lo tanto es posible a) solicitar la informacin anticipadamente al controlador del disco y b) colocarla en un contenedor para su uso posterior (ver Figura 1), para lo cual se debe determinar dnde y en dado caso, qu dato remplazar (desalojar un dato que de momento no sea til para colocar otro). En estas circunstancias hay que sincronizar cuidadosamente la precarga (solicitud de datos) y su almacenamiento en memoria principal, lo cual constituye un problema complejo [7]. Aplicacin

Contenedor

Datos en Disco Figura 1. Situacin del Contenedor en una Arquitectura Tpica. En este trabajo de investigacin se propone una nueva estrategia de solucin al problema de recuperacin de informacin, en este caso para el rea de bases de datos relacionales. En el mbito de las bases de datos no se ha trabajado con tcnicas combinadas de precarga y polticas de remplazo de la informacin de acuerdo a nuestra investigacin de la literatura especializada. 2. Marco Terico La memoria principal disponible para un programa ms sus datos puede ser insuficiente, en este caso, se deber emplear una prctica conocida como intercambio. En sta el programa y sus datos son organizados de tal manera que varios mdulos pueden ser colocados en la misma regin de la memoria. En casi todos los sistemas de multiprogramacin modernos, esto involucra un sofisticado mecanismo conocido como memoria virtual. La memoria virtual se basa en el uso de una o ambas tcnicas bsicas: segmentacin y paginacin; y sus principales polticas son las siguientes: Polticas de carga (solicitud) Por demanda Precarga Polticas de colocacin

Polticas de remplazo Algoritmos bsicos ptimo Last Recent Use (LRU, ltimo recientemente usado) First in , first out (FIFO, primero en entrar, primero en salir) Clock (de reloj) Carga de pginas [8]. En un ambiente de sistema operativo (SO) actual, que utilice una estrategia de memoria virtual, alojar un SMBD que sea tratado como un programa de aplicacin normal, puede tener resultados desfavorables para el administrador del contenedor (espacio para almacenamiento temporal de datos) del SMBD. Esto se debe a que tanto su cdigo como su contenedor sern paginados por el sistema de archivos (mdulos encargados de la administracin de los archivos) del SO, el cual est diseado para propsitos generales por lo que sus algoritmos son para tales fines [9, 10]. Un SMBD difiere sustancialmente de aplicaciones de propsito general por lo que el sistema de archivos del SO no se desempea de forma ptima a los requerimientos del SMBD. Debido a lo anterior algunos SMBDs construyen su propio administrador de archivos haciendo a un lado al del SO [11, 12]. Actualmente los sistemas de archivos tradicionales esperan hasta que una aplicacin requiera datos para solicitarlos al subsistema de entrada y salida (la Figura 2, muestra la organizacin jerrquica de la memoria [8]). Si stos no estn presentes en algn contenedor, ser necesario recuperarlos (leer los datos) del almacenamiento secundario, con su correspondiente prdida de tiempo, adems de realizar alguna poltica de remplazo (seleccionar un dato vctima cuando el contenedor est lleno para colocar el que se necesita) si fuera necesario [8, 13].

Registro Contenedor (Cache) Memoria Principal Contenedor de Archivos (File Cache) Discos Medios Desmontables Figura 2. Jerarqua de la Memoria.

Si el optimizador de consultas y el administrador del contenedor trabajaran en conjunto y no de manera independiente, se podra transmitir informacin relevante ya que en ciertas consultas el SMBD puede conocer el patrn de acceso (cules y cundo sern ledos los datos) para satisfacer la consulta; por lo tanto, el SMBD puede precargar los datos y, cuando stos sean requeridos ya estarn en el contenedor con lo que se evitar leerlos de disco, lo cual es mucho ms rpido [11, 14]. Hay dos tipos de precarga: la informada y la predictiva. En la precarga informada la aplicacin divulga los datos que requerir; es decir, proporciona los datos a usar, de tal forma que se sabe con certeza cules sern. La implementacin ms comn de precarga predictiva es la lectura adelantada secuencial; otra opcin es que el sistema haga predicciones sobre los accesos futuros (basadas generalmente en accesos pasados) para precargar los datos en consecuencia. Algunos investigadores han llegado al extremo de precargar archivos enteros antes de ser referidos [14]. 3. Algoritmos de Remplazo y Precarga Debido a que un acceso a una pgina de la BD en disco es mucho ms caro que un acceso a una pgina de la BD en el contenedor, la meta principal de un administrador de contenedor de una BD es minimizar las entradas y salidas (E/S) de las pginas. Por tal motivo la optimizacin del algoritmo de remplazo de pginas es muy importante para el desempeo total del SMBD [15]. Tanto en los SOs como en los SMBDs se necesita elegir a la pgina vctima cuando el contenedor se encuentra lleno. La respuesta a qu pgina quitar es sencilla: elegir a la pgina que ya no se va a usar. El algoritmo para implementar tal regla es muy complicado (ptimo), porque requiere que el SO tenga perfecto conocimiento de eventos futuros [8, 16], para lo cual habra que ejecutar el programa. En el rea de los SOs se han inventado e implementado tcnicas variantes a la regla ptima, es decir, remplazan la pgina que tenga menor probabilidad de usarse. En la Figura 3 se muestran los algoritmos de remplazo ms conocidos y/o utilizados; la F en esta figura significa que no se encontr la pgina y que se realizar un remplazo (seleccionando a la pgina vctima de acuerdo al algoritmo) debido a que el contenedor se encuentra lleno.
SECUENCIA DE PGINAS

2
2

3
2 3

2
2 3

1
2 3 1 2 3 1 2 3 1

5
2 3 5 F 2 5 1 F 5 3 1 F

2
2 3 5 2 5 1 5 2 1 F

4
4 3 5 F 2 5 4 F 5 2 4 F

5
4 3 5 2 5 4 5 2 4

3
4 3 5 3 5 4 F 3 2 4 F

2
2 3 5 F 3 5 2 F 3 2 4

5
2 3 5 3 5 2 3 5 4 F

2
2 3 5 3 5 2 3 5 2 F

PTIMO

LRU

2 3

2 3

FIFO

2 3

2 3

Figura 3. Algoritmos de Remplazo de Pginas.

La precarga y el contenedor son dos mtodos muy conocidos para mejorar el desempeo del sistema de archivos [17]. A pesar de que stos han sido estudiados extensivamente, se han realizado varios estudios de precarga con la ausencia del contenedor o para estrategias de contenedor fijo. Segn [18] la interaccin entre la precarga y el contenedor no est bien entendida. La principal complicacin es que precargar pginas en el contenedor puede ser daino an cuando las pginas sean accedidas en el futuro cercano [19]. Para ilustrar lo anterior, considerse un programa que hace referencia a pginas, acorde al patrn "ABCA". Supngase que el contenedor mantiene dos pginas, que la precarga de una pgina toma cuatro unidades de tiempo, y que A y B estn inicialmente en el contenedor. Como se muestra en la Figura 4, una poltica que no precarga (usando el algoritmo ptimo de remplazo fuera de lnea) puede acertar en las primeras dos referencias (A y B), despus falta la referencia a C, descartando a B, y finalmente acertando en A. La referencia a C es detenida por cuatro unidades de tiempo mientras se carga a C y se descarta a B. El tiempo de ejecucin de la poltica de no precarga puede en consecuencia consumir ocho unidades de tiempo (uno por cada una de las cuatro referencias, ms cuatro por la falta). Tiempo Acceso Carga Contenido del contenedor A B A B A B 1 A 2 B ________carga de C________ A A A A C A C 3 4 5 6 7 C 8 A

Figura 4. Un Ejemplo de Poltica sin Precarga. En contraste, como se muestra en la Figura 5, una poltica que precargue cuantas veces sea posible (mientras efecta la seleccin del remplazo ptimo) consume 10 unidades de tiempo para ejecutar la misma secuencia. Despus del primer acceso exitoso a A, se efecta la precarga de C, descartando a A. Esta precarga oculta una unidad en la latencia de la carga, tal que el acceso a C se detiene slo por tres unidades. En cuanto llega C a memoria, el algoritmo inicia otra precarga, trayendo a A y descartando a B, mientras se accede a C. La siguiente referencia a A se detiene por tres unidades de tiempo, esperando que la precarga de A se complete. Este algoritmo usa 10 unidades de tiempo, una para cada una de las cuatro referencias, ms dos esperas de tres unidades. Tiempo Acceso Carga Contenido del contenedor A B A B 1 A 2 B _____carga de C______ C B 3 4 5 6 C ______carga de A______ C C C C A 7 8 9 10 A

Figura 5. El Mismo Ejemplo con Poltica de Precarga.

Este ejemplo demuestra que la precarga miope no siempre es benfica. De tal forma que es una espada de doble filo: oculta la latencia de la carga, pero puede incrementar el nmero de cargas. 4. Estrategias de Acceso La investigacin que se est realizando tiene como objetivo demostrar que la integracin de la precarga y del contenedor en el rea de BDs permite mejorar el desempeo de stas, tal como ya se ha demostrado en el rea de los sistemas operativos [7, 20]. Este proyecto consiste de tres partes bsicas: 1) el desarrollo de estrategias de precarga para BDs, 2) la evaluacin de la(s) poltica(s) de remplazo ptima(s), y 3) la integracin e implementacin de ambas. Las reglas que hay que tomar en cuenta para una precarga y estrategia del contenedor ptimas son las siguientes: Precarga ptima: cada precarga deber traer al contenedor el siguiente bloque en el flujo de referencia que no est en el contenedor. Remplazo ptimo: cada precarga deber descartar el bloque cuya siguiente referencia sea la menos necesaria en el futuro. Para que la precarga y la poltica del contenedor estn correctamente integradas hay que tomar las decisiones siguientes: cundo cargar un bloque de disco, qu bloque cargar, y qu bloque remplazar cuando se realiza la carga, para que el tiempo total a transcurrir sea mnimo. Hay que hacer notar que lo anterior corresponde a un sistema con un disco o un servidor de archivos, y ste slo considera referencias de lectura. 5. Anlisis de la Instruccin SELECT 5.1. Un ejemplo que evidencia la utilidad de precargar datos Para ejemplificar que es factible predecir el uso de renglones en un SMBD se describir el caso ms sencillo. Primeramente cabe hacer mencin que el SMBD, cuando recibe una instruccin en SQL, la analiza lxica, sintctica y semnticamente [8, 21] de tal manera que puede predecir el patrn de acceso a los datos. Por ejemplo, al solicitrsele un determinado rengln de cierta tabla (que no tenga ndice) el SMBD sabe que para proporcionar el resultado a tal consulta deber leer todos los renglones de la tabla, para lo cual se deber evaluar el tamao de sta para determinar si es

factible precargar toda la tabla o slo algunas pginas de datos (renglones). Como se muestra en la Figura 6, el SMBD, una vez que haya ledo el rengln i, sabe que el rengln i 1 (o alguno anterior a ste) ya no le servir, de tal forma que ste puede ser el dato vctima para colocar el rengln i +1 si fuera necesario. : i-2 i-1 i

1 2 : i-1 i i+1 : n Alumnos

Figura 6. Interaccin entre Precarga y Contenedor. 5.2. Taxonoma de la Instruccin SELECT Uno de los objetivos principales de esta investigacin es identificar de acuerdo a la instruccin SELECT de SQL qu datos precargar, a partir de la informacin del planificador de consultas, y si es posible cargar toda la tabla. A continuacin se describen los diferentes tipos de casos que pueden presentarse con la instruccin SELECT de SQL. 1. Consulta a slo una tabla, sin clusula WHERE sin ndice y con ndice. Al tener que mostrar la informacin de todos los renglones de la tabla, lo ms conveniente es utilizar la precarga, para cargar en memoria principal los renglones (en pginas) que se usarn en un futuro prximo, con el consiguiente ahorro en el tiempo de acceso a los datos, debido a que con esto se adelantar a la solicitud de los datos de tal manera que ya estarn en memoria principal cuando stos sean requeridos. Para este caso es conveniente usar el algoritmo de remplazo APU (Any Previously Used), debido a que los renglones ya ledos no se volvern a utilizar y por lo tanto es indistinto qu rengln se remplazar. 2. Consulta a slo una tabla, con clusula WHERE sencilla sin ndice. Al no tener ndice la columna que se utiliza en la clusula WHERE, es necesario evaluar cada uno de los

renglones de la tabla para saber si cumplen con la condicin de bsqueda, por lo tanto se tratar igual que el caso nmero 1. 3. Consulta a slo una tabla, con clusula WHERE sencilla con ndice. Primeramente evaluar si es conveniente usar el ndice, si es as cargar los nodos del rbol (del ndice) de acuerdo a como se vayan necesitando; en este caso no se pueden aprovechar las bondades de la precarga, debido a que para poder precargar algn nodo del rbol se necesitar conocer su direccin, en todo caso, es mejor saber qu nodo conduce a la hoja (dato) que se busca. Lo que se podra precargar sera el nodo raz, ya que este nodo es indispensable para iniciar la bsqueda. Una vez encontrado el nodo hoja, se podr acceder al rengln de la tabla (pgina). Se continuarn leyendo los nodos hoja adyacentes (a la izquierda o derecha, de acuerdo al anlisis previo de la instruccin) siempre y cuando lo indique la clusula WHERE (por ejemplo, columna > valor), y/o la informacin proporcionada por la tabla, mientras se cumpla la condicin, lo cual puede arrojar como resultado uno, varios o ningn rengln; es conveniente usar el algoritmo de remplazo LRU (Least Recently Used) para los nodos del rbol, permaneciendo con esto los primeros nodos accedidos (los ms prximos a la raz) que son los que tienen mayor probabilidad de volverse a utilizar. Se podr utilizar el algoritmo de remplazo APU para la administracin de las pginas que contienen los renglones de la tabla, ya que una vez ledo un determinado rengln pudiera ser que exista otro en la misma pgina a ser utilizado posteriormente; de tal manera que al no saber con certeza absoluta qu pginas contienen renglones a ser ledos en un futuro cercano, la pgina a remplazar ser hasta cierto punto indistinta. 4. Consulta a slo una tabla, con clusula WHERE compleja, sin ndice. Al no contar con ndice se debern evaluar todos los renglones de la tabla, para saber cules cumplen la condicin de bsqueda, por lo tanto se trata igual que el caso nmero 1. 5. Consulta a slo una tabla, con clusula WHERE compleja, con ndice. Se deber descomponer en subconsultas y si alguna de stas tiene ndice utilizarlo, siempre y cuando sea de utilidad; si hay ms de un ndice, hay que realizar un anlisis para seleccionar el que resulte ms beneficioso. En caso de existir un ndice y sea conveniente utilizarlo, se continuar trabajando igual que en el caso nmero 3. Cabe hacer notar que adems de evaluar que los renglones cumplan la condicin de seleccin en el ndice, debern de cumplir con las dems condiciones (subconsultas), para lo cual una vez ledo el rengln, stas podrn ser verificadas. Si no se puede utilizar algn ndice, se tratar igual al caso nmero 1. 6. Consulta a dos tablas, sin clusula WHERE sin ndice y con ndice. Debido a que se tiene que realizar el producto cartesiano, el ndice no es til para esto, lo conveniente es utilizar la precarga para agilizar las operaciones. En el proceso antes referido (producto cartesiano) una de las tablas ser leda de manera secuencial, slo una vez, de tal forma que los renglones ya ledos no se volvern a utilizar, por lo tanto es conveniente utilizar el algoritmo de remplazo APU en stos; en tanto en la otra tabla, sus renglones tambin sern ledos de manera secuencial, con la diferencia de que stos sern accedidos en ms de una ocasin, en proporcin al nmero de renglones de la otra tabla, de tal manera que con estos renglones se podr utilizar el algoritmo de remplazo MRU, no sin antes determinar si es posible colocar toda la tabla en memoria principal, para mejorar la eficiencia en el tiempo de respuesta.

7. Consulta a dos tablas, con clusula WHERE sencilla, sin ndice y con ndice. Conviene crearle un ndice a la tabla con menor cardinalidad, en caso de que ninguna de ellas lo tenga, o si existiera alguno que no fuera til; en forma paralela iniciar la precarga de los renglones de la otra tabla (con mayor cardinalidad); esto es debido a que con la precarga se accedern ms rpido que con el ndice. Si el operador entre una columna y otra es: >, > =, <, <= o = se debe proceder de la siguiente forma: leer un rengln de la tabla sin ndice, posteriormente obtener el dato de la columna que participa en la clusula WHERE, a continuacin buscar con el dato anterior la primer hoja en el rbol del ndice que satisfaga la condicin, similar al caso nmero 3; a partir de ah, recorrer a la izquierda o derecha las dems hojas del rbol (si es que las hay), dependiendo del tipo de operador; terminado lo anterior, se debe continuar con otro rengln, hasta finalizar con cada uno de ellos. El algoritmo de remplazo a utilizar para las pginas que contienen los renglones de la tabla indizada ser APU, debido a que tienen la misma posibilidad de que sean accedidas nuevamente y MRU para la otra tabla, que de acuerdo a la literatura es el algoritmo de remplazo ms eficiente para reuniones. Si el operador fuera <>, se procedera en forma similar al caso nmero 6. 8. Consulta a dos tablas, con clusula WHERE compleja, sin ndice y con ndice. Tambin se deber descomponer en subconsultas, tratndose igual que el caso anterior. Cabe hacer mencin que puede darse una condicin que involucre el producto cartesiano, para lo cual se tratar igual que el caso nmero 6. 9. Consulta a tres o ms tablas, sin clusula WHERE sin ndice y con ndice. Primeramente se debern tomar dos tablas tratndolas igual que el caso nmero 6, con el resultado anterior (tabla resultante o intermedia) y otra tabla, nuevamente se trabajar como en el caso 6; y as sucesivamente si existieran ms tablas. 10. Consulta a tres o ms tablas, con clusula WHERE sencilla, sin ndice y con ndice. Similar al caso anterior, con la diferencia de que en lugar de utilizar el caso nmero 6, para trabajar de dos en dos las tablas, ser el caso 7. 11. Consulta a tres o ms tablas, con clusula WHERE compleja, sin ndice y con ndice. Similar al caso anterior, con la diferencia de utilizar el caso nmero 8, para trabajar las tablas. 6. Implementacin Aunque se ha trabajado bastante en el rea de los sistemas operativos, sus tcnicas ignoran informacin que est disponible y, por lo tanto, sus estimaciones de usar ciertas pginas (datos) son inciertas comparadas con la informacin que se obtendra del planificador de consultas de un SMBD. En la literatura especializada, solamente se mencionan trabajos para conocer el patrn de bsqueda o en su defecto colocar marcas para informar de ste al sistema operativo. En el rea de BDs se puede saber con cierta certeza este patrn en varias instrucciones de SQL.

Actualmente existe un sistema manejador de bases de datos distribuidas experimental (denominado SiMBaDD), desarrollado por el Centro Nacional de Investigacin y Desarrollo Tecnolgico, el cual cuenta con varias versiones, una para cada una de las siguientes funciones: a) manejo de transacciones, b) optimizacin de consultas, c) procesamiento de consultas globales, d) manejo de fragmentacin horizontal, y e) manejo de vistas. Para propsitos de prueba se seleccionar una versin del SiMBaDD para integrarle los mdulos de precarga y administracin del contenedor (Figura 7), para tal efecto se implementarn los algoritmos antes propuestos, los cuales se evaluarn contra los algoritmos que tradicionalmente se han implementado en SOs y SMBDs, como por ejemplo LRU, MRU y FIFO entre otros. Se pretende trabajar con este manejador debido principalmente a que se tiene disponible el cdigo fuente para aadirle las rutinas necesarias y poder demostrar los beneficios de la precarga y la administracin del contenedor planteados en esta investigacin.
main ( ) l { $SELECT : }

Analizador Instruccin SQL

Inicio

rbol Sintctico

Analizador Patrn de Acceso a los Datos

Condicin de Bsqueda

Generador de Resultados

Datos Finales

Selector de Renglones
Registros Solicitados Solicitud de Registros Patrn de Acceso, Poltica de Remplazo

Precarga de Datos

Solicitud Precarga de Datos Poltica de Remplazo

Administrador de Contenedores

Remplazo ptimo: cada precarga deber descartar el bloque cuya siguiente referencia sea la menos necesaria en el futuro.

RAM Tabla de Pags Datos

A Tomar en Consideracin: cundo cargar un bloque de disco, qu bloque cargar, y qu bloque remplazar cuando se realiza la carga.

BD Figura 7. Arquitectura del Sistema

Al presente ya existe el mdulo Analizador Instruccin SQL en el prototipo, el cual verifica que la instruccin de SQL a evaluar est correcta tanto sintctica, como semnticamente. Posteriormente el mdulo Selector de Tuplas, que tambin ya existe, lee y selecciona las tuplas que cumplen la condicin de bsqueda; por ltimo el mdulo Generador de Resultados (ya implementado) formatea el resultado final de la consulta. Con el mdulo Analizador Patrn de Acceso a los Datos se pretende identificar los futuros renglones a leer (patrn de acceso) a partir del tipo de consulta, tal como se mostr en la seccin anterior, as como la poltica de remplazo a utilizar. Esta informacin se debe transferir despus al mdulo Administrador de Contenedores, para que a su vez solicite al mdulo Precarga de Datos los renglones antes de que stos le sean solicitados por el mdulo Selector de Renglones, con su consiguiente ahorro de tiempo. De tal forma que el acceso a los datos sea ms rpido, adems de tener una poltica de remplazo ad-hoc. 7. Conclusiones En el rea de optimizacin de estrategias de acceso, se han identificado problemas de investigacin abiertos. Hemos encontrado que se han desarrollado muchos trabajos sobre precarga principalmente en el rea de los SOs, enfocndose en tratar de obtener o predecir el patrn de acceso a los datos para aplicaciones de propsito general. Sin embargo como se ha visto, ste es complicado de obtener comparado con el que se obtendra del planificador de consultas de un SMBD relacional, ya que ste soporta un limitado conjunto de operaciones y los patrones de referencia de pginas exhibidas por estas operaciones son muy regulares y predecibles, adems de ser stos ms precisos. Cabe recordar que la precarga por s sola no basta, ya que debe estar integrada con los algoritmos de remplazo adecuados para su ptimo funcionamiento, lo cual constituye un problema complejo. Referencias [1] [2] [3] [4] [5] [6] David Lomet, Avi Silberschatz, Mike Stonebraker, y Jeff Ulman, Database Research: Archievements and Opportunities Into the 21st Century (Extended abstract), Sumario del Workshop on Future of Database Systems Research, Mayo de 1995. Todd C. Mowry, Angela K. Demke, y Orran Krieger, Automatic Compiler-Inserted I/O Prefetching for Out-of-Core Applications, Second Simposium on Operating Systems Design and Implementations, Oct. de 1996. R. Hugo Patterson, Garth A. Gibson, Eka Ginting, Daniel Stodolsky, y Jim Zelenka, Informed Prefetching and Caching, Proc. of the 15th ACM Symp. on Operating System Principles, Dec. 1995. Abraham Silberschatz, Peter B. Galvin y Greg Gagne, Operating System Concepts. 6ta ed. John Wiley & Sons, 2002. pp. 34-35. Christos Faloutsos, Raymond Ng, y Timos Sellis, ``Flexible and Adaptable Buffer Management Techniques for Database Management Systems,'' IEEE Transactions on Computers, vol. 44, No. 4, Abril 1995. pp. 546-560. Bjrn T. Jonson, Michael J. Franklin y Divesh Srivastava, Interaction of Query Evaluation and Buffer Management for Informatin Retrieval, Proceeding ACM

[7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21]

SIGMOD International Conference on Management of Data, Junio1998, Seattle, WS, USA. 118-129. Pei Cao, Edward W. Felten, Anna R. Karlin, y Kai Li, A Study of Integrated Prefetching and Caching Strategies, Proc. ACM SIGMETRICS, 1995. William Stallings, Operating Systems Internal and Design Principles. 3rd ed. Prentice Hall, 1997. Leonard D. Shapiro, Join Processing in Database System with Large Main Memories, ACM Transactions on Database Systems, Vol. 11, No. 3, Sep. 1986. pp 239-264. Steve Bobrowski, Oracle8i para Windows NT, Oracle Press., 2000, pp. 4-5. Douglas W. Cornell y Philip S. Yu, Integration of Buffer Management and Query Optimization in Relational Database Enviroment, Proc. of the 15th Intern. Conference on Very Large Data Base VLDB89, 1989. pp 247-255. Hong-Tai Chow y David J. DeWitt, An Evaluation of Buffer Management Strategies for Relational Database System, Proc. of the 11th Intern. Conference on Very Large Data Base VLDB85, Ago. 1985. pp. 127-141. 1985. Andrew Tomkins, Practical and Theorical Issues in refetching and Caching, tesis doctoral, Universidad de Carnegie Mellon, Pittsburgh, Oct. de 1997. Pei Cao, Edward W. Felten, y Kai Li, Aplication-Controlled File Caching Policies, Proc. USENIX, conferencia tcnica, Junio de 1994. Wolfgang Effelsberg, Principles of Database Buffer Management, ACM Transactions on Database Systems, Vol. 9, No. 4, Dic. 1984, pp. 560-595. 1984. Andrew S. Tanenbaum, Modern operating systems. 2nd ed. Prentice Hall, 2001. pp. 214228. Garth A. Gibson, Jeffrey Scott Vitter y John Wilkes, Report of the Working Group on Storage I/O for Large-Scale Computing, ACM Workshop on Strategic Directions in Computing Research, Dic. 1996. Pei Cao, Application-Controlled File Caching and Prefetching, tesis doctoral, Universidad de Princeton, Enero de 1996. Todd C. Mowry, Monica S. Lam, y Anoop Gupta, Design and Evaluation of a Compiler Algorithm for Prefetching, Fifth International Conference on Architectural Support for Programming Languages and Operating Systems, Oct. de 1992. Asit Dan, Philip S. Yu y Jen-Yao Chung, Characterization of Database Access Pattern for Analytic Prediction of Buffer Hit Probability, VLDB Journal, vol. 4, No. 1. 1995. pp 127-154. G. Elsa Jurez, Optimizacin de Estrategias de Acceso para un Sistema Manejador de Bases de Datos Distribuidas, tesis de maestra, Centro Nacional de Investigacin y Desarrollo Tecnolgico, Cuernavaca, Mor., Mxico, Junio de 1995.