24.3. BASES DE DATOS EN MEMORI A P RI NC I P AL

Transcripción

1 FUNDAMENTOS DE BASES DE DATOS Recuperación de los flujos de trabajo El objetivo de la recuperación de los flujos de trabajo es hacer que se cumpla la atomicidad ante fallos de los flujos de trabajo. Los procedimientos de recuperación deben asegurarse de que, si se produce un fallo en cualquiera de los componentes de procesamiento del flujo de trabajo (incluido el planificador), éste acabe alcanzando un estado aceptable de terminación (sea abortado o comprometido). Por ejemplo, el planificador puede continuar procesando tras el fallo y la recuperación, como si no hubiera pasado nada, lo que proporciona recuperabilidad hacia delante. En caso contrario, el planificador puede abortar todo el flujo de trabajo (es decir, alcanzar uno de los estados globales abortados). D e cualquier forma, puede que haga falta comprometer algunas subtransacciones o incluso remitirlas para su ejecución (por ejemplo, las subtransacciones compensadoras). Se da por supuesto que las entidades de procesamiento implicadas en el flujo de trabajo tienen sus propios sistemas locales de recuperación y tratan sus fallos locales. Para recuperar el contexto del entorno de ejecución las rutinas de recuperación de los fallos deben restaurar la información de estado del planificador en el momento del fallo, incluida la información sobre el estado de ejecución de cada tarea. Por tanto, la información de estado correspondiente debe registrarse en almacenamiento estable. T ambién hay que considerar el contenido de las colas de mensajes. Cuando un agente transfiere una tarea a otro, la transferencia debe ejecutarse exactamente una vez: si la transferencia tiene lugar dos veces, puede que se ejecute dos veces una tarea; si no se produce la transferencia, puede que se pierda la tarea. La mensajería persistente (Apartado ) proporciona exactamente las características para asegurar una transferencia positiva y única Sistemas gestores de flujos de trabajo Los flujos de trabajo suelen codificarse a mano como parte de los sistemas de aplicaciones. Por ejemplo, los sistemas de planificación de los recursos de las empresas (enterprise resource planning, ERP), que ayudan a coordinar las actividades en toda la empresa, tienen incorporados numerosos flujos de trabajo. El objetivo de los sistemas gestores de flujos de trabajo es simplificar la construcción de flujos de trabajo y hacerlos más dignos de confianza, permitiéndoles que se especifiquen en un modo de nivel elevado y se ejecuten de acuerdo con la especificación. H ay gran número de sistemas comerciales de gestión de flujos de datos; algunos, como FlowMark de IBM, son sistemas gestores de flujos de trabajo de propósito general, mientras que otros son específicos de flujos de trabajo concretos, como los sistemas de procesamiento de órdenes o los sistemas de comunicación de fallos. En el mundo actual de organizaciones interconectadas, no es suficiente gestionar los flujos de trabajo exclusivamente en el interior de una organización. Los flujos de trabajo que atraviesan las fronteras organizativas se están volviendo cada vez más frecuentes. Por ejemplo, considérese un pedido realizado por una organización y comunicado a otra organización que lo atiende. En cada organización puede que haya un flujo de trabajo asociado con el pedido, y es importante que los flujos de trabajo puedan operar entre sí con objeto de minimizar la intervención humana. La Coalición de gestión de flujos de trabajo (W orkflow Management Coalition) ha desarrollado estándares para la interoperatividad entre sistemas de flujos de trabajo. Los esfuerzos actuales de normalización utilizan X ML como lenguaje subyacente para comunicar la información sobre el flujo de trabajo. Véanse las notas bibliográficas para obtener más información BASES DE DATOS EN MEMORI A P RI NC I P AL Para permitir una velocidad elevada de procesamiento de transacciones (centenares o millares de transacciones por segundo) hay que utilizar hardware de alto rendimiento y aprovechar el paralelismo. Estas técnicas, por sí solas, no obstante, resultan insuficientes para obtener tiempos de respuesta muy bajos, ya que las operaciones de E/S de disco siguen constituyendo un cuello de botella: se necesitan alrededor de diez milisegundos para cada operación de E/S y esta cifra no se ha reducido a una velocidad comparable con el aumento en la velocidad de los procesadores. Las operaciones de E/S suelen ser el cuello de botella de las operaciones de lectura y de los compromisos de las transacciones. La elevada latencia de los discos (alrededor de diez milisegundos de promedio) no sólo aumenta el tiempo necesario para tener acceso a un elemento de datos, sino 596 que también limita el número de accesos por segundo. Se puede hacer un sistema de bases de datos menos ligado a los discos aumentando el tamaño de la memoria intermedia de la base de datos. Los avances en la tecnología de la memoria principal permiten construir memorias principales de gran tamaño con un coste relativamente bajo. H oy en día los sistemas comerciales de sesenta y cuatro bits pueden soportar memorias principales de decenas de gigabytes. Para algunas aplicaciones, como el control en tiempo real, es necesario almacenar los datos en la memoria principal para cumplir los requisitos de rendimiento. El tamaño de memoria exigido para la mayoría de estos sistemas no resulta excepcionalmente grande, aunque hay unas cuantas aplicaciones que exigen que sean residentes en la memoria varios gigabytes de datos.

2 CAPÍTULO 24 PROCESAMIENTO AVANZADO DE TRANSACCIONES Dado que el tamaño de la memoria ha estado creciendo con una velocidad muy elevada, se puede esperar que un número creciente de aplicaciones tenga datos que quepan en la memoria principal. Las memorias principales de gran tamaño permiten el procesamiento más rápido de las transacciones, ya que los datos están residentes en la memoria. No obstante, sigue habiendo limitaciones relacionadas con los discos: Hay que guardar en almacenamiento estable los registros del registro histórico antes de comprometer una transacción. El rendimiento mejorado que hace posible la memoria principal de gran tamaño puede hacer que el proceso de registro se convierta en un cuello de botella. Se puede reducir el tiempo de compromiso creando un búfer de registro estable en la memoria principal, utilizando RAM no volátil (implementada, por ejemplo, mediante memoria sustentada por baterías). La sobrecarga impuesta por el registro también puede reducirse mediante la técnica de compromiso e n g ru po estudiada más adelante en este apartado. La productividad (el número de transacciones por segundo) sigue estando limitada por la velocidad de transferencia de datos del disco de registro. Sigue habiendo que escribir los bloques de la memoria intermedia marcados como modificados por las transacciones comprometidas para que se reduzca la cantidad de registro histórico que hay que volver a ejecutar en el momento de la recuperación. Si la velocidad de actualización es extremadamente elevada, la velocidad de transferencia de los datos al disco puede convertirse en un cuello de botella. Si el sistema falla, se pierde toda la memoria principal. En la recuperación el sistema tiene la memoria intermedia de la base de datos vacía y hay que introducir desde el disco los elementos de datos cuando se tenga acceso a ellos. Por tanto, incluso una vez que esté completa la recuperación hace falta algo de tiempo antes de que se cargue completamente la base de datos en memoria principal y se pueda reanudar el procesamiento de transacciones de alta velocidad. Por otro lado, las bases de datos en memoria principal ofrecen oportunidades para la optimización: Como la memoria resulta más costosa que el espacio de disco, hay que diseñar las estructuras internas de los datos de la memoria principal para reducir los requisitos de espacio. No obstante, las estructuras de datos pueden tener punteros que atraviesen varias páginas a diferencia de los de las bases de datos en disco, en las que el coste de que la operación de E/S atraviese varias páginas resultaría excesivamente elevado. Por ejemplo, las 597 estructuras arbóreas de las bases de datos en memoria principal pueden ser relativamente profundas, a diferencia de los árboles B +, pero deben minimizar los requisitos de espacio. No hace falta clavar en la memoria las páginas de la memoria intermedia antes de que se tenga acceso a los datos, ya que las páginas de la memoria intermedia no se sustituyen nunca. Las técnicas de procesamiento deben diseñarse para minimizar la sobrecarga de espacio, de modo que no se superen los límites de la memoria mientras se evalúa una consulta; esa situación daría lugar a que se paginara el área de intercambio y ralentizaría el procesamiento de la consulta. Una vez eliminado el cuello de botella de las operaciones de E/S del disco, pueden convertirse en cuellos de botella operaciones como los bloqueos y los pestillos. Hay que eliminar estos cuellos de botella mediante mejoras en la implementación de estas operaciones. Los algoritmos de recuperación pueden optimizarse, ya que rara vez hace falta borrar las páginas para hacer sitio a otras páginas. TimesTen y DataBlitz son dos productos de bases de datos en memoria principal que aprovechan varias de estas optimizaciones, mientras que la base de datos de O racle ha añadido características especiales para soportar memorias principales de tamaño muy grande. Se da información adicional sobre las bases de datos en memoria principal en las referencias de las notas bibliográficas. El proceso de comprometer una transacción T exige que estos registros se escriban en almacenamiento estable: Todos los registros del registro histórico asociados con T que no se hayan remitidos al almacenamiento estable. El registro < T comprometida > del registro histórico. Estas operaciones de salida suelen exigir la salida de bloques que sólo se hallan parcialmente llenos. Para asegurarse de que se saquen bloques casi llenos se utiliza la técnica de compromiso en g rupo. En lugar de intentar comprometer T cuando se complete T, el sistema espera hasta que se hayan completado varias transacciones, o hasta que haya pasado un determinado periodo de tiempo desde que se completó la ejecución de una transacción. Luego compromete el grupo de transacciones que están esperando, todas juntas. Los bloques escritos en el registro histórico en almacenamiento estable contienen registros de varias transacciones. Mediante una cuidadosa selección del tamaño del grupo y del tiempo máximo de espera, el sistema puede asegurarse de que los bloques estén llenos cuando se escriben en

