Folie 104 ("Vermeidung von Deadlocks: Zeitstempel"): Alt: Jeder Transaktion T_i wird zu Beginn ein Zeitstempel TS(T_i) zugeordnet (Time Stamp): - Ende der vorherigen TA - oder (besser) erste Datenbank-Operation einer TA Neu: Jeder Transaktion T_i wird zu Beginn ein Zeitstempel TS(T_i) zugeordnet (Time Stamp): - ***Begin (BoT) einer TA*** - oder (besser) erste Datenbank-Operation einer TA Grund: Wenn wir als Zeitstempel das Ende der vorherigen TA verwenden, dann kann folgendes passieren: Wenn zwei TA's gestartet werden, ohne das zwischendurch eine TA beendet wird, dann haben die beiden neuen TA's den selben Zeitstempel. Die beiden TA's könnten dann (zumindest anhand ihrer Zeitstempel) nichtmehr unterschieden werden. ----------------------------------------------------------------------- Folie 108 ("Vermeidung von Deadlocks: Zeitstempel...-Wound-Wait ist serialisierbar"): Alt: "Der äquivalente serielle Schedule ist aber nicht beliebig...." "Serialisierungsreihenfolge definiert durch BoT" ... "Äquivalenter serieller Schedule gleich" Neu: Nix Grund: Alle diese Aussagen gehören in das "Zeitstempel statt Sperren" Synchronisationsverfahren (nächster Abschnitt) anstatt hier beim Deadlockvermeidungsverfahren mit Zeitstempel.) ---------------------------------------------------------------------- Folie 114 (Zeitstempel statt Sperren(cont.).... -Prüfungen beim Schreibzugriff): Alt: Unter dem Pseudocode stand "Garantiert seriellen Schedule" Neu: Nix Grund: Gemeint war "Garantiert serialisierbaren Schedule" und das steht schon auf einer der nächsten Folien. ----------------------------------------------------------------------------- Folie 160 (No-Force) Statt "Änderung werden erst nach dem Commit in die DB geschrieben" muss es heissen: "Änderung werden *AUCH* erst nach dem Commit in die DB geschrieben". Bei Force müssen die Änderungen also vor Commit ausgeschrieben sein, bei No-Force gilt diese Einschränkung nicht. Entsprechungen müssen bei No Steal die Änderungen nach dem Commit ausgeschrieben werden, bei Steal nicht. Bei No-Force/Steal darf eine Seite also zu jederzeit ausgeschrieben werden. --------------------------------------------------- Folie 88 (RAC): C-Sperre wird erst freigegeben wenn letzter alter Leser fertig ist ---------------------------------------------------------- ---------------------------------------------------------------------- Folie 253 (Sort-Merge-Join) Die letzten drei Zeilen des Algorithmus wurden entfernt, dafür dieser Kommentar: Achtung: Dieser Algorithmus funktioniert nur, falls R und S auf dem Joinattribut keine Duplikate enthalten. Wie muss der Algorithmus erweitert werden um Duplikate zu erfassen? Das Problem der Duplikate ist nicht schwer zu lösen, aber für das Verständnis des Sort-Merge-Joins unerheblich. Trotzdem hier eine Lösungsidee für die, die es ganz genau wissen wollen: Bei Duplikaten hat man für einen Attributswerts möglicherweise einen ganzen Block von Tupelpaaren die in das Ergebnis aufgenommen werden müssen. So wie der Algorithmus (wie er im Skript steht)funktioniert, findet man immer zuerst das obere linke Tupel eines solchen Blocks. Darum: Immer wenn man ein Joinpaar findet, schaut man, wieviele Tupel von S den gleichen Wert haben (also wie weit der Block noch rechts geht) und wieviele Tupel von R diesen Wert haben (also wie weit der Block nach unten geht). Dann wird der ganze Block gejoined (z.B. mit einem Nested-Loop-Join). Dann setzt man i und j auf die indices des letzten (d.h. unteren rechten) Tupels des Blocks. Fertig. Im nächsten Schleifendurchlauf wird i automatisch um eins erhöht, und der Algorithmus macht an dem Tupelpaar rechts vom unteren-rechten Ecks des Blocks weiter. [Um ganz genau zu sein müsste es in der dritten Zeile noch heissen "for(int i=0;i