BBDD Tema 3 UJA

Dado el siguiente código SQL, ¿qué devolverá la sentencia select de la línea 8 (transacción T2). 10. 20. se generará una excepción en T1. se generará una excepción en T2.

Dadas dos transacciones T1 y T2 que se ejecutan concurrentemente como a continuación se indica, podemos afirmar. Con un nivel de aislamiento READ UNCOMMITED se generaría una lectura sucia. Con un nivel de aislamiento READ UNCOMMITED se generaría una lectura fantasma. Con un nivel de aislamiento READ COMMITED se generaría una lectura sucia. Con un nivel de aislamiento READ COMMITED se generaría una lectura fantasma.

En Oracle, una transacción serializable: Puede generar una excepción si intenta modificar un dato que ha sido modificado en otra transacción T2, tras comenzar T1. Puede realizar lecturas de datos no actualizadas. Es el mínimo nivel de aislamiento necesario para garantizar que no habrá lecturas sucias. Es el mínimo nivel de aislamiento necesario para garantizar que no habrá lecturas fantasma.

Dadas dos transacciones T1 y T2 y una planificación P, se puede garantizar que: Si P es serializable, se garantiza que no hay estados conflictivos. Si P es serie, se garantiza que no hay estados conflictivos. Si P2 es una planificación alternativa a P, y P2 es serie, se garantiza que ambas dejarán la base de datos en el mismo estado. Si P es serie entonces es estricta.

Un planificador que implemente el protocolo de bloqueo B2F estricto. Garantiza que cualquier planificación será serializable. Garantiza que cualquier planificación será recuperable. Garantiza que no habrá interbloqueos. Garantiza que ninguna transacción quedará en espera indefinida.

Un planificador que garantice concurrencia, la serializabilidad, esté libre de borrados en cascada, no esté libre de interbloqueos y no conozca los datos que va a modificar cada transacción al inicio de ésta, podría implementar una estrategia: Serie. Estrategia B2F conservadora. Estrategia B2F estricta. Estrategia B2F rigurosa.

Sobre el nivel de aislamiento SERIALIZABLE de Oracle podemos afirmar: Está libre de actualizaciones perdidas. Está libre de borrados en cascada. Está libre de interbloqueos. Sigue una estrategia de bloqueos B2F.

Sobre el nivel de aislamiento READ COMMITED de Oracle podemos afirmar: Está libre de actualizaciones perdidas. Está libre de borrados en cascada. Está libre de interbloqueos. Está libre de lecturas sucias.

El algoritmo de recuperación de caídas de un DBMS debe contar necesariamente con la operación DESHACER si. El algoritmo de gestión del buffer de memoria es de tipo “no robar página”. El algoritmo de gestión del buffer de memoria es de tipo “no forzar escritura”. Se permiten transacciones concurrentes. Se permiten transacciones de larga duración.

El algoritmo de recuperación de caídas de un DBMS debe contar necesariamente con la operación REHACER si. El algoritmo de gestión del buffer de memoria es de tipo “no robar página”. El algoritmo de gestión del buffer de memoria es de tipo “no forzar escritura”. Se permiten transacciones concurrentes. Se permiten transacciones de larga duración.

En un DBMS donde se sigue un criterio de actualización inmediata de páginas sucias, la primera regla de la escritura anticipada de trazas, WAL#1: Es necesaria para garantizar la atomicidad. Es necesaria si el algoritmo de gestión del buffer de memoria es de tipo “robar página”. Permite la implementación de la operación DESHACER. No evita que transacciones cometidas puedan perderse.

En un DBMS donde se sigue un criterio de actualización inmediata de páginas sucias, la primera regla de la escritura anticipada de trazas, WAL#2: Es necesaria para garantizar la atomicidad. Es necesaria si el algoritmo de gestión del buffer de memoria es de tipo “robar página”. Permite la implementación de la operación DESHACER. No evita que transacciones cometidas puedan perderse.

Respecto ARIES se puede afirmar: En los puntos de verificación se graban en el archivo de datos las páginas sucias. Es un algoritmo de recuperación de caídas adecuado para una estrategia del buffer de datos de tipo forzar. Es un algoritmo de recuperación de caídas adecuado para una estrategia del buffer de datos de tipo robar. En la fase de deshacer se retrocede hasta alcanzar el primer evento que hizo que alguna página cambiara a sucia.

La fase de “rehacer” en ARIES, en su formulación original: Rehace única y exclusivamente aquellos eventos que aún no han sido almacenados en el archivo de datos. Rehace tanto aquellos eventos de transacciones que han sido confirmados como los que no. Utiliza el campo lastLSN almacenado en cada traza para rehacer con mayor eficiencia. Es precedida por la fase “deshacer”.

La fase de “deshacer” en ARIES, en su formulación original: Deshace única y exclusivamente aquellos eventos que aún no han sido almacenados en el archivo de datos. Deshace tanto aquellos eventos de transacciones que han sido confirmados como los que no. Utiliza el campo lastLSN almacenado en cada traza para deshacer con mayor eficiencia. Es precedida por la fase “análisis”.

En ARIES se puede afirmar que la base de datos se encuentra exactamente en el estado que se encontraba en el instante de la caída: Al final de la fase de análisis. Al final de la fase “rehacer”. Al final de la de “deshacer”. Nunca.