3 FUNDAMENTOS DE BASES DE DATOS el almacenamiento estable sin hacer que las transacciones esperen demasiado. Esta técnica da como resultado, en promedio, menos operaciones de salida por cada transacción comprometida. Aunque el compromiso en grupo reduce la sobrecarga impuesta por el registro histórico, da lugar a un ligero retraso en el compromiso de las transacciones que llevan a cabo actualizaciones. El retraso puede hacerse bastante pequeño (del orden de diez milisegundos), lo que resulta aceptable para muchas aplica- ciones. Estos retrasos pueden eliminarse si los discos o los controladores de disco soportan los búferes de RAM no volátil para las operaciones de escritura. Las transacciones pueden comprometerse en cuanto la operación de escritura se lleva a cabo en la memoria intermedia de RAM no volátil. En este caso, no hay necesidad de compromiso en grupo. Obsérvese que el compromiso en grupo resulta útil incluso en bases de datos con datos residentes en disco SISTEMAS DE TRANSACCIONES DE TIEMPO REAL Las restricciones de integridad que se han considerado hasta ahora corresponden a los valores almacenados en la base de datos. En determinadas aplicaciones las restricciones incluyen tiempos límite en los que se tiene que haber completado una tarea. Entre estas aplicaciones están la gestión de factorías, el control del tráfico y la planificación. Cuando se incluyen tiempos límite, la corrección de la ejecución ya no es exclusivamente un problema de consistencia de la base de datos. Por el contrario, hay que preocuparse por el número de tiempos límite sobrepasados y por el tiempo que hace que se sobrepasaron. Los tiempos límite se caracterizan de la manera siguiente: Tiempo límite estricto. Pueden producirse problemas graves, como fallos del sistema, si no se completa una tarea antes de su tiempo límite. Tiempo límite firme. La tarea no tiene ningún valor si se completa después del tiempo límite. Tiempo límite flex ible. La tarea tiene un valor decreciente si se completa tras el tiempo límite, y el valor se aproxima a cero a medida que aumenta el retraso. Los sistemas con tiempos límite se denominan sistemas de tiempo real. La gestión de transacciones en los sistemas de tiempo real debe tener en cuenta los tiempos límite. Si el protocolo de control de concurrencia determina que la transacción T i debe esperar, puede hacer que T i supere el tiempo límite. En esos casos, puede que resulte preferible adelantar la transacción que mantiene el bloqueo y permitir que T i siga adelante. El adelantamiento debe utilizarse con cuidado, no obstante, ya que el tiempo perdido por la transacción adelantada (debido al retroceso y al reinicio) puede hacer que la transacción supere su tiempo límite. Por desgracia, es difícil determinar si es preferible retroceder o esperar en una situación dada. Una de las principales dificultades para soportar las restricciones de tiempo real surge de la variabilidad en el tiempo de ejecución de las transacciones. En el caso más favorable, todos los accesos a los datos hacen referencia a datos de la memoria intermedia de la base de datos. En el peor de los casos, cada acceso hace que se escriba una página de la memoria intermedia en el disco (precedida de los registros del registro histórico necesario), seguido de la lectura desde el disco de la página que contiene los datos a los que hay que tener acceso. Como los dos o más accesos al disco necesarios en el peor de los casos tardan varios órdenes de magnitud más que las referencias a la memoria principal necesarias en el caso más favorable, el tiempo de ejecución de las transacciones puede estimarse con muy poca precisión si los datos están residentes en el disco. Por tanto, se suelen utilizar las bases de datos en memoria principal si hay que cumplir restricciones de tiempo real. Sin embargo, aunque los datos estén residentes en la memoria principal, la variabilidad del tiempo de ejecución surge de las esperas de los bloqueos, de los abortos de las transacciones, etcétera. Los investigadores han dedicado esfuerzos considerables al control de concurrencia para las bases de datos de tiempo real. Han ampliado los protocolos de bloqueo para conceder una prioridad más elevada a las transacciones con tiempos límite más próximas. Han hallado que los protocolos de concurrencia optimistas tienen un buen comportamiento en las bases de datos de tiempo real; es decir, estos protocolos dan lugar a menos tiempos límite sobrepasados incluso que los protocolos de bloqueo ampliados. Las notas bibliográficas proporcionan referencias para la investigación en el área de las bases de datos de tiempo real. En los sistemas de tiempo real, los tiempos límite, y no la velocidad absoluta, son el aspecto más importante. El diseño de sistemas de tiempo real implica asegurarse de que hay suficiente capacidad de procesamiento como para respetar las tiempos límite sin necesitar excesivos recursos de hardware. La consecución de este objetivo, pese a la variabilidad de los tiempos de ejecución resultante de la gestión de las transacciones, sigue constituyendo un problema sin resolver. 598

4 CAPÍTULO 24 PROCESAMIENTO AVANZADO DE TRANSACCIONES TRANSACCIONES DE LARG A DURACIÓ N El concepto de transacción se desarrolló inicialmente en el contexto de las aplicaciones de procesamiento de datos, en el que la mayor parte de las transacciones son de corta duración y no interactivas. Aunque las técnicas presentadas aquí y, anteriormente, en los Capítulos 15, 16 y 17 funcionan bien en esas aplicaciones, surgen problemas graves cuando se aplica este concepto a sistemas de bases de datos que implican la interacción con personas. Esas transacciones tienen las siguientes propiedades principales: Larga duración. Una vez que una persona interactúa con una transacción activa esa transacción se transforma en una transacción de larga duración desde la perspectiva de la computadora, ya que el tiempo de respuesta de las personas es lento en comparación con la velocidad de las computadoras. Además, en las aplicaciones de diseño, la actividad humana puede suponer horas, días o periodos incluso más prolongados. Por tanto, las transacciones pueden ser de larga duración en términos humanos, además de serlo en términos de la máquina. E xposición de datos no comprometidos. Los datos generados y mostrados a los usuarios por las transacciones de larga duración no están comprometidos, ya que la transacción puede abortarse. Por tanto, los usuarios y, en consecuencia, las demás transacciones pueden verse forzados a leer datos no comprometidos. Si varios usuarios están colaborando en un proyecto puede que las transacciones de los usuarios necesiten intercambiar datos antes de comprometer las transacciones. S ubtareas. Cada transacción interactiva puede consistir en un conjunto de subtareas iniciadas por el usuario. Puede que el usuario desee abortar una subtarea sin hacer necesariamente que aborte toda la transacción. R ecuperabilidad. Resulta inaceptable abortar una transacción interactiva de larga duración debido a un fallo del sistema. La transacción activa debe recuperarse hasta un estado que existiera poco antes del fallo para que se pierda una cantidad de trabajo humano relativamente pequeña. R endimiento. El buen rendimiento de los sistemas interactivos de transacciones se define como tiempo de respuesta rápido. Esta definición difiere de la de los sistemas no interactivos, en los que el objetivo es una productividad (número de transacciones por segundo) elevada. Los sistemas con productividad elevada hacen un uso eficiente de los recursos del sistema. Sin embargo, en el caso de las transacciones interactivas, el recurso más 599 costoso es el usuario. Si hay que optimizar la eficiencia y la satisfacción del usuario, el tiempo de respuesta debe ser rápido (desde el punto de vista humano). En los casos en los que una tarea tarda mucho tiempo, el tiempo de respuesta debe ser predecible (es decir, la variabilidad de los tiempos de respuesta debe ser baja), de modo que los usuarios puedan administrar bien su tiempo. En los Apartados a se verá el motivo de que estas cinco propiedades sean incompatibles con las técnicas presentadas hasta ahora, y se estudiará el modo en que se pueden modificar esas técnicas para acomodar las transacciones interactivas de larga duración Ejecuciones no secuenciables Las propiedades que se han estudiado hacen poco práctico obligar a que se cumpla el requisito empleado en los capítulos anteriores de que sólo se permitan las planificaciones secuenciables. Cada uno de los protocolos de control de concurrencia del Capítulo 16 tiene efectos negativos sobre las transacciones de larga duración: B loq ueo de dos fases. Cuando no se puede conceder un bloqueo, la transacción que lo ha solicitado se ve obligada a esperar a que se desbloquee el elemento de datos en cuestión. La duración de la espera es proporcional a la duración de la transacción que sostiene el bloqueo. Si el elemento de datos está bloqueado por una transacción de corta duración, se espera que el tiempo de espera sea breve (excepto en el caso de interbloqueos o de carga extraordinaria del sistema). Sin embargo, si el elemento de datos está bloqueado por una transacción de larga duración, la espera será prolongada. Los tiempo de espera elevados provocan tiempos de respuesta mayores y una mayor posibilidad de interbloqueos. P rotocolos basados en grafos. Los protocolos basados en grafos permiten que se liberen los bloqueos antes que con los protocolos de bloqueo de dos fases, y evitan los interbloqueos. Sin embargo, imponen una ordenación de los elementos de datos. Las transacciones deben bloquear los elementos de datos de manera consistente con esta ordenación. En consecuencia, puede que una transacción tenga que bloquear más datos de los que necesita. Además, la transacción debe mantener el bloqueo hasta que no haya posibilidades de que se vuelva a necesitar. Por tanto, es probable que se produzcan esperas por bloqueos de larga duración.

5 FUNDAMENTOS DE BASES DE DATOS Protocolos basados en las marcas temporales. Los protocolos de marcas temporales nunca necesitan que las transacciones esperen. Sin embargo, exigen que las transacciones se aborten bajo ciertas circunstancias. Si se aborta una transacción de larga duración, se pierde una cantidad sustancial de trabajo. Para las transacciones no interactivas este trabajo perdido supone un problema de rendimiento. Para las transacciones interactivas el problema también es de satisfacción de los usuarios. Resulta muy poco deseable que el usuario descubra que se han deshecho varias horas de trabajo. Protocolos de v alidación. Al igual que los protocolos basados en las marcas temporales, los protocolos de validación hacen que se cumpla la secuencialidad mediante el aborto de transacciones. Por tanto, parece que el cumplimiento de la secuencialidad provoca esperas de larga duración, el aborto de transacciones de larga duración o ambas cosas. Hay resultados teóricos, citados en las notas bibliográficas, que sustentan esta conclusión. Surgen dificultades adicionales con el cumplimiento de la secuencialidad cuando se consideran los problemas de las recuperaciones. Y a se ha estudiado el problema de los retrocesos en cascada, en los que el aborto de una transacción puede conducir al aborto de otras transacciones. Este fenómeno no es deseable, especialmente para las transacciones de larga duración. Si se utiliza el bloqueo, se deben mantener bloqueos exclusivos hasta el final de la transacción, si hay que evitar el retroceso en cascada. Este mantenimiento de bloqueos exclusivos, no obstante, aumenta la duración del tiempo de espera de las transacciones. Por tanto, parece que el cumplimiento de la atomicidad de las transacciones debe llevar a una mayor probabilidad de las esperas de larga duración o a crear la posibilidad de retrocesos en cascada. Estas consideraciones son la base de los conceptos alternativos de corrección de las ejecuciones concurrentes y de la recuperación de transacciones que se considerarán en el resto de este apartado Control de concurrencia El objetivo fundamental del control de concurrencia de las bases de datos es asegurarse de que la ejecución concurrente de las transacciones no da lugar a una pérdida de la consistencia de la base de datos. El concepto de secuencialidad puede utilizarse para conseguir este objetivo, ya que todas las planificaciones secuenciables conservan la consistencia de las bases de datos. No obstante, no todas las planificaciones que conservan la consistencia de las bases de datos son secuenciables. Por ejemplo, considérese nuevamente una base de datos bancaria que consista en dos cuentas, A y B, con el requisito de consistencia de que se conserve la suma A + B. 600 T 1 T 2 leer(a) A := A 50 escribir(a) leer(b) B := B + 50 escribir(b) leer(b) B := B 10 escribir(b) leer(a) A := A + 10 escribir(a) FIGURA P la n ific a c ión n o s e c u e n c ia b le e n c u a n to a c on - flic tos. Aunque la planificación de la Figura 24.5 no es secuenciable para conflictos, pese a todo, conserva la suma de A + B. También ilustra dos aspectos importantes del concepto de corrección sin secuencialidad. La corrección depende de las restricciones de consistencia concretas de la base de datos. La corrección depende de las propiedades de las operaciones llevadas a cabo por cada transacción. En general, no es posible llevar a cabo un análisis automático de las operaciones de bajo nivel de las transacciones y comprobar su efecto en las restricciones de consistencia de la base de datos. Sin embargo, hay técnicas más sencillas. Una de ellas es el empleo de las restricciones de consistencia de la base de datos como base de una división de la base de datos en subbases de datos en las que se puede administrar por separado la concurrencia. Otra es el intento de tratar algunas operaciones aparte de leer y de escribir como operaciones fundamentales de bajo nivel y ampliar el control de concurrencia para trabajar con ellas. Las notas bibliográficas hacen referencia a otras técnicas para asegurar la consistencia sin exigir secuencialidad. Muchas de estas técnicas aprovechan variedades del control de concurrencia multiversión (véase el Apartado 17.6). A las aplicaciones de procesamiento de datos más antiguas que sólo necesitan una versión los protocolos multiversión les imponen una elevada sobrecarga de espacio para almacenar las versiones adicionales. Dado que muchas de las nuevas aplicaciones de bases de datos exigen el mantenimiento de las versiones de los datos, las técnicas de control de concurrencia que aprovechan varias versiones resultan prácticas Transacciones anidadas y multinivel Las transacciones de larga duración pueden considerarse como conjuntos de subtareas relacionadas o subtransacciones. Al estructurar cada transacción como un conjunto de subtransacciones, se puede mejorar el

