Recuperatorio Segundo Parcial 2C 2007 (Bases de Datos)

De Cuba-Wiki
Saltar a: navegación, buscar
Back.png Volver a la página de la materia

Enunciado[editar]

Ver el enunciado

Recuperación[editar]

Parte A[editar]

Escenario 1[editar]

Estado del log:

<START T1>
<T1, A, 10, 20>
<T1, B, 0, 40>
<START T2>
<T1, A, 20, 50>
<T2, C, 20, 30>
<COMMIT T1>
<START T3>
<T3, D, 30, 60>
<T2, E, 25, 50>
<START CKPT (T2, T3)>
<T2, C, 30, 45>

No hay END CHKPT, entonces se recorre todo el log. Se deben deshacer T2 y T3 y rehacer T1, que es la unica que tiene un commit. Los valores luego de la pasada de undo y de redo son entonces:

  UNDO   REDO  FINAL
A        20 50  50
B        40     40
C 30 20         20
D 30            30
E 25            25
F               10

Escenario 2[editar]

Estado del log:

<START T1>
<T1, A, 10, 20>
<T1, B, 0, 40>
<START T2>
<T1, A, 20, 50>
<T2, C, 20, 30>
<COMMIT T1>
<START T3>
<T3, D, 30, 60>
<T2, E, 25, 50>
<START CKPT (T2, T3)>
<T2, C, 30, 45>
<COMMIT T2>

Igual que en el anterior, al no haber END CKPT no se considera el checkpoint. En este caso hay que deshacer solamente T3 y rehacer T1 y T2. Los valores resultantes, luego de hacer la pasada de undo y luego la de redo, son los siguientes:

  UNDO REDO  FINAL
A      20 50  50  
B      40     40
C      30 45  45
D 30          30
E      50     50
F             10

Escenario 3[editar]

Estado del log:

<START T1>
<T1, A, 10, 20>
<T1, B, 0, 40>
<START T2>
<T1, A, 20, 50>
<T2, C, 20, 30>
<COMMIT T1>
<START T3>
<T3, D, 30, 60>
<T2, E, 25, 50>

<START CKPT (T2, T3)>
<T2, C, 30, 45>
<COMMIT T2>
<START T4>
<T4, F, 10, 80>
<COMMIT T3>
<END CKPT>
<T4, F, 80, 100>

En este caso sí hay END CKPT, entonces sabemos que todas las modificaciones iniciadas previas al START CKPT ya estan en disco y no es necesario rehacerlas. Basta con deshacer T4 y rehacer algunos updates de T2 y T3.

  DISK  UNDO  REDO FINAL
A 20 50            50 
B 40               40
C 30          45   45
D 30 60            60
E 50               50
F       80 10      10


Final[editar]

   A  B  C  D  E  F
1  50 40 20 30 25 10
2  50 40 45 30 50 10
3  50 40 45 60 50 10


Parte B[editar]

Item 1[editar]

Estado del log:

<START T1>
<T1, A, 5>
<START T2>
<T1, B, 1>
<COMMIT T1>
<T2, B, 11>
<T2, C, 8>
<COMMIT T2>
<START T3>
<T3, A, 10>
<START T4>
<T4, A, 11>
<T3, C, 7>
<T4, B, 22>

En undo logging los registros de update se escriben a disco antes de que se modifique el item (al igual que en todas las demas estrategias) y el commit se escribe luego de que todas las modificaciones ya bajaron a disco. Por lo tanto, no se sabe si todas las modificaciones de T3 y T4 están o no en disco, con lo que los valores posibles son:

  • A = 10, 11, 12
  • B = 22, 23
  • C = 7, 8

Consultar: Las operaciones de update sobre un mismo item tienen que bajarse en orden a disco? Y las operaciones de una misma transaccion sobre distintos items?

Item 2[editar]

Item 3[editar]

Estado del log:

<START T1>
<T1, A, 5, 0>
<START T2>
<T1, B, 1, 2>
<COMMIT T1>
<T2, B, 2, 3>
<START CKPT(T2)>
<T2, C, 8, 9>
<COMMIT T2>
<END CKPT>
<START T3>
<T3, A, 0, 10>
<START T4>
<T4, A, 10, 11>
<T3, C, 9, 7>
<T4, B, 3, 22>

Como encontramos el end checkpoint sabemos que TODO antes del start está en disco (commiteadas y no commiteadas), con esos valores base calculamos la combinatoria del resto de los cambios.

  • A = 0, 10, 11
  • B = 3, 22
  • C = 8, 9, 7