| Transaktionen, Serialisierbarkeit |
     |
Hallo.
Ich habe hier ein paar Aufgaben zu Transaktionen, für die ich das wesentliche mal angehangen habe. Ich habe leider keine Lösungen dazu und bei manchen Sachen bin ich mir auch nicht sicher, wie es gelöst werden kann. Die Serialisierbarkeits-Aufgaben dienen eher der Überprüfung.
| Zitat: |
A1: Auf Serialisierbarkeit testen.
Da ich ja nur 5 Bilder anhängen darf und auch keine Lust auf Paint habe:
T2 ist von T1 abhängig, T4 ist von T2 abhängig, T1 ist von T4 abhängig -> Zyklus
T3 ist von T4 abhängig, genauso T2 von T3 -> 2. Zyklus
T3 ist von T1 abhängig
Der Graph ist nicht zyklenfrei, somit nicht serialisierbar. |
| Zitat: |
A2: Puffermethode ist Steal/no-Force. Nach dem letzten Log-Eintrag ist der Strom ausgefallen. Es soll für jede Transaktion die nötige Aktion angegeben werden, um eine konsistente Datenbank zu erhalten.
Zusätzlich zum Log ist angegeben, dass die Veränderungen von P_A und P_C in der Datenbank gespeichert sind.
Hier war ich erstmal ratlos, also alles Schritt für Schritt, das Vorlesungsskript ist da auch absolut nicht ergiebig.
Definitionen:
1. Steal: Eine Seite, die von einer unfertigen Transaktion geändert wurde, darf ausgelagert werden
2. No-Force: Eine Seite, die von einer fertigen Transaktion geändert wurde, muss nicht gesichert werden.
Fertige Transaktionen: T1, T2, T4
Unfertige Transaktionen: T3, T5, T6
Da P_C gesichert wurde und T1 P_C betrifft, ist keine Aktion nötig
Analog gilt dies auch für T4
P_B wurde nicht gesichert, also ist für T2 ein Redo nötig.
P_A wurde gesichert, T3 benötigt keine Aktion.
T6 hat bisher keine Einschränkungen -> Undo
T5 betrifft P_C. Hier ist jetzt die Frage, ob diese Veränderung auch schon gesichert wurde. Je nachdem ist also keine Aktion bzw. ein Undo nötig. Ich habe mich fürs Undo entschieden, da die Transaktion nur in den Cache/Puffer/Speicher was auch immer ausgelagert wurde und weil die Lösung zu Aufgabe 5 passt. |
| Zitat: |
A3: Wieder Serialisierbarkeit und zusätzlich alle äquivalenten, seriellen Schedules angeben:
Der Schedule ist serialisierbar, da er keine Zyklen enthält:
T3 ist von T1 abhängig, T4 ist von allen 3 anderen abhängig.
Für die seriellen Schedules ergibt das, dass T4 immer die letzte Transaktion sein muss, und dass T3 niemals vor T1 ausgeführt werden darf.
Somit:
T2, T1, T3, T4
T1, T3, T2, T4
T1, T2, T3, T4 |
| Zitat: |
A4: Analog zu A3
T2 ist von T1 abgängig, T4 von T2 und T1.
Daraus folgt die fixe Reihenfolge T1, T2, T4, wodurch es nur für T3 4 Möglichkeiten gibt, wann die Transaktion ausgeführt werden soll. |
| Zitat: |
A5: Analog zu A2, hier aber mit dem Zusatz, dass nur P_A(#7) gespeichert wurde.
Fertige Transaktionen: T1, T2
Unfertige Transaktion: T3
P_A wurde in #7 gesichert, dies betrifft T1, also keine Aktion
T2, bzw. P_B wurde nicht gesichert, also Redo
T3 betrifft zwar wieder P_A, aber durch den Zusatz mit #7 würde ich hier folgern, dass diese Veränderung nicht gesichert wurde und entsprechend ein Undo nötig ist. Das ist allerdings nur ne Folgerung aus der Formulierung.
In A2 gab es keine direkten Bezug zu einem Log-Eintrag, entsprechend habe ich dort die Sicherung auf #13 bezogen, wodurch #14 dann rückgängig gemacht werden muss. So ganz eindeutig ist mir das nicht. Was meint ihr dazu? |
Vielen Dank im voraus.
Morgyr hat diese Bilder (verkleinerte Versionen) angehängt:
  
 
Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von Morgyr: 22.03.2015 09:12.
|