6 CAPÍTULO 24 PROCESAMIENTO AVANZADO DE TRANSACCIONES paralelismo, ya que puede que sea posible ejecutar en paralelo varias subtransacciones. Además, es posible trabajar con los fallos de las subtransacciones (debidos a abortos, fallos del sistema, etcétera) sin tener que hacer retroceder toda la transacción de larga duración. Una transacción anidada o multinivel T consiste en un conjunto T = {t 1, t 2,, t n } de subtransacciones y en un orden parcial P sobre T. Cada subtransacción t i de T puede abortar sin obligar a que T aborte. En lugar de eso, puede que T reinicie t i o simplemente escoja no ejecutar t i. Si se compromete t i, esa acción no hace que t i sea permanente (a diferencia de la situación del Capítulo 17). En vez de eso, t i se compromete con T, y puede que todavía aborte (o exija compensación; véase el Apartado ) si T aborta. La ejecución de T no debe violar el orden parcial P. Es decir, si un trazo t i t j aparece en el grafo de precedencia, t j t i no debe estar en el cierre transitivo de P. El anidamiento puede tener varios niveles de profundidad, representando la subdivisión de una transacción en subtareas, subsubtareas, etcétera. En el nivel inferior de anidamiento se tienen las operaciones estándar de bases de datos leer y escribir que se han utilizado anteriormente. Si se permite a una subtransacción de T liberar los bloqueos al completarse, T se denomina transacción multinivel. Cuando una transacción multinivel representa una actividad de larga duración, a veces se denomina saga. De manera alternativa, si los bloqueos mantenidos por la subtransacción t i de T se asignan de manera automática a T al concluir t i, T se denomina transacción anidada. Aunque el principal valor práctico de las transacciones multinivel surja en las transacciones complejas de larga duración, se utilizará el sencillo ejemplo de la Figura 24.5 para mostrar el modo en que el anidamiento puede crear operaciones de nivel superior que pueden mejorar la concurrencia. Se reescribe la transacción T 1, mediante las subtransacciones T 1,1 y T 1,2, que llevan a cabo operaciones de suma o de resta: T 1 consiste en T 1,1, que resta 50 de A T 1,2, que suma 50 a B De manera parecida, se reescribe la transacción T 2, mediante las subtransacciones T 2,1 y T 2,2, que también llevan a cabo operaciones de suma o de resta: T 2 consiste en T 2,1, que resta 10 de B T 2,2, que suma 10 a A No se especifica ninguna ordenación para T 1,1, T 1,2, T 2,1 y T 2,2. Cualquier ejecución de estas subtransacciones generará un resultado correcto. La planificación de la Figura 24.5 corresponde a la planificación < T 1,1, T 2,1, T 1,2, T 2,2 > Transacciones compensadoras Para reducir la frecuencia de las esperas de larga duración se dispone que las actualizaciones no comprometidas se muestren a otras transacciones que se ejecuten de manera concurrente. En realidad, las transacciones multinivel pueden permitir esta exposición. No obstante, la exposición de datos no comprometidos crea la posibilidad de retrocesos en cascada. El concepto de transacciones compensadoras ayuda a tratar este problema. Divídase la transacción T en varias subtransacciones t 1, t 2,, t n. Una vez comprometida la subtransacción t i, libera sus bloqueos. Ahora, si hay que abortar la transacción del nivel externo T, hay que deshacer el efecto de sus subtransacciones. Supóngase que las subtransacciones t 1,, t k se han comprometido y que t k+1 se estaba ejecutando cuando se tomó la decisión de abortar. Se pueden deshacer los efectos de t k+1 abortando esa subtransacción. Sin embargo, no es posible abortar las subtransacciones t 1,, t k, puesto que ya se han comprometido. En lugar de eso, se ejecuta una nueva subtransacción tc i, denominada tra nsa cció n compensa d ora, para deshacer el efecto de cada subtransacción t i. Es necesario que cada subtransacción t i tenga su transacción compensadora tc i. Las transacciones compensadoras deben ejecutarse en el orden inverso tc k,, tc 1. A continuación se ofrecen varios ejemplos de compensaciones: Considérese la planificación de la Figura 24.5, que se ha demostrado que es correcta, aunque no secuenciable en cuanto a conflictos. Cada subtransacción libera sus bloqueos una vez se completa. Supóngase que T 2 falla justo antes de su terminación, una vez que T 2,2 ha liberado sus bloqueos. Se ejecuta una transacción compensadora para T 2,2 que resta 10 de A y una transacción compensadora para T 2,1 que suma 10 a B. Considérese una inserción en la base de datos por la transacción T i que, como efecto lateral, provoca que se actualice el índice del árbol B +. La operación de inserción puede haber modificado varios nodos del índice del árbol B +. Otras transacciones pueden haber leído estos nodos al tener acceso a datos diferentes del registro insertado por T i. Como en el Apartado 17.9, se puede deshacer la inserción eliminando el registro insertado por T i. El resultado es un árbol B + correcto y consistente, pero no necesariamente uno con exactamente la misma estructura que la que se tenía antes de que se iniciara T i. Por tanto, la eliminación es una acción compensadora para la inserción. Considérese una transacción de larga duración T i que represente una reserva de viaje. La transacción T tiene tres subtransacciones: T i,1, que hace las reservas de billetes de avión; T i,2, que reserva los coches de alquiler; y T i,3, que reserva las habita-

7 FUNDAMENTOS DE BASES DE DATOS ciones de hotel. Supóngase que el hotel cancela la reserva. En lugar de deshacer todas las T i, se compensa el fallo de T i,3 eliminando la reserva de hotel antigua y realizando una nueva. Si el sistema falla en medio de la ejecución de una transacción del nivel externo hay que hacer retroceder sus subtransacciones cuando se recupere. Las técnicas descritas en el Apartado 17.9 pueden utilizarse con este fin. La compensación del fallo de una transacción exige que se utilice la semántica de la transacción que ha fallado. Para determinadas operaciones, como el incremento o la inserción en un árbol B +, la compensación correspondiente se define con facilidad. Para transacciones más complejas puede que los planificadores de la aplicación tengan que definir la forma correcta de compensación en el momento en que se codifique la transacción. Para las transacciones interactivas complejas puede que sea necesario que el sistema interactúe con el usuario para determinar la forma adecuada de compensación Problemas de implementación Los conceptos sobre las transacciones estudiados en este apartado crean serias dificultades para su implementación. Aquí se presentan unos cuantos y se estudia el modo de abordar esos problemas. Las transacciones de larga duración deben sobrevivir a los fallos del sistema. Se puede asegurar que lo harán llevando a cabo una operación rehacer con las subtransacciones comprometidas, y llevando a cabo una operación deshacer o una compensación para cualquier subtransacción de corta duración que estuviera activa en el momento del fallo. Sin embargo, estas acciones sólo resuelven parte del problema. En los sistemas típicos de bases de datos los datos internos del sistema como las tablas de bloqueos y las marcas temporales de las transacciones se conservan en almacenamiento volátil. Para que se pueda reanudar una transacción de larga duración tras un fallo hay que restaurar esos datos. Por tanto, es necesario registrar no sólo las modificaciones de la base de datos, sino también las modificaciones de los datos internos del sistema correspondientes a las transacciones de larga duración. El registro histórico de las actualizaciones se hace más complicado cuando hay en la base de datos ciertos tipos de elementos de datos. Un elemento de datos puede ser un diseño CAD, el texto de un documento u otra forma de diseño compuesto. Estos elementos de datos son de gran tamaño físico. Por tanto, guardar los valores antiguos y nuevos del elemento de datos en un registro del registro histórico no resulta deseable. Hay dos enfoques para reducir la sobrecarga de asegurar la recuperabilidad de elementos de datos de gran tamaño: Registro histórico de operaciones. Sólo se guardan en el registro histórico la operación llevada a cabo en el elemento de datos y el nombre del elemento de datos. El registro histórico de operaciones también se denomina registro histórico lógico. Para cada operación debe haber una operación inversa. Se lleva a cabo la operación deshacer utilizando la operación inversa y la operación rehacer utilizando la misma operación. La recuperación mediante el registro histórico de operaciones resulta más difícil, ya que rehacer y deshacer no son idempotentes. Además, el empleo del registro lógico para una operación que actualice varias páginas resulta muy complicado debido al hecho de que algunas, pero no todas, las páginas actualizadas pueden haberse escrito en el disco, por lo que resulta difícil aplicar tanto rehacer como deshacer a la operación en la imagen del disco durante la recuperación. El empleo del registro histórico físico de rehacer y registro histórico lógico de deshacer tal y como se describe en el Apartado 17.9 proporciona las ventajas de concurrencia del registro histórico lógico y evita los inconvenientes mencionados. Registro histórico y paginación en la sombra. El registro se utiliza para las modificaciones de elementos de datos de pequeño tamaño, pero los elementos de datos de gran tamaño se hacen recuperables mediante una técnica de paginación en la sombra (véase el Apartado 17.5). Cuando se utiliza esta técnica sólo hace falta almacenar por duplicado las páginas que se modifican realmente. Independientemente de la técnica empleada, las complejidades introducidas por las transacciones de larga duración y los elementos de datos de gran tamaño complican el proceso de recuperación. Por tanto, resulta deseable permitir que algunos datos no esenciales queden exentos del registro, y confiar en las copias de seguridad fuera de línea y en la intervención de las personas. 602

8 CAPÍTULO 24 PROCESAMIENTO AVANZADO DE TRANSACCIONES GESTIÓN DE TRANSACCIONES EN V ARIAS BASES DE DATOS Hay que recordar del Apartado 19.8 que un sistema con varias bases de datos crea la ilusión de una integración lógica de las bases de datos, en un sistema de bases de datos heterogéneo en el que los sistemas locales de bases de datos pueden emplear diferentes modelos lógicos de datos y lenguajes de definición y de manipulación diferentes, y pueden diferenciarse en sus mecanismo de control de concurrencia y de gestión de las transacciones. Los sistemas con varias bases de datos soportan dos tipos de transacciones: 1. Transacciones locales. Estas transacciones las ejecuta cada sistema local de base de datos fuera del control del sistema con varias bases de datos. 2. Transacciones globales. Estas transacciones se ejecutan bajo el control del sistema con varias bases de datos. 603 El sistema con varias bases de datos es consciente del hecho de que pueden ejecutarse transacciones locales en los sitios locales, pero no de las transacciones concretas que se ejecutan, ni de los datos a los que tienen acceso. Asegurar la autonomía local de cada sistema de bases de datos exige que no se realice ningún cambio en su software. Por tanto, el sistema de bases de datos de un sitio no puede comunicarse directamente con los de otros sitios para sincronizar la ejecución de transacciones globales activas en varios sitios. Dado que el sistema con varias bases de datos no tiene ningún control sobre la ejecución de las transacciones globales, cada sistema local debe utilizar un esquema de control de concurrencia (por ejemplo, el compromiso de dos fases o las marcas temporales) para asegurarse de que su planificación sea secuenciable. Además, en caso de bloqueo, cada sistema local debe poder protegerse contra la posibilidad de interbloqueos locales. La garantía de la secuencialidad local no es suficiente para asegurar la secuencialidad global. Como ejemplo, considérense dos transacciones globales T 1 y T 2, cada una de las cuales tiene acceso y actualiza a dos elementos de datos, A y B, ubicados en los sitios S 1 y S 2, respectivamente. Supóngase que las planificaciones locales son secuenciables. Sigue siendo posible que haya una situación en la que, en el sitio S 1, T 2 siga a T 1, mientras que, en S 2, T 1 siga a T 2, dando como resultado una planificación global no secuenciable. En realidad, aunque no haya concurrencia entre las transacciones globales (es decir, cada transacción global sólo se remite una vez que la anterior se compromete o aborta), la secuencialidad local no resulta suficiente para asegurar la secuencialidad global (véase el Ejercicio 24.14). En función de la implementación de los sistemas locales de bases de datos puede que una transacción global no pueda controlar el comportamiento exacto de los bloqueos de sus subtransacciones. Por tanto, incluso si todos los sistemas locales de bases de datos siguen el bloqueo de dos fases, puede que sólo sea posible asegurar que cada transacción local sigue las reglas del protocolo. Por ejemplo, puede que un sistema local de bases de datos comprometa su subtransacción y libere sus bloqueos mientras que la subtransacción de otro sistema local se sigue ejecutando. Si los sistemas locales permiten el control del comportamiento de los bloqueos y todos los sistemas siguen el bloqueo de dos fases, el sistema con varias bases de datos puede asegurar que las transacciones globales se bloqueen en la modalidad de dos fases y que los puntos de bloqueo de las transacciones en conflicto definan su orden global de secuencia. Si diferentes sistemas locales siguen diferentes mecanismos de control de concurrencia, sin embargo, esta forma directa de control global no funciona. Hay muchos protocolos para asegurar la consistencia pese a la ejecución concurrente de las transacciones globales y locales en los sistemas con varias bases de datos. Algunos se basan en imponer las condiciones suficientes para asegurar la secuencialidad global. Otros sólo aseguran una forma de consistencia más débil que la secuencialidad, pero la consiguen por medios menos restrictivos. Se considerará uno de estos últimos esquemas: la secuencialidad de dos niv eles. El Apartado 24.5 describe más enfoques de la consistencia sin secuencialidad; se citan otros enfoques en las notas bibliográficas. Un problema relacionado en los sistemas de bases de datos es el del compromiso atómico global. Si todos los sistemas locales siguen el protocolo de compromiso de dos fases, puede utilizarse este protocolo para conseguir la atomicidad global. No obstante, puede que los sistemas locales no diseñados para ser parte de un sistema distribuido no puedan participar en este protocolo. Aunque un sistema local pueda soportar el compromiso de dos fases, la organización propietaria del sistema puede que no desee permitir las esperas en los casos en los que se producen bloqueos. En esos casos, pueden alcanzarse compromisos que permitan la falta de atomicidad en determinadas modalidades de fallo. En la literatura proporcionada hay un tratamiento más extenso de estos asuntos (véanse las notas bibliográficas) Secuencialidad de dos niveles La secuencialidad de dos niveles (S2 N ) asegura la secuencialidad en dos niveles del sistema: Cada sistema local de bases de datos asegura la secuencialidad local entre sus transacciones locales, incluidas las que forman parte de las transacciones globales.

9 FUNDAMENTOS DE BASES DE DATOS El sistema con varias bases de datos asegura sólo la secuencialidad entre las transacciones globales, ignorando las ordenaciones inducidas por las transacciones locales. Resulta sencillo hacer que se cumpla cada uno de estos niveles de secuencialidad. Los sistemas locales ya ofrecen garantías de secuencialidad; por tanto, el primer requisito es sencillo de lograr. El segundo requisito sólo se aplica a una proyección de la planificación global en la que las transacciones locales no aparecen. Por tanto, el sistema con varias bases de datos puede asegurar el segundo requisito utilizando técnicas estándar de control de concurrencia (no importa la elección concreta de la técnica). Los dos requisitos de S2N no resultan suficientes para asegurar la secuencialidad global. Sin embargo, con el enfoque S2N, se adopta un requisito más débil que la secuencialidad, denominado corrección fuerte: 1. La conservación de la consistencia tal y como especifica un conjunto de restricciones de consistencia. 2. La garantía de que el conjunto de elementos de datos leído por cada transacción es consistente. Puede probarse que determinadas restricciones al comportamiento de las transacciones, combinadas con S2N, son suficientes para asegurar la corrección fuerte (aunque no necesariamente para asegurar la secuencialidad). Se citarán varias de estas restricciones. En cada uno de los protocolos se distingue entre los datos locales y los datos globales. Los elementos locales de datos pertenecen a un sitio concreto y se hallan bajo el control exclusivo de ese sitio. Obsérvese que no puede haber restricciones de consistencia entre los elementos locales de datos de sitios distintos. Los elementos globales de datos pertenecen al sistema con varias bases de datos y, aunque puede que se almacenen en un sitio local, se hallan bajo el control del sistema con varias bases de datos. El protocolo globales-lectura permite que las transacciones globales lean, pero no actualicen, los elementos locales de datos, mientras que impide el acceso a los datos globales por parte de las transacciones locales. El protocolo globales-lectura asegura la corrección fuerte si se cumplen todas las reglas siguientes: 1. Las transacciones locales sólo tienen acceso a los elementos locales de datos. 2. Las transacciones globales pueden tener acceso a los elementos globales de datos, y pueden leer los elementos locales de datos (aunque no deben escribirlos). 3. No hay restricciones de consistencia entre los elementos de datos locales y los globales. El protocolo locales-lectura concede a las transacciones locales acceso de lectura a los datos globales, 604 pero impide el acceso a los datos locales por las transacciones globales. En este protocolo hay que introducir el concepto de dependencia del valor. Cada transacción tiene una dependencia del valor si el valor que escribe en el elemento de datos de un sitio depende del valor que ha leído para el elemento de datos de otro sitio. El protocolo locales-lectura asegura la corrección fuerte si se cumplen todas las condiciones siguientes: 1. Las transacciones locales pueden tener acceso a los elementos locales de datos y pueden leer los elementos globales de datos almacenados en ese sitio (aunque no deban escribir elementos globales de datos). 2. Las transacciones globales sólo tienen acceso a los elementos globales de datos. 3. Ninguna transacción puede tener dependencia de ningún valor. El protocolo globales-escritura-lectura/localeslectura es el más generoso en términos de acceso a los datos de los protocolos que se han considerado. Permite que las transacciones globales lean y escriban los datos locales y que las transacciones locales lean los datos globales. Sin embargo, impone tanto la condición de dependencia del valor del protocolo locales-lectura como la condición del protocolo globales-lectura de que no haya restricciones de consistencia entre los datos locales y los globales. El protocolo globales-escritura-lectura/locales-lectura asegura la corrección fuerte si se cumplen todas las condiciones siguientes: 1. Las transacciones locales pueden tener acceso a los elementos locales de datos y pueden leer los elementos globales de datos almacenados en ese sitio (aunque no deben escribir los elementos globales de datos). 2. Las transacciones globales pueden tener acceso a los elementos globales de datos y a los elementos locales de datos (es decir, pueden leer y escribir todos los datos). 3. No hay restricciones de consistencia entre los elementos locales de datos y los globales. 4. Ninguna transacción puede tener dependencia de ningún valor Aseguramiento de la secuencialidad global Los primeros sistemas con varias bases de datos restringían las transacciones globales a ser sólo de lectura. Así evitaban la posibilidad de que las transacciones globales introdujeran inconsistencia en los datos, pero no eran lo bastante restrictivas como para asegurar la secuencialidad global. Resulta posible realmente obtener planificaciones globales de este tipo y desarrollar un esque-

10 CAPÍTULO 24 PROCESAMIENTO AVANZADO DE TRANSACCIONES ma para asegurar la secuencialidad global, y se pide al lector que haga las dos cosas en el Ejercicio Hay varios esquemas generales para asegurar la secuencialidad global en entornos en los que se pueden ejecutar actualizaciones y transacciones sólo de lectura. Varios de estos esquemas se basan en la idea del billete. Se crea un elemento de datos especial denominado billete en cada sistema local de bases de datos. Cada transacción global que tenga acceso a los datos de un sitio debe escribir en el billete de ese sitio. Este requisito asegura que las transacciones globales entren en conflicto directamente en cada sitio que visiten. Además, el gestor de las transacciones globales puede controlar el orden en el que se secuencian las transacciones globales controlando el orden en el que tienen acceso a los billetes. Las referencias a estos esquemas aparecen en las notas bibliográficas. Si se desea asegurar la secuencialidad global en entornos en los que no se generan en cada sitio conflictos locales directos, hay que realizar algunas suposiciones sobre las planificaciones autorizadas por el sistema local de bases de datos. Por ejemplo, si las planificaciones locales son tales que el orden de compromiso y el de secuenciación son siempre idénticos, se puede asegurar la secuencialidad controlando únicamente el orden en que se comprometen las transacciones. El problema de los esquemas que aseguran la secuencialidad global es que pueden restringir la concurrencia de manera inadecuada. Resultan especialmente propensos a hacerlo porque la mayor parte de las transacciones remiten al sistema de bases de datos subyacente las sentencias SQL, en lugar de remitir cada uno de los pasos de lectura, escritura, compromiso y aborto. Aunque sigue siendo posible asegurar la secuencialidad global con esta suposición, el nivel de concurrencia puede ser tal que otros esquemas, como la técnica de secuencialidad de dos niveles estudiada en el Apartado , resulten alternativas atractivas RESUMEN Los flujos de trabajo son actividades que implican la ejecución coordinada de varias tareas llevadas a cabo por diferentes entidades de proceso. No sólo existen en las aplicaciones informáticas, sino también en casi todas las actividades de una organización. Con el auge de las redes y la existencia de numerosos sistemas autónomos de bases de datos, los flujos de trabajo ofrecen una manera adecuada de llevar a cabo las tareas que implican a varios sistemas. Aunque los requisitos transaccionales ACID habituales resultan demasiado estrictos o no pueden implementarse para estas aplicaciones de flujo de trabajo, los flujos de trabajo deben satisfacer un conjunto limitado de propiedades transaccionales que garantiza que no se dejen los procesos en estados inconsistentes. Los monitores de procesamiento de transacciones se desarrollaron inicialmente como servidores con varias hebras que podían atender a un gran número de terminales desde un único proceso. Desde entonces han evolucionado y hoy en día ofrecen la infraestructura para la creación y gestión de sistemas complejos de procesamiento de transacciones que tienen gran número de clientes y varios servidores. Proporcionan servicios como colas duraderas de las solicitudes de los clientes y de las respuestas de los servidores, el encaminamiento de los mensajes de los clientes a los servidores, la mensajería persistente, el equilibrio de carga y la coordinación del compromiso de dos fases cuando las transacciones tienen acceso a varios servidores. Las memorias principales de gran tamaño se aprovechan en determinados sistemas para conseguir una gran productividad del sistema. En esos sistemas el registro histórico constituye un cuello de botella. Bajo el concepto de compromiso en grupo se puede reducir el número de salidas hacia el almacenamiento estable, lo que libera este cuello de botella. La gestión eficiente de las transacciones interactivas de larga duración resulta más compleja debido a las esperas de larga duración y a la posibilidad de los abortos. Dado que las técnicas de control de concurrencia utilizadas en el Capítulo 16 emplean las esperas, los abortos o las dos cosas, hay que considerar técnicas alternativas. Estas técnicas deben asegurar la corrección sin exigir la secuencialidad. Las transacciones de larga duración se representan como transacciones atómicas con operaciones atómicas de la base de datos anidadas en el nivel inferior. Si una transacción falla, sólo se abortan las transacciones activas de corta duración. Las transacciones activas de larga duración se reanudan una vez que se han recuperado todas las transacciones de corta duración. Se necesita una transacción compensadora para deshacer las actualizaciones de las transacciones anidadas que se hayan comprometido, si falla la transacción del nivel exterior. En los sistemas con restricciones de tiempo real la corrección de la ejecución no sólo implica la consistencia de la base de datos, sino también el cumplimiento de las tiempos límite. La amplia variabilidad de los tiempos de ejecución de las operaciones de lectura y de escritura complica el problema de la gestión de las transacciones en sistemas con restricciones temporales. Los sistemas con varias bases de datos proporcionan un entorno en el que las nuevas aplicaciones de bases 605

11 FUNDAMENTOS DE BASES DE DATOS de datos pueden tener acceso a los datos desde gran variedad de bases de datos existentes previamente ubicadas en varios entornos heterogéneos de hardware y de software. Los sistemas locales de bases de datos pueden emplear diferentes modelos lógicos y lenguajes diferentes de definición y de manipulación de datos, y puede que se diferencien en sus mecanismos de control de concurrencia y de gestión de las transacciones. Los sistemas con varias bases de datos crean la ilusión de la integración lógica de las bases de datos sin exigir su integración física. TÉ RMINOS DE REPASO Arquitecturas de los monitores TP Proceso por cliente Servidor único Varios servidores, un encaminador Varios servidores, varios encaminadores Arquitecturas de los sistemas gestores del flujo de trabajo Centralizadas Completamente distribuidas Parcialmente distribuidas Aseguramiento de la secuencialidad global Atomicidad ante fallos del flujo de trabajo Autonomía Bases de datos en memoria principal Bases de datos de tiempo real Billete Cambio de contexto Compromiso en grupo Coordinación de aplicaciones Gestor de recursos Llamada a procedimiento remoto (Remote Procedure Call, RPC) Corrección fuerte Datos globales Datos locales Ejecuciones no secuenciables Estado del flujo de trabajo Estados de ejecución Valores de salida Variables externas Estados de terminación del flujo de trabajo Abortado Aceptable Comprometido No aceptable Exposición de datos no comprometidos Flujos de trabajo transaccionales Ejecución del flujo de trabajo Entidad de procesamiento Especificación del flujo de trabajo Tarea Gestor de la cola Monitor TP Multitarea Protocolos De dependencia del valor Globales-lectura Globales-escritura-lectura/locales-lectura Locales-lectura Recuperación del flujo de trabajo Registro histórico lógico Saga Secuencialidad de dos niveles (S2N) Servidor con varias hebras Sistema gestor de flujos de trabajo Sistemas de tiempo real Subtareas Sistemas con varias bases de datos Tiempos límite Tiempo límite estricto Tiempo límite firme Tiempo límite flexible Transacciones anidadas Transacciones compensadoras Transacciones globales Transacciones de larga duración Transacciones locales Transacciones multinivel 606

12 CAPÍTULO 24 PROCESAMIENTO AVANZADO DE TRANSACCIONES EJ ERCICIOS Explíquese el modo en que los monitores TP administran los recursos de la memoria y del procesador de manera más efectiva que los sistemas operativos habituales Compárense las características de los monitores TP con las proporcionadas por los servidores web que soportan servlets (estos servidores se han denominado TP-lite) Considérese el proceso de admisión de nuevos alumnos en la universidad (o de nuevos empleados en la organización). a. Dese una imagen de alto nivel del flujo de trabajo comenzando por el procedimiento de matrícula de los estudiantes. b. Indíquense los estados de terminación aceptables y los pasos que implican intervención de personas. c. Indíquense los posibles errores (incluido el vencimiento del tiempo límite) y el modo en que se tratan. d. Estúdiese la cantidad de flujo de trabajo que se ha automatizado en la universidad Al igual que los sistemas de bases de datos, los sistemas de flujo de trabajo también necesitan la gestión de la concurrencia y de la recuperación. Indíquense tres motivos por los que no se puede aplicar simplemente un sistema relacional de bases de datos empleando bloqueo de dos fases, registro histórico de operaciones físicas de deshacer y compromiso de dos fases Si toda la base de datos cabe en la memoria principal, indíquese si sigue haciendo falta un sistema de bases de datos para administrar los datos. Explíquese la respuesta Considérese un sistema de bases de datos en memoria principal que se recupera de un fallo del sistema. Explíquense las ventajas relativas de Volver a cargar toda la base de datos en memoria principal antes de reanudar el procesamiento de las transacciones. Cargar los datos a medida que los soliciten las transacciones En la técnica de compromiso en grupo indicar el número de transacciones que deben formar parte de un grupo. Explíquese la respuesta Indíquese si un sistema de transacciones de alto rendimiento es necesariamente un sistema de tiempo real. Explíquese el motivo En un sistema de bases de datos que utilice el registro histórico de escritura adelantada indíquese el número de accesos a disco necesarios para leer un elemento de datos en el peor caso posible. Explíquese el motivo por el que esto supone un problema para los diseñadores de sistemas de bases de datos de tiempo real Explíquese el motivo por el que puede que no resulte práctico exigir la secuencialidad para las transacciones de larga duración Considérese un proceso con varias hebras que entrega mensajes desde una cola duradera de mensajes persistentes. Pueden ejecutarse de manera concurrente diferentes hebras, que intentan entregar mensajes diferentes. En caso de fallo en la entrega, el mensaje debe restaurarse en la cola. Modélense las acciones que lleva a cabo cada hebra como una transacción multinivel, de manera que no haga falta mantener los bloqueos en la cola hasta que se entregue cada mensaje Discútanse las modificaciones que hay que hacer en cada uno de los esquemas de recuperación tratados en el Capítulo 17 si se permiten las transacciones anidadas. Explíquense también las diferencias que se producen si se permiten las transacciones multinivel Indíquese la finalidad de las transacciones compensadoras. Preséntense dos ejemplos de su empleo Considérese un sistema con varias bases de datos en el que se garantice que, como máximo, está activa una transacción global en un momento dado y que cada sistema local asegura la secuencialidad local. a. Sugiéranse maneras de que el sistema con varias bases de datos pueda asegurar que haya como máximo una transacción global activa en cualquier momento dado. b. Demuéstrese mediante un ejemplo que resulta posible que se produzca una planificación global no secuenciable pese a estas suposiciones Considérese un sistema con varias bases de datos en el que cada sitio local asegura la secuencialidad local y todas las transacciones globales son sólo de lectura. a. Demuéstrese mediante un ejemplo que pueden producirse ejecuciones no secuenciables en este sistema. b. Muéstrese la manera en que se podría utilizar un esquema de billete para asegurar la secuencialidad global. 607

13 FUNDAMENTOS DE BASES DE DATOS NOTAS BIBLIOGRÁ FICAS Gray y Edwards [1995] proporcionan una introducción a las arquitecturas de los monitores TP; Gray y Reuter [1993] ofrecen una descripción detallada (y excelente) con nivel de libro de texto de los sistemas de procesamiento de transacciones, incluidos capítulos sobre los monitores TP. La descripción que se ha dado de los monitores TP se basa en estas dos fuentes. X/Open [1991] define la interfaz X/Open XA. El procesamiento de las transacciones en Tuxedo se describe en Huffman [1993]. Wipfler [1987] es uno de los textos sobre el desarrollo de aplicaciones mediante CICS. Fischer [2001] es un manual sobre los sistemas de flujo de trabajo. Un modelo de referencia para los flujos de trabajo, propuesto por la Coalición para la gestión de flujos de trabajo (Workflow Management Coalition), se presenta en Hollinsworth [1994]. El sitio web de la coalición es La descripción de flujos de trabajo que se ha dado sigue el modelo de Rusinkiewicz y Sheth [1995]. Reuter [1989] presenta ConTracts, un método para agrupar las transacciones en actividades con varias transacciones. Algunos problemas relativos a los flujos de trabajo se abordan en el trabajo sobre las actividades de larga duración descritas por Dayal et al. [1990] y Dayal et al. [1991]. Los autores proponen las reglas de evento-condición-acción como una técnica para especificar los flujos de trabajo. Jin et al. [1993] describen los problemas de los flujos de trabajo en las aplicaciones de telecomunicaciones. García-Molina y Salem [1992] ofrecen una introducción a las bases de datos en memoria principal. Jagadish et al. [1993] describen un algoritmo de recuperación diseñado para las bases de datos en memoria principal. En Jagadish et al. [1994] se describe un gestor de almacenamiento para las bases de datos en memoria principal. El procesamiento de transacciones en las bases de datos de tiempo real se estudia en Abbott y García-Molina [1999] y en Dayal et al. [1990]. Barclay et al. [1982] describen un sistema de bases de datos de tiempo real empleado en un sistema de conmutación de telecomunicaciones. Los problemas de la complejidad y de la corrección en las bases de datos de tiempo real se abordan en Korth et al. [1990b] y en Soparkar et al. [1995]. El control de concurrencia y las planificaciones en las bases de datos de tiempo real se estudian en Haritsa et al. [1990], en Hong et al. [1993] y en Pang et al. [1995]. Ozsoyoglu y Snodgrass [1995] es una reseña de la investigación en las bases de datos de tiempo real y en las bases de datos temporales. Las transacciones anidadas y las transacciones multinivel se presentan en Lynch [1983], Moss [1982], Moss [1985], Lynch y Merritt [1986], Fekete et al. [1990b], Fekete et al. [1990a], Korth y Speegle [1994] y Pu et al. [1988]. Los aspectos teóricos de las transacciones multinivel se presentan en Lynch et al. [1988] y en Weihl y Liskov [1990]. Se han definido varios modelos de transacciones ampliadas, incluidos Sagas (García-Molina y Salem [1987]), ACTA (Chrysanthis y Ramamritham [1994]), el modelo Con-Tract (Wachter y Reuter [1992]), ARIES (Mohan et al. [1992] y Rothermel y Mohan [1989]) y el modelo NT/PV (Korth y Speegle [1994]). El fraccionamiento de las transacciones para conseguir un rendimiento mayor se aborda en Shasha et al. [1995]. Beeri et al. [1989] presentan un modelo para la concurrencia en los sistemas de transacciones anidadas. El relajamiento de la secuencialidad se estudia en García-Molina [1983] y en Sha et al. [1988]. La recuperación en los sistemas de transacciones anidadas se estudia en Moss [1987], Haerder y Rothermel [1987] y Rothermel y Mohan [1989]. La gestión de las transacciones multinivel se estudia en Weikum [1991]. Gray [1981], Skarra y Z donik [1989], Korth y Speegle [1988] y Korth y Speegle [1990] estudian las transacciones de larga duración. El procesamiento de las transacciones para las transacciones de larga duración se considera en Weikum y Schek [1984], Haerder y Rothermel [1987], Weikum et al. [1990] y Korth et al. [1990a]. Salem et al. [1994] presentan una extensión del bloqueo de dos fases para las transacciones de larga duración al permitir la liberación precoz de los bloqueos en ciertas circunstancias. El procesamiento de las transacciones en las aplicaciones de diseño y de ingeniería del software se estudia en Korth et al. [1988], Kaiser [1990] y Weikum [1991]. El procesamiento de las transacciones en los sistemas con varias bases de datos se estudia en Breitbart et al. [1990], Breitbart et al. [1991], Breitbart et al. [1992], Soparkar et al. [1991], Mehrotra et al. [1992b] y Mehrotra et al. [1992a]. El esquema del billete se presenta en Georgakopoulos et al. [1994]. S2N se introduce en Mehrotra et al. [1991]. Un enfoque anterior, denominado cuasi-secuencialidad, se presenta en Du y Elmagarmid [1989]. 608

14 C A P Í T U L O 25 ORACLE H a k a n Ja k o b sso n Ora cle Co rp o ra tio n Cuando se fundó Oracle en como Softw are Development Laboratories por Larry Ellison, B ob Miner y Ed Oates no había productos de bases de datos relacionales comerciales. La compañía, cuyo nombre cambió posteriormente a Oracle, se estableció para construir un sistema de gestión de bases de datos como producto comercial y fue la primera en lanzarlo al mercado. Desde entonces Oracle ha mantenido una posición líder en el mercado de las bases de datos relacionales, pero con el paso de los años su producto y servicios ofrecidos han crecido más allá del servicio de este campo. Aparte de las herramientas directamente relacionadas con el desarrollo y gestión de bases de datos Oracle vende herramientas de inteligencia de negocio, incluyendo sistemas de gestión de bases de datos multidimensionales y un servidor de aplicaciones con una integración cercana al servidor de la base de datos. Aparte de los servidores y herramientas relacionados con las bases de datos, la compañía ofrece softw are para la planificación empresarial de recursos y gestión de relaciones con el cliente, incluyendo áreas como finanzas, recursos humanos, manufactura, márketing, ventas y gestión de cadenas de suministro. La unidad B usiness OnLine de Oracle ofrece servicios en estas áreas como un proveedor de servicios de aplicación. Este capítulo cubre un subconjunto de características, opciones y funcionalidad de los productos Oracle. Continuamente se desarrollan nuevas versiones de los productos, por lo que las descripciones de los productos están sujetas a cambios. Este conjunto de características descrito aquí está basado en la primera versión de Oracle9i. Antes de abordar a fondo cada uno de los temas se resumirá la motivación de cada uno de estos tipos de datos y algunos problemas importantes del trabajo con ellos HE R R A M I E N T A S P A R A E L D I S E Ñ O D E B A S E S D E D A T O S Y L A C O N S U L T A Oracle proporciona una serie de herramientas para el diseño, consulta, generación de informes y análisis de datos para bases de datos, incluyendo OLAP Herramientas para el diseño de bases de datos 611 La mayor parte de las herramientas de diseño de Oracle están incluidas en Oracle Internet Development Suite. Se trata de una familia de herramientas para los distintos aspectos de desarrollo de aplicaciones, incluyendo herramientas para el desarrollo de formularios, modelado de datos, informes y consultas. La familia de productos soporta el estándar UML (vé ase el Apartado ) para el modelado. P roporciona modelado de clases para generar código para componentes de negocio para un entorno Java así como modelado de actividades para el modelado del flujo de control de propósito general. La familia tambié n soporta X ML para el intercambio de datos con otras herramientas UML. La principal herramienta de diseño de bases de datos en la familia es Oracle Designer, que traduce la lógica de negocio y el flujo de datos en definiciones de esquemas y guiones procedimentales para la lógica de las aplicaciones. Soporta varias té cnicas de modelado tales como diagramas E-R, ingeniería de información y análisis y diseño de objetos. Oracle Designer almacena el diseño en Oracle Repository, que sirve como un único punto de metadatos para la aplicación. Los metadatos se pueden entonces utilizar para generar formularios e informes. Oracle Repository proporciona gestión de la configuración para objetos de bases de datos, formularios, clases Java, archivos X ML y otros tipos de archivos. La familia tambié n contiene herramientas de desarrollo de aplicaciones para generar formularios, informes, y herramientas para distintos aspectos de desarrollo basado en Java y X ML. El componente de inteligencia de negocio proporciona JavaB eans para funcionalidad analítica tal como visualización de datos, consultas y cálculos analíticos. Oracle tambié n posee una herramienta de desarrollo de aplicaciones para el almacé n de datos. Oracle W arehouse B uilder. W arehouse B uilder es una herramienta para el diseño e implantación de todos los aspectos de un almacé n de datos, incluyendo el diseño del esquema, asignaciones de datos y transformaciones, procesamiento de carga de datos y gestión de metadatos. Ora-

15 FUNDAMENTOS DE BASES DE DATOS cle Warehouse Builder soporta los esquemas 3FN y en estrella y puede también importar diseños desde Oracle Designer Herramientas de consulta Oracle proporciona herramientas de consulta, generación de informes y análisis de datos ad hoc, incluyendo OLAP. Oracle Discoverer es una herramienta basada en Web para realizar consultas, informes, análisis y publicación Web ad hoc para usuarios finales y analistas de datos. Permite a los usuarios abstraer y concretar conjuntos de resultados de datos pivote y almacenar cálculos como informes que se pueden publicar en una serie de formatos tales como hojas de datos o H T ML. Discoverer contiene asistentes que ayudan a los usuarios finales a visualizar los datos como gráficos. Oracle9i soporta un amplio conjunto de funciones analíticas tales como la agregación de clasificación y traslado en SQ L. La interfaz de consulta de Discoverer puede generar SQ L del que se puede aprovechar su funcionalidad y puede proporcionar a los usuarios finales una rica funcionalidad analítica. Puesto que el procesamiento tiene lugar en el sistema de gestión de la base de datos relacional, Discoverer no requiere un complejo motor de cálculo en el lado del cliente, y hay una versión de Discoverer con ex ploración. Oracle Ex press Server es un servidor de bases de datos multidimensionales. Soporta una amplia variedad de consultas analíticas, así como previsiones, modelado y gestión del escenario. Puede utilizar un sistema de gestión de bases de datos relacionales como un dorsal para almacenamiento o utilizar su propio almacenamiento multidimensional de los datos. Con la introducción de los servicios OLAP en Oracle9i, Oracle está evitando un motor de almacenamiento separado y trasladando la mayor parte de los cálculos a SQ L. El resultado es un modelo donde todos los datos residen en el sistema de gestión de la base de datos relacional, y los cálculos que no se pueden realizar en SQ L se realizan en un motor de cálculo que se ejecuta en el servidor de la base de datos. El modelo también proporciona una interfaz para la programación de aplica- connect by, que es una forma de recorrido de árboles que permite cálculos al estilo del cierre transitivo en una única instrucción SQ L. Es una sintax is específica de Oracle para una característica que Oracle tenía desde los años 80. Upsert e inserciones en varias tablas. La operación upsert combina una actualización y una inserciones Java OLAP. H ay muchas razones para evitar un motor de almacenamiento multidimensional separado: Un motor relacional puede dimensionarse a conjuntos de datos mucho mayores. Se puede utilizar un modelo de seguridad común para las aplicaciones analíticas y el almacén de datos. El modelado multidimensional se puede integrar con el modelado del almacén de datos. El sistema de gestión de la base de datos relacional tiene un conjunto mayor de características y funcionalidad en muchas áreas tales como alta disponibilidad, copia de seguridad y recuperación y soporte para herramientas de terceros. No hay necesidad de formar administradores de bases de datos para dos motores de bases de datos. El principal reto al evitar un motor de bases de datos multidimensional separado es proporcionar el mismo rendimiento. Un sistema de gestión de bases de datos mutidimensional que materializa todo o grandes partes de un cubo de datos puede ofrecer tiempos de respuesta muy cortos para muchos cálculos. Oracle ha enfocado este problema de dos formas. Oracle ha agregado soporte SQ L para un amplio rango de funciones analíticas, incluyendo cubos, abstracciones, conjuntos de agrupación, clasificaciones (ranks), agregación de traslado, funciones led y lag, cajones de histograma, regresión lineal y desviación estándar, junto con la capacidad de optimizar la ejecución de dichas funciones en el motor de la base de datos. Oracle ha ex tendido las vistas materializadas para permitir funciones analíticas, en particular los conjuntos de agrupación. La capacidad de materializar partes o todo el cubo es primordial para el rendimiento de un sistema de gestión de bases de datos multidimensionales y las vistas materializadas proporcionan al sistema de gestión de bases de datos relacionales la capacidad de realizar lo mismo V ARIACIONES Y EX TENSIONES DE SQ L Oracle9i soporta todas las características principales de SQ L:1999, con algunas pequeñas ex cepciones tales como distintos tipos de datos. Además, Oracle soporta un gran número de otras constructoras del lenguaje, algunas de las cuales casan con SQ L:1999, mientras que otras son específicas de Oracle en sintax is o funcionalidad. Por ejemplo Oracle soporta las operaciones OLAP descritas en el Apartado 22.2, incluyendo clasificación, agregación de traslado, cubos y abstracción. 612 Algunos ejemplos de las ex tensiones SQ L de Oracle son:

16 CAPÍTULO 25 ORACLE ción y es útil para combinar datos nuevos con antiguos en aplicaciones de almacén de datos. Si una nueva fila tiene el mismo valor de clave que una fila antigua se actualiza la fila antigua (por ejemplo agregando los valores desde la nueva fila), en otro caso se inserta la nueva fila en la tabla. Las inserciones en varias tablas permiten actualizar varias tablas basándose en una única exploración de los nuevos datos. cláusula with, que se describe en el Apartado Características relacionales orientadas a objetos Oracle tiene soporte extensivo para constructores relacionales orientados a objetos, incluyendo: T ipos de objetos. Se soporta un único modelo de herencia para las jerarquías de tipos. T ipos de colecciones. Oracle soporta varrays, que son arrays de longitud variable, y tablas anidadas. T ablas de objetos. Se utilizan para almacenar objetos mientras se proporciona una vista relacional de los atributos de los objetos. Funciones de tablas. Son funciones que producen conjuntos de filas como salida y se pueden utilizar en la cláusula from de una consulta. Las funciones de tablas se pueden anidar en Oracle. Si una función de tablas se utiliza para expresar algún formulario de transformación de datos, el anidamiento de varias funciones permite que se expresen varias transformaciones en una única instrucción. V istas de objetos. Proporcionan una vista de tablas de objetos virtuales de datos almacenados en una tabla relacional normal. Permite acceder o ver los datos en un estilo orientado a objetos incluso si los datos están realmente almacenados en un formato relacional tradicional. M é todos. Se pueden escribir en PL/SQL, Java o C. Funciones de agregación definidas por el usuario. Se pueden utilizar en instrucciones SQL de la misma forma que las funciones incorporadas tales como sum y count. T ipos de datos X M L. Se pueden utilizar para almacenar e indexar documentos XML. Oracle tiene dos lenguajes procedimentales principales, PL/SQL y Java. PL/SQL fue el lenguaje original de Oracle para los procedimientos almacenados y tiene una sintaxis similar al utilizado en el lenguaje Ada. Java se soporta mediante una máquina virtual Java dentro del motor de la base de datos. Oracle proporciona un paquete para encapsular procedimientos, funciones y variables relacionadas en unidades únicas. Oracle soporta SQLJ (SQL incorporado en Java) y JDBC y proporciona una herramienta para generar las definiciones de clases Java correspondientes a tipos de la base de datos definidos por el usuario Disparadores Oracle proporciona varios tipos de disparadores y varias opciones para el momento y forma en que se invocan (véase el Apartado 6.4 para una introducción a los disparadores en SQL). Los disparadores se pueden escribir en PL/SQL o Java o como llamadas a C. Para los disparadores que se ejecutan sobre instrucciones LMD tales como insert, update y delete, Oracle soporta disparadores de filas (row) y disparadores de instrucciones (statement). Los disparadores de filas se pueden ejecutar una vez por cada fila que se vea afectada (actualización o borrado, por ejemplo) por la operación LMD. Un disparador de instrucciones se ejecuta solamente una vez por instrucción. En cada caso, el disparador se puede definir tanto como un disparador before o after dependiendo de si se va a invocar antes o después de que se lleva a cabo la operación LMD. Oracle permite la creación de disparadores instead of para las vistas que no pueden estar sujetas a operaciones LMD. Dependiendo de la definición de la vista puede no ser posible para Oracle traducir una instrucción LMD en una vista a modificaciones de las tablas base subyacentes sin ambigü edad. Por ello las operaciones LMD sobre vistas están sujetas a numerosas restricciones. Se puede crear un disparador instead of sobre una vista para especificar manualmente las operaciones sobre las tablas base que van a ocurrir en respuesta a la operación LMD sobre la vista. Oracle ejecuta el disparador en lugar de la operación LMD y por consiguiente proporciona un mecanismo de rodeo de las restricciones sobre las operaciones LMD sobre las vistas. Oracle también tiene disparadores que ejecutan otros eventos, tales como el inicio o finalización de la base de datos, mensajes de error del servidor, inicio o finalización de sesión de un usuario e instrucciones LDD tales como las instrucciones create, alter o drop. 613

17 FUNDAMENTOS DE BASES DE DATOS ALMACENAMIENTO E INDEXACIÓ N En la jerga de Oracle, una base de datos consiste en información almacenada en archivos y se accede a través de un ejem p lar, que es un área de memoria compartida y un conjunto de procesos que interactúa con los datos en los archivos Espacios de tablas Una base de datos consiste en una o más unidades de almacenamiento lógicas denominadas espacios de tablas. Cada espacio de tablas, a su vez, consiste en una o más estructuras físicas denominadas archivos de datos. É stos pueden ser archivos gestionados por el sistema operativo o dispositivos en bruto. Normalmente una base de datos Oracle tendrá los siguientes espacios de tablas: El espacio de tablas del sistema, que siempre se crea. Contiene las tablas diccionario de datos y almacenamiento para los disparadores y los procedimientos almacenados. Espacios de tablas creados para almacenar los datos de usuario. Aunque los datos de usuario se pueden almacenar en el espacio de tablas del sistema es frecuentemente deseable separar los datos de usuario de los datos del sistema. Normalmente la decisión sobre los otros espacios de tablas que se deben crear está basada en el rendimiento, disponibilidad, capacidad de mantenimiento y facilidad de administración. Por ejemplo, puede ser útil tener varios espacios de tablas para las operaciones de copia de seguridad parcial y recuperación. Los espacios de tablas temporales. Muchas operaciones de base de datos requieren la ordenación de los datos y la rutina de ordenación puede tener que almacenar éstos temporalmente en el disco si la ordenación no se puede realizar en memoria. Se asignan espacios de tablas temporales a la ordenación, para realizar las operaciones de gestión de espacio involucradas en un volcado a disco más eficiente. Los espacios de tablas también se pueden utilizar como un medio para trasladar datos entre las bases de datos. Por ejemplo, es común trasladar los datos desde un sistema transaccional a un almacén de datos a intervalos regulares. Oracle permite trasladar todos los datos en un espacio de tablas de un sistema a otro sencillamente copiando los archivos y exportando e importando una pequeña cantidad de metadatos del diccionario de datos. Estas operaciones pueden ser mucho más rápidas que descargar los datos de una base de datos y después usar un descargador para insertarlos en la otra. Un requisito para esta característica es que ambos sistemas utilicen el mismo sistema operativo Segmentos El espacio en un espacio de tablas se divide en unidades, denominadas segmentos, cada una de las cuales contiene datos para una estructura de datos específica. Hay cuatro tipos de segmentos Segmentos de datos. Cada tabla en un espacio de tablas tiene su propio segmento de datos donde se almacenan los datos de la tabla a menos que ésta se encuentre dividida; si esto ocurre, existe un segmento de datos por división (la división en Oracle se describe en el Apartado ). Segmentos de índices. Cada índice en un espacio de tablas posee su propio segmento de índices, excepto los índices divididos, los cuales mantienen un segmento de índices por división. Segmentos temporales. Son segmentos utilizados cuando una operación de ordenación necesita escribir datos al disco o cuando éstos se insertan en una tabla temporal. Segmentos de retroceso. Se trata de segmentos que contienen información para deshacer los cambios de las transacciones de forma que se pueda deshacer una copia no terminada. También juegan un papel importante en el modelo de control de concurrencia en Oracle y para la recuperación de la base de datos, descrito en los Apartados y Debajo del nivel de segmentos se asigna espacio a un nivel de granularidad, denominado extensión. Cada extensión consiste en un conjunto de bloq u es contiguos de la base de datos. Un bloque de la base de datos es el nivel más bajo de granularidad en el cual Oracle ejecuta E/S a disco. Un bloque de base de la base de datos no tiene que tener el mismo tamaño que un bloque de un sistema operativo, pero debería ser un múltiplo. Oracle proporciona parámetros de almacenamiento que permiten un control detallado de cómo se asigna y gestiona el espacio, tales como: El tamaño de una extensión nueva que se va a asignar para proporcionar espacio a las filas que se insertan en una tabla. El porcentaje de utilización de espacio con el cual un bloque de la base de datos se considera lleno y con el cual no se introducirán más filas en ese bloque (dejando algo de espacio libre en un bloque se puede permitir que las filas existentes aumenten su tamaño cuando se realizan actualizaciones sin quedarnos sin espacio en el bloque) Tablas Una tabla estándar en Oracle está organizada en montículo; esto es, la ubicación de almacenamiento de una

18 CAPÍTULO 25 ORACLE fila en una tabla no está basada en los valores contenidos en la fila y se fija cuando la fila se inserta. Sin embargo, si la tabla se divide, el contexto de la fila afecta a la partición en la cual está almacenada. Hay varias características y variaciones. Oracle soporta las tablas anidadas; esto es, una tabla puede tener una columna cuyo tipo de datos sea otra tabla. La tabla anidada no se almacena en línea en la tabla padre sino que se almacena en una tabla separada. Oracle soporta tablas temporales donde la duración de los datos es la de la transacción en la cual se insertan los datos o la sesión de usuario. Los datos son privados a la sesión y se eliminan automáticamente al final de su duración. Una agrupación es otra forma de organización de los datos de la tabla (véase el Apartado 11.7). El concepto, en este contexto, no se debería confundir con otros significados de la palabra agrupación, tales como los relacionados con la arquitectura del ordenador. En una agrupación las filas de tablas diferentes se almacenan juntas en el mismo bloque según algunas columnas comunes. Por ejemplo, una tabla de departamento y una tabla de empleados se podrían agrupar de forma que cada fila en la tabla departamento se almacene junto con todas las filas de los empleados que trabajan en ese departamento. Los valores de la clave principal o clave externa se utilizan para determinar la ubicación de almacenamiento. Esta organización mejora el rendimiento cuando las dos tablas están combinadas pero sin un aumento de espacio de un esquema desnormalizado puesto que los valores en la tabla de departamento no están repetidos para cada empleado. Como compromiso, una consulta que involucra solamente la tabla departamento puede tener que involucrar un número sustancialmente más grande de bloques que si la tabla se almacenara sola. La organización en agrupación implica que una fila pertenece a un lugar específico; por ejemplo, una nueva fila de empleado se debe insertar con las otras filas para el mismo departamento. Por consiguiente, es obligatorio un índice en la columna de agrupación. Una organización alternativa es una agrupación asociativa. Aquí, Oracle calcula la localización de una fila aplicando una función asociativa al valor para la columna de agrupación. La función asociativa asigna la fila a un bloque específico en la agrupación asociativa. Puesto que no es necesario el recorrido del índice para acceder a una fila según su valor de columna de agrupación, esta organización puede ahorrar cantidades significativas de E/S a disco. Sin embargo, el número de cajones asociativos y otros parámetros de almacenamiento se deben establecer cuidadosamente para evitar problemas de rendimiento debido a demasiadas colisiones o malgasto de espacio debido a cajones asociativos vacíos. La organización según agrupación asociativa y según agrupación normal se puede aplicar a una única tabla. El almacenamiento de una tabla como una agrupación asociativa con la columna de la clave principal como la clave de la agrupación puede permitir un acceso basado en 615 un valor de clave principal con una única E/S a disco siempre que no haya desbordamiento para ese bloque de datos Tablas organizadas con índices En una tabla organizada con índices los registros se almacenan en un índice de árbol B en lugar de en un montículo. Una tabla organizada con índices requiere que se identifique una clave única para su uso como la clave del índice. Aunque una entrada en un índice normal contiene el valor de la clave y el identificador de fila de la fila indexada, una tabla organizada con índices reemplaza el identificador de fila con los valores de la columna para el resto de columnas en la tabla. Comparado con el almacenamiento de los datos en una tabla en montículo normal y la creación de un índice según las columnas clave, una tabla organizada con índices puede mejorar el rendimiento y el espacio. Consideremos la lectura de todos los valores de columna de una fila, dado su valor de clave principal. Para una tabla en montículo se requeriría un examen del índice seguido por un acceso a tabla mediante identificador de fila. Para una tabla organizada con índices solamente es necesario el examen del índice. Los índices secundarios sobre columnas que no sean clave de una tabla organizada con índices son distintos de los índices en una tabla en montículo normal. En una tabla en montículo cada fila posee un identificador de fila fijo que no cambia. Sin embargo, un árbol B se reorganiza al crecer o disminuir cuando se insertan o borran las entradas, y no hay garantía de que una fila permanezca en una ubicación dentro de una tabla organizada con índices. Por ello, un índice secundario en una tabla organizada con índices no contiene identificadores de fila normales, sino identificadores lógicos de fila. Un identificador lógico de fila se compone de dos partes: un identificador de fila física correspondiente a donde la fila estaba cuando se creó el índice o la última reconstrucción y un valor para la clave única. El identificador de fila física se conoce como una «suposición», puesto que sería incorrecto si la fila se ha trasladado. En este caso, la otra parte del identificador lógico de fila, el valor de la clave para la fila, se utiliza para acceder a la misma; sin embargo, este acceso es más lento que si la suposición hubiera sido correcta, puesto que involucra un recorrido del árbol B para la tabla organizada con índices desde la raíz hasta los nodos hoja, incurriendo potencialmente en varias operaciones E/S de disco. Sin embargo, si una tabla es altamente volátil y es probable que un buen porcentaje de suposiciones sean incorrectas, puede ser mejor crear un índice secundario con solamente valores clave, puesto que el uso de una suposición incorrecta puede producir una E/S a disco malgastada Índices Oracle soporta varios tipos distintos de índices. El tipo más comúnmente utilizado es un índice de árbol B, creado en una o varias columnas. (Nota: En la termi-

19 FUNDAMENTOS DE BASES DE DATOS nología de Oracle, como también en varios otros sistemas de bases de datos, un índice de árbol B es lo que se denomina un índice de árbol B+ en el Capítulo 12.) Las entradas de los índices tienen el siguiente formato: para un índice en las columnas col 1, col 2 y col 3, cada fila en la tabla en donde al menos una columna tenga un valor no nulo resultaría en la entrada de índice <col 1 > < col 2 > < col 3 > < id-fila > donde < col i > denota el valor para la columna i e < idfila > es la identificador de fila para la fila. Oracle puede opcionalmente comprimir el prefijo de la entrada para ahorrar espacio. Por ejemplo, si hay muchas combinaciones repetidas de valores < col 1 > < col 2 >, la representación de cada prefijo < col 1 > < col 2 > distinto se puede compartir entre las entradas que tienen esa combinación de valores, en lugar de almacenarlo explícitamente para cada entrada. La compresión de prefijos puede llevar a ahorros de espacio sustanciales Índices de mapas de bits Los índices de mapas de bits (descritos en el Apartado ) utilizan una representación de mapa de bits para entradas de índice que pueden llevar a un ahorro sustancial de espacio (y, por consiguiente, ahorro de E/S a disco), cuando la columna indexada tiene un número moderado de valores distintos. Los índices de mapas de bits en Oracle utilizan la misma clase de estructura de árbol B para almacenar las entradas que un índice normal. Sin embargo, donde un índice normal en una columna tuviera entradas de la forma < col 1 > < id-fila >, una entrada de índice de mapa de bits tendría la forma < col 1 > < id-filainicial > < id-filafinal > < mapabitscomprimido >. El mapa de bits conceptualmente representa el espacio de todas las filas posibles en la tabla entre los identificadores de la fila inicial y final. El número de tales filas posibles en un bloque depende de cuántas de ellas se pueden alojar en un bloque, lo cual va en función del número de columnas en la tabla y sus tipos de datos. Cada bit en el mapa de bits representa una fila posible en un bloque. Si el valor de la columna de esa fila es el de la entrada de índice, el bit se establece a 1. Si la fila tiene algún otro valor o la fila no existe realmente en la tabla, el bit se establece a 0 (es posible que la fila no exista realmente porque un bloque de la tabla pueda tener un número más pequeño de filas que el número que se calculó como el máximo posible). Si la diferencia es grande, el resultado pueden ser grandes cadenas de ceros consecutivos en el mapa de bits, pero el algoritmo de compresión trata dichas cadenas de ceros, por lo que el efecto negativo se limita. El algoritmo de compresión es una variación de una técnica de compresión denominada compresión de 616 mapas de bits alineados (Byte-Aligned Bitmap Compression, BBC). Esencialmente, una sección del mapa de bits donde la distancia entre dos unos consecutivos es suficientemente pequeña se almacena como mapas de bits. Si la distancia entre dos unos es suficientemente grande (esto es, hay un número suficiente de ceros entre ellos) se almacena el número de ceros. Los índices de mapas de bits permiten varios índices en la misma tabla para combinarse en la misma ruta de acceso si hay varias condiciones sobre las columnas indexadas en la cláusula where de una consulta. Por ejemplo, para la condición (col 1 = 1 or col 1 = 2) and col 2 > 5 and col 3 < > 10 Oracle podría calcular las filas que coinciden con la condición ejecutando operaciones booleanas sobre los mapas de bits a partir los mapas de bits de índices sobre las tres columnas. En este caso, estas operaciones se realizarían para cada índice: Para el índice en col 1, se realizaría la disyunción de los valores de clave 1 y 2. Para el índice en col 2, todos los mapas de bits para los valores de la clave > 5 se mezclarían en una operación que corresponde a una disyunción. Para el índice en col 3, se obtendrían los mapas de bits para los valores 10 y null. Entonces, se aplicaría una conjunción sobre los resultados de los dos primeros índices, seguido por dos operaciones menos booleanas de los mapas de bits para los valores 10 y null para col 3. Todas las operaciones se realizan directamente sobre la representación comprimida de los mapas de bits (no es necesaria la descompresión) y el mapa de bits resultante (comprimido) representa las filas que cumplen todas las condiciones lógicas. La capacidad de utilizar las operaciones booleanas para combinar varios índices no está limitada a los índices de mapas de bits. Oracle puede convertir identificadores de filas a la representación de mapa de bits comprimidos, por lo que se puede utilizar un índice de árbol B normal en cualquier lugar de un árbol binario u operación de mapa de bits simplemente poniendo un operador id-fila-a-mapa-de-bits en la parte superior del acceso a índices del plan de ejecución. Como regla nemotécnica, los índices de mapas de bits tienden a ser más eficientes en el espacio que los índices de árbol B si el número de valores distintos de la clave es menor que la mitad del número de filas en una tabla. Por ejemplo, en una tabla con un millón de filas, un índice en una columna con menos de valores distintos probablemente sería menor si se creara como un índice de mapa de bits. Para las columnas con un número muy pequeño de valores distintos (por ejemplo, las columnas que se refieren a propiedades tales como país, estado, género, estado marital y varios

20 CAPÍTULO 25 ORACLE estados indicadores) un índice mapa de bits podría requerir solamente una pequeña fracción del espacio normal de un índice de árbol B normal. Cualquier ventaja en el espacio también puede dar lugar a mejoras en el rendimiento en la forma de menos operaciones E/S a disco cuando se explora el índice Índices basados en funciones Además de crear índices sobre una o varias columnas de una tabla. Oracle permite crear índices sobre expresiones que involucran una o más columnas, tales como col 1 + col 2 * 5. Por ejemplo, la creación de un índice sobre la expresión upper(nombre), donde upper es una función que devuelve la versión en mayúsculas de una cadena y nombre es una columna, es posible realizar búsquedas independientes de la caja (mayúsculas o minúsculas) sobre la columna nombre. Con el fin de buscar todas las filas con el nombre «van Gogh» de una forma eficiente se puede utilizar la condición upper(nombre)= V AN GOGH en la cláusula where de la consulta. Oracle entonces casa la condición con la definición de índice y concluye que se puede utilizar el índice para recuperar todas las filas que coincidan con «van Gogh» sin considerar las mayúsculas y minúsculas del nombre cuando se almacenó en la base de datos. Se puede crear un índice basado en función como un mapa de bits o como un índice de árbol B Índices de reunión Un índice de reunión es un índice donde las columnas clave no están en la tabla que se referencia mediante los identificadores de filas en el índice. Oracle soporta los índices de reunión mapa de bits principalmente para su uso con esquemas en estrella (véase el Apartado ). Por ejemplo, si hay una columna para los nombres de los productos en una tabla de la dimensión productos se podría utilizar un índice de reunión de mapas de bits sobre la tabla de hechos con esta columna clave para recuperar las filas de la tabla de hechos que corresponden a un producto con un nombre específico, aunque el nombre no esté almacenado en la tabla de hechos. La forma en la que las filas en las tablas de hechos y de la dimensión correspondientes está basada en una condición de reunión se especifica cuando se crea el índice y se convierte en parte de los los metadatos de índices. Cuando se procesa una consulta el optimizador buscará la misma condición de reunión en la cláusula where de la consulta con el fin de determinar si es aplicable el índice de reunión. Oracle permite índices de reunión de mapa de bits para tener más de una columna clave y estas columnas pueden estar en tablas diferentes. En todos los casos las condiciones de reunión entre la tabla de hechos donde 617 se construye el índice y las tablas dimensionales se deben referir a claves únicas en las tablas dimensionales; esto es, una fila indexada en la tabla de hechos debe corresponder a una única fila en cada una de las tablas de dimensión. Oracle puede combinar un índice de reunión de mapa de bits en una tabla de hechos con otros índices en la misma tabla (tanto si hay índices de reunión o no) mediante el uso de operadores para las operaciones booleanas del mapa de bits. Por ejemplo, consideremos un esquema con una tabla de hechos para las ventas y tablas dimensionales para los clientes, productos y fechas. Supongamos que una consulta solicita información sobre las ventas a los clientes en un cierto código postal que compraron productos de una cierta categoría de producto durante un cierto periodo de tiempo. Si existe un índice de reunión de mapa de bits sobre varias columnas donde las columnas clave son las columnas de la tabla de dimensión restringidas (código postal, categoría de producto y fecha), Oracle puede utilizar el índice de reunión para buscar las filas en la tabla de hechos que coinciden con las condiciones de restricción. Sin embargo, si existen índices individuales sobre una única columna para las columnas clave (o un subconjunto de ellas), Oracle puede recuperar los mapas de bits de las filas de la tabla de hechos que coinciden con cada condición individual y utiliza la operación and booleana para generar un mapa de bits de la tabla de hechos para aquellas filas que satisfacen todas las condiciones. Si la consulta contiene condiciones sobre algunas columnas de la tabla de hechos, los índices de aquellas columnas se podrían incluir en la misma ruta de acceso, incluso si fueran índices normales de árbol B o índices de dominio (los índices de dominio se describen posteriormente en el Apartado ) Índices de dominio Oracle permite que las tablas sean indexadas por estructuras de índices que no sean propias de Oracle. Esta característica de extensibilidad del servidor Oracle permite a los fabricantes de software desarrollar los llamados cartuchos con funcionalidad para dominios de aplicación específicos, tales como texto, datos espaciales e imágenes, con la funcionalidad de indexado más allá de la proporcionada por los tipos de índice Oracle estándar. Para implementar la lógica para crear, mantener y buscar en el índice, el diseñador de índices debe asegurar que se adhiere a un protocolo específico en su interacción con el servidor Oracle. Un índice de dominio se debe registrar en el diccionario de datos junto con los operadores que soporta. El optimizador de Oracle considera los índices de dominio como una de las posibles rutas de acceso para una tabla. Oracle permite a las funciones de coste registrarse con los operadores de forma que el optimizador pueda comparar el coste del uso del índice de dominio con los de otras rutas de acceso.