Transactions Management. (Διαχείριση Δοσοληψιών)

Transactions Management (Διαχείριση Δοσοληψιών)

Επισκόπηση διαλέξεων Αντιμετώπιση αστοχιών συστήματος (failure recovery) Χρήση ιστορικού/πρακτικού - Logging (Undo, Redo, Undo/Redo) Χρονοπρογράμματα Δοσοληψιών (Transaction Scheduling) και Σειριοποιησιμότητα (Serializability) Έλεγχος Συγχρονικότητας (Concurrency Control) και Τεχνικές Κλειδώματος (Lock-based Protocols) 2

Το πρόβλημα Έλεγχος προσπέλασης δεδομένων ενός ΣΔΒΔ (DBMS) κύρια ζητήματα: Προφύλαξη από ενδεχόμενες αποτυχίες/αστοχίες/λάθη του συστήματος Διατήρηση αναλλοίωτων δεδομένων κατά την ταυτόχρονη εκτέλεση ερωτημάτων ή τροποποιήσεων της ΒΔ και τον διαμοιρασμό των δεδομένων 3

Το πρόβλημα: Είδη αποτυχιών/σφαλμάτων Σφάλματα στην καταχώρηση δεδομένων περιορισμοί (constraints) και πυροδότες (triggers) Αστοχίες του μόνιμου αποθηκευτικού μέσου δίσκος μη-αναγνώσιμος: χρήση RAID, αντίγραφα ασφαλείας (backup full/incremental, replication) etc Καταστροφικές αστοχίες εξωτερικού περιβάλλοντος π.χ. φωτιά, έκρηξη κλπ Αστοχίες συστήματος προγραμματιστικά (κακό πρόγραμμα με λάθη) αστοχία δοσοληψίας (απώλεια κατάστασης μιας δοσοληψίας, ακύρωση από τον χρήστη, αδιέξοδο κλπ) του ίδιου του συστήματος (π.χ. αδιέξοδα λειτουργικού, διακοπή ρεύματος, CPU halts/resets, system crash) 4

Το πρόβλημα: Είδη αποτυχιών/σφαλμάτων Events Desired Undesired Expected Unexpected Ιεραρχία αποθήκευσης Προσωρινή Μνήμη (RAM, cache, καταχωρητές) a b Read(A,a) A Μόνιμο Αποθηκευτικό Μέσο (Disk) buffer Write(B,b) B buffer Οι διακεκομμένες αναπαριστούν λειτουργίες που μπορεί να καθυστερήσουν, να αγνοηθούν ή να μην γίνουν ποτέ 5

Το πρόβλημα: Διαπλοκή Δοσοληψιών Η ταυτόχρονη εκτέλεση προγραμμάτων χρηστών είναι απαραίτητη για την καλή απόδοση ενός ΣΔΒΔ Επειδή οι προσπελάσεις στο δίσκο είναι συχνές και σχετικά αργές, είναι σημαντικό να κρατείται η CPU απασχολημένη με πολλά προγράμματα χρηστών Πολυχρηστικά (multi-user) ΣΔΒΔ Η «διαπλοκή» γίνεται από το ΣΔΒΔ και πρέπει να είναι «αδιαφανής» στο χρήστη. Ο χρήστης πρέπει να πιστεύει ότι είναι ο μόνος που χρησιμοποιεί το σύστημα. Τα πράγματα γίνονται πιο δύσκολα όταν υπάρχουν αποτυχίες Α Β Α Β Διαπλεγμένο μοντέλο ταυτόχρονης εκτέλεσης (χρονοπρόγραμμα) 6

Δοσοληψίες (Transactions)

Συνέπεια ΒΔ (DB Consistency) Θέλουμε τα δεδομένα μας να είναι πάντα «ακριβή» (accurate) και «σωστά» (correct). Μια ΒΔ διέπεται από κανόνες ακεραιότητας (integrity constraints) πρωτεύοντος κλειδιού, περιορισμούς τιμών, Επιπλέον, υπάρχουν και λογικοί περιορισμοί, τους οποίους «κρύβουμε» στις εφαρμογές. Πριν και μετά την εκτέλεση της δοσοληψίας (αλλά όχι απαραίτητα ενδιαμέσως), όλοι οι περιορισμοί αυτοί πρέπει να πληρούνται. 8

Προβληματισμός Παραδοχή (αρχή της ορθότητας): Μια δοσοληψία πρέπει να αφήνει τη ΒΔ σε μια συνεπή κατάσταση αν η ΒΔ ήταν σε συνεπή κατάσταση όταν άρχισε η δοσοληψία. Δύο είναι τα βασικά προβλήματα με τις δοσοληψίες: Τι θα γίνει αν κατά τη διάρκεια της εκτέλεσης, υπάρχει κάποια αποτυχία ή πέσει το σύστημα; Τι θα γίνει αν δύο δοσοληψίες επιχειρούν να μεταβάλλουν το ίδιο αντικείμενο ταυτόχρονα; 9

Η έννοια της δοσοληψίας Δοσοληψία (transaction) είναι μια σειρά από ενέργειες, οι οποίες προσπελαύνουν ή τροποποιούν (διαβάζουν ή γράφουν) το περιεχόμενο (αντικείμενα) της ΒΔ, και τελειώνει με μια πράξη επικύρωσης ή με μια πράξη ακύρωσης. Μια δοσοληψία μπορεί να επικυρωθεί (commit) αφού ολοκληρώσει όλες τις πράξεις της να ακυρωθεί (abort) αφού έχει εκτελέσει κάποιες από τις πράξεις της 10

Καταστάσεις μιας Δοσοληψίας R / W COMMIT Running (active) END FAILED - ABORT ABORT BEGIN π.χ. R(X) T1: BEGIN R(X), X=Χ-N, W(X), R(Y), Y=Y+N, W(Y) END W(X) T2: BEGIN R(X) X=X+M, W(X) END END COMMIT (επικύρωση) - επιτυχία - όλες οι τροποποιήσεις επικυρώνονται και δεν μπορούν να αναιρεθούν ABORT (ακύρωση ή ανάκληση) - αποτυχία όλες οι τροποποιήσεις πρέπει να αναιρεθούν 11

Επιθυμητές ιδιότητες μιας Δοσοληψίας Ατομικότητα (Atomicity): είτε όλες οι πράξεις της δοσοληψίας επιτυγχάνουν, είτε όλες αποτυγχάνουν. Συνέπεια (Consistency): στο τέλος της δοσοληψίας, η ΒΔ πρέπει να διατηρείται σε συνεπή μορφή. Απομόνωση (Isolation): ακόμα κι αν τρέχουν πολλές δοσοληψίες ταυτόχρονα, κάθε δοσοληψία πρέπει να νομίζει ότι τρέχει μόνη της και δεν αποκαλύπτονται τα ενδιάμεσα αποτελέσματα. Μονιμότητα ή Διάρκεια (Durability): μετά την επικύρωση μιας δοσοληψίας οι αλλαγές δεν είναι δυνατόν να χαθούν, ακόμα και σε περίπτωση αποτυχίας του συστήματος. Διεθνώς γνωστό ως ACID test 12

Πράξεις δοσοληψιών - Συμβολισμός Input(X): Αντιγραφή block που περιέχει X από το δίσκο μνήμη (buffer) Read(X,t): Κάνε Input(X) αν χρειάζεται, τιμή του X στο block t Write(X,t): Κάνε Input(X) αν χρειάζεται, t τιμή του X στο block Output(X): Αντιγραφή block που περιέχει X δίσκο Δες επόμενο παράδειγμα: ημιτελής δοσοληψίες δημιουργούν προβλήματα συνέπειας στην ΒΔ. 13

Παράδειγμα δοσοληψίας T1: Read (A,t); t t*2 Write (A,t); Read (B,t); t t*2 Write (B,t); Output (A); Output (B); A: B: 5 5 10 10 A: 5 B: 5 10 10 memory disk 14

Ημιτελής δοσοληψία T1: Read (A,t); t t*2 Write (A,t); Read (B,t); t t*2 Write (B,t); Output (A); Output (B); failure! Χρειαζόμαστε Ατομικότητα: να εκτελεστούν όλες οι ενέργειες της δοσοληψίας ή καμία A: 5 B: 5 10 10 A: 5 B: 5 10 Ασυνεπής κατάσταση στην ΒΔ memory disk 15

Τεχνικές Ανάκαμψης από σφάλματα (Failure Recovery)

Ιστορικό/Πρακτικό/Ημερολόγιο (Log) Στόχος της ανάκαμψης: επαναφορά στην πιο πρόσφατη συνεπή κατάσταση ακριβώς πριν τη στιγμή της αποτυχίας. Το ΣΔΒΔ καταγράφει (logs) όλες τις ενέργειες που πραγματοποιούνται από τις δοσοληψίες και κάθε άλλο σημαντικό συμβάν. Το πρακτικό (log) είναι ένα αρχείο καταγραφής που αποτελείται από έγγραφες/δελτία πρακτικών (log records) και επιτρέπεται μόνο προσθήκη (append). Το ίδιο το log δημιουργείται στην κύρια μνήμη και αντιγράφεται στο δίσκο με μια κατάλληλη πράξη flashlog, μόλις αυτό καταστεί εφικτό. 17

Έννοια της ανάκαμψης (recovery) Ιδιότητες Δοσοληψιών Ατομικότητα (Αtomicity) - είτε όλες οι πράξεις είτε καμία Οι δοσοληψίες μπορεί να αναιρεθούν ( rollback ). Μονιμότητα ή Διάρκεια (Durability ) - μετά την επικύρωση μιας δοσοληψίας οι αλλαγές δεν είναι δυνατόν να χαθούν Τι θα συμβεί αν το ΣΔΒΔ καταρρεύσει? Επανάληψη 18

Έννοια της ανάκαμψης (recovery) Επιθυμητή συμπεριφορά μετά από μια αποτυχία: T1, T2 & T3 πρέπει να έχουν Διάρκεια (redoεπανάληψη) T4 & T5 πρέπει να αναιρεθούν (undo-αναίρεση) T1 T2 T3 T4 T5 αποτυχία 19

Log records Μορφές και συμβολισμοί: <START T> : η δοσοληψία T έχει ξεκινήσει <COMMIT T> : η T έχει ολοκληρωθεί επιτυχώς. Οι αλλαγές που έκανε η T πρέπει να εμφανίζονται στο δίσκο <ABORT T> : η T δεν ολοκληρώθηκε επιτυχώς. Οι αλλαγές που έκανε η T δεν πρέπει να εμφανίζονται στο δίσκο Για την τεχνική ανάκαμψης με πρακτικά αναίρεσης (undo log) χρειαζόμαστε: εγγραφές ενημέρωσης (update records) <T, X, v> : η T τροποποίησε το στοιχείο X, του οποίου η παλιά τιμή ήταν v (η εγγραφή αυτή καταγράφεται σε απόκριση μιας ενέργειας Write, και όχι μιας ενέργειας Output) 20

T1: Read (A,t); t t*2 Write (A,t); Read (B,t); t t*2 Write (B,t); Output (A); Output (B); A: 5 B: 5 10 10 Undo Logging A:5 B:5 <START T1> <T1, A, 5> 10 <T1, B, 5> <COMMIT T1> 10 memory disk log Μια πιθανή «επιπλοκή»: - Το log δημιουργείται πρώτα στην κύρια μνήμη - Δεν γράφεται στον δίσκο σε κάθε ενέργεια 21

Κανόνες Undo Logging Οι δοσοληψίες πρέπει να υπακούν στους παρακάτω κανόνες για να είναι δυνατή η αποκατάσταση μετά από αστοχία: 1. Αν η T αλλάζει το στοιχείο X, τότε το log record <T, X, v> πρέπει να γραφεί στο log πριν η νέα τιμή του X γραφτεί στο δίσκο (Write Ahead Log - WAL) 2. Αν η T οριστικοποιηθεί (commits), τότε το <COMMIT T> γράφεται στο δίσκο μόνο μετά την εγγραφή στο δίσκο όλων των στοιχείων της ΒΔ που τροποποιήθηκαν από την Τ, αλλά όσο το δυνατόν συντομότερα. Αυτοί οι κανόνες επιβάλλουν την ακόλουθη σειρά εγγραφής στο δίσκο: a) Τα log records που δείχνουν τα μεταβληθέντα στοιχεία της ΒΔ b) Τα ίδια τα μεταβληθέντα στοιχεία της ΒΔ c) Το COMMIT log record Για να εξαναγκάσουμε τα log records στο δίσκο, ο log manager πρέπει να στείλει μια εντολή FLUSH LOG 22

Επαναφορά με Undo Logging Σε περίπτωση αστοχίας, ο διαχειριστής αποκατάστασης (Recovery Manager) πρέπει να επαναφέρει την ΒΔ σε συνεπή κατάσταση χρησιμοποιώντας το log. Θεωρούμε έναν απλό recovery manager ο οποίος: εξετάζει ολόκληρο το log και βασιζόμενος σε αυτή την εξέταση κάνει τις απαραίτητες αλλαγές στην ΒΔ Ο recovery manager πρέπει να χωρίσει τις δοσοληψίες σε οριστικοποιημένες και μη-οριστικοποιημένες Αν βρεθεί ένα <COMMIT T>, τότε, βάσει του κανόνα 2, όλες οι αλλαγές που έγιναν από την T έχουν ήδη εγγραφεί στο δίσκο. Συνεπώς η T άφησε την ΒΔ σε συνεπή κατάσταση Αν όμως βρεθεί <START T> αλλά όχι <COMMIT T>, η T θεωρείτε ανολοκλήρωτη (incomplete) και πρέπει να αναιρεθεί (be undone) 23

Επαναφορά με Undo Logging Αναίρεση σημαίνει ότι τα στοιχεία πρέπει να επανέλθουν στην προηγούμενή τους τιμή. Ο κανόνας 1 διασφαλίζει ότι αν το X είχε αλλάξει πριν την αποτυχία, τότε θα υπάρχει ένα <T, X, v> στο log, και αυτό θα έχει γραφτεί στο δίσκο πριν την αποτυχία. Για την επαναφορά, η τιμή v πρέπει να γραφτεί στο X Πολλές μη-οριστικοποιημένες δοσοληψίες μπορεί να έχουν τροποποιήσει το Χ. Για αυτό πρέπει να επαναφέρουμε τις τιμές με συστηματικό τρόπο (πρέπει να σεβαστούμε την σειρά/διάταξη) Το log πρέπει να σαρωθεί ανάποδα: από το νεότερο στο παλαιότερο Πρέπει να κρατηθεί μια λίστα από δοσοληψίες για τις οποίες έχει βρεθεί <COMMIT Τ> ή <ABORT Τ>. 24

Επαναφορά με Undo Logging Αν βρεθεί <T, X, v> : Αν έχει βρεθεί <COMMIT T> τότε δεν κάνουμε τίποτα. Οι αλλαγές δεν χρειάζεται να αναιρεθούν. Αν η T είναι ανολοκλήρωτη, η τιμή του X πρέπει να αλλάξει σε v Αφού πραγματοποιηθούν οι απαραίτητες αλλαγές, ένα <ABORT T> πρέπει να γραφεί για κάθε ανολοκλήρωτη δοσοληψία και το log να γίνει flushed Η προσέγγιση αυτή είναι απλή αλλά όχι αποδοτική: ολόκληρο το ιστορικό πρέπει να εξεταστεί κάθε φορά που έχουμε κάποια αποτυχία μια βελτιωμένη προσέγγιση βασίζεται σε σημεία ελέγχου (checkpoints) στο log ώστε να περιοριστεί η έκταση του log που πρέπει να εξεταστεί (θα το δούμε στην συνέχεια) 25

Undo Logging: Recovery rules For every Ti with <START Ti> in log: If <COMMIT Ti> or <ABORT Ti> do nothing in log Else For all <Ti, X, v> in log: Write (X, v) Output (X ) Write <ABORT Ti> to log Είναι σωστό αυτό? 26

Undo Logging: Recovery rules 1) Let S = set of transactions with <START Ti> in the log, but no <COMMIT Ti> or <ABORT Ti> record in the log 2) For each <Ti, X, v> in the log, in reverse order (latest earliest) do: if Ti S then Write (X, v) Output (X) 3) For each Ti S do: Write <ABORT Ti> to log 27

Παράδειγμα 28

Επιπλοκές με Undo Logging Τα logging actions δεν συμβαίνουν σε απομόνωση. Αφού πολλές δοσοληψίες μπορεί να εκτελούνται ταυτόχρονα, μπορεί να υπάρξει διαπλοκή των log records με παρόμοιες ενέργειες από άλλες δοσοληψίες Με το flushing του log ίσως ενδεχομένως να εμφανιστούν στο δίσκο log records πολύ πριν από ότι πρέπει. Δεν υπάρχει πρόβλημα εφόσον το <COMMIT T> γραφτεί μόνο μετά από την ολοκλήρωση των Output ενεργειών της T Αν τα στοιχεία A και B μοιράζονται ένα block, γράφοντας το ένα συνεπάγεται και η εγγραφή του άλλου (το οποίο παραβιάζει τον κανόνα 1) Πρέπει να επιβάλουμε επιπλέον περιορισμούς ή έναν Έλεγχο Συνδρομικότητας (concurrency protocol) περισσότερα για τον Έλεγχο Συνδρομικότητας θα δούμε αργότερα 29

Σημεία ελέγχου (Checkpoints) Από την στιγμή που γίνεται ένα <COMMIT > σε ένα Undo Recovery θα μπορούσε κανείς να υποθέσει ότι τα πρακτικά της δοσοληψίας μέχρι το <COMMIT > δεν είναι πλέον απαραίτητα για την αποκατάσταση όμως κάποιες φορές αυτό δεν είναι δυνατό γιατί συχνά εκτελούνται πολλές δοσοληψίες ταυτόχρονα και μπορεί να χαθούν και πρακτικά από δοσοληψίες που δεν έχουν ολοκληρωθεί ακόμα Για να το αποφύγουμε αυτό, δημιουργούμε περιοδικά σημεία ελέγχου (check points) ως εξής: 1. Σταματάμε να αποδεχόμαστε νέες δοσοληψίες 2. Περιμένουμε μέχρι οι ενεργές δοσοληψίες να ολοκληρωθούν ή να ματαιωθούν και να γραφτεί το <COMMIT > ή <ABORT > στο log 3. Κάνουμε flush το log στο δίσκο 4. Γράφουμε ένα log record <CKPT> και ξανακάνουμε flush το log 5. Ξαναρχίζουμε να δεχόμαστε δοσοληψίες 30

Σημεία ελέγχου (Checkpoints) Δεν χρειάζεται να αναιρέσουμε τις αλλαγές των δοσοληψιών πριν το σημείο ελέγχου γιατί σύμφωνα με τον κανόνα 2, οι μεταβολές θα έχουν φτάσει στο δίσκο Κατά την αποκατάσταση, σαρώνουμε το log προς τα πίσω για να βρούμε ανολοκλήρωτες δοσοληψίες όταν βρεθεί ένα <CKPT> τότε όλες οι ανολοκλήρωτες δοσοληψίες βρέθηκαν Δεν χρειάζεται να σαρώσουμε πριν το <CKPT> αφού καμία δοσοληψία δεν μπορεί να ξεκινήσει μέχρι να ολοκληρωθεί το checkpoint Το log πριν το <CKPT> μπορεί με ασφάλεια να διαγραφεί ή να υπερεγγραφεί (overwrite) 31

Παράδειγμα: Σημεία ελέγχου (Checkpoints) <START T 1 > <T 1, A, 5> <START T 2 > < T 2, B, 10> Αν βάλουμε ένα checkpoint εδώ, πρέπει να περιμένουμε να ολοκληρωθούν οι T 1 και T 2 πριν γράψουμε το <CKPT> στο log file <COMMIT T 1 > <COMMIT T 2 > <CKPT> <START T 3 > 32

Μη-αδρανή σημεία ελέγχου (Non-quiecent) Για να μην διακοπεί η λειτουργία του συστήματος, συνήθως προτιμάται αυτή η τεχνική που επιτρέπει την εισαγωγή νέων δοσοληψιών κατά την διάρκεια δημιουργίας ενός checkpoint Βήματα: 1. Γράφουμε στο log record <START CKPT(T 1,T 2, T k )> για όλες τις ενεργές μη οριστικοποιημένες δοσοληψίες T 1, T 2,, T k και κάνουμε flush log. 2. Περιμένουμε μέχρι να οριστικοποιηθούν ή να ματαιωθούν όλες οι T 1, T 2,, T k αλλά δεν απαγορεύουμε την εκκίνηση άλλων δοσοληψιών. 3. Όταν ολοκληρωθούν οι T 1, T 2,, T k γράφουμε στο log record <END CKPT> και κάνουμε flush log. 33

Αποκατάσταση με Μη-αδρανή σημεία ελέγχου Όταν χρειαστεί recovery, σαρώνουμε το log file backwards: 1. Αν συναντήσουμε πρώτα ένα <END CKPT>, τότε όλες οι ανολοκλήρωτες δοσοληψίες ξεκίνησαν μετά το προηγούμενο <START CKPT (T 1,, T k )>. Άρα σάρωσε προς τα πίσω μέχρι το <START CKPT>. Ότι παλαιότερο υπάρχει μπορεί να διαγραφεί. 2. Αν συναντήσουμε πρώτα ένα <START CKPT (T 1,, T k )>, τότε το crash έγινε κατά την διάρκεια του checkpoint. Οι μόνες οι ανολοκλήρωτες δοσοληψίες είναι αυτές που βρήκαμε όσο σαρώναμε προς τα πίσω μέχρι <START CKPT (T 1,, T k )> και όσες από τις T 1, T 2,.. T k δεν ολοκληρώθηκαν πριν το crash. Δεν χρειάζεται να σαρώσουμε προς τα πίσω πέρα από την έναρξης της παλαιότερης από αυτές τις δοσοληψίες 34

Αποκατάσταση με Μη-αδρανή σημεία ελέγχου Παράδειγμα 1: <START T 1 > <T 1, A, 5> <START T 2 > <T 2, B, 10> Βάζουμε ένα non-quiescent checkpoint εδώ <START CKPT(T 1,T 2 )>. Η T 3 αρχίζει ενώ περιμένουμε να ολοκληρωθούν οι T 1 και T 2 <START CKPT(T 1,T 2 )> <T 2, C, 15> <START T 3 > <T 1, D, 20> <COMMIT T 1 > <T 3, E, 25> <COMMIT T 2 > <END CKPT> <T 3, F, 30> failure 35

Αποκατάσταση με Μη-αδρανή σημεία ελέγχου Παράδειγμα 1 (συνέχεια): Η T 3 είναι ανολοκλήρωτη και πρέπει να αναιρεθεί και πρέπει να γίνει επαναφορά της τιμής του F σε 30 Όταν συναντήσουμε το <END CKPT> ξέρουμε ότι όλες οι ανολοκλήρωτες δοσοληψίες άρχισαν με το προηγούμενο <START CKPT> Συνεχίζοντας την σάρωση προς τα πίσω βρίσκουμε ότι η τιμή του Ε πρέπει να αποκατασταθεί σε 25 Δεν υπάρχουν άλλες δοσοληψίες που ξεκίνησαν χωρίς να οριστικοποιηθούν. Δεν χρειάζεται να ψάξουμε άλλο πριν το <START CKPT> 36

Αποκατάσταση με Μη-αδρανή σημεία ελέγχου Παράδειγμα 2: Κατάρρευση του συστήματος κατά την διάρκεια του checkpoint <START T 1 > <T 1, A, 5> <START T 2 > <T 2, B, 10> <START CKPT(T 1,T 2 )> <T 2, C, 15> <START T 3 > <T 1, D, 20> <COMMIT T 1 > <T 3, E, 25> failure Επαναφορά: Οι T 3 και T 2 είναι οι μόνες ανολοκλήρωτες δοσοληψίες και οι αλλαγές που έκαναν πρέπει να αναιρεθούν. Όταν βρούμε το <START CKPT(T 1,T 2 )> οι πιθανές ανολοκλήρωτες δοσοληψίες είναι οι T 1, T 2 Επειδή όμως έχει βρεθεί <COMMIT T 1 >, το μόνο που χρειάζεται είναι να πάμε μέχρι το <START T 2 > και να αποκαταστήσουμε την τιμή του Β σε 10. 37

Redo Logging Πρόβλημα εξοικονόμησης Ι/Ο: με το undo logging δεν μπορούμε να οριστικοποιήσουμε μια δοσοληψία αν δεν γράψουμε πρώτα στον δίσκο όλα τα δεδομένα που μετέβαλε. Διαφορές κατά το recovery: Undo Logging ακυρώνει τις ανολοκλήρωτες δοσοληψίες και αγνοεί τις μεταβολές που έκαναν οι οριστικοποιημένες απαιτεί εγγραφεί των μεταβολών στο δίσκο πριν εμφανιστεί το <COMMIT> στο δίσκο για την αποκατάσταση χρειαζόμαστε τις παλιές τιμές των μεταβληθέντων στοιχείων Redo Logging αγνοεί τις ανολοκλήρωτες δοσοληψίες και επαναλαμβάνει τις μεταβολές που έκαναν οι οριστικοποιημένες απαιτεί εγγραφεί των μεταβολών στο δίσκο μετά την εμφάνιση του <COMMIT> στο δίσκο για την αποκατάσταση χρειαζόμαστε τις νέες τιμές των μεταβληθέντων στοιχείων 38

Κανόνες Redo Logging <T, X, v> σημαίνει: Η δοσοληψία T έγγραψε στο Χ την νέα τιμή v Κάθε φορά που υπάρχει τροποποίηση ενός στοιχείου Χ της ΒΔ, πρέπει να γράφεται στο log ένα δελτίο της μορφής <T, X, v> Υπάρχει μόνο ένας κανόνας στο Redo Logging για την σειρά που φτάνουν τα δεδομένα και τα log records στο δίσκο (write-ahead log rule): Πριν τροποποιήσουμε οποιοδήποτε στοιχείο Χ της ΒΔ στο δίσκο, πρέπει να γράφονται όλα τα σχετικά log records στο δίσκο (δηλαδή και τα <T, X, v> και το <COMMIT T>) Η σειρά εγγραφής στο δίσκο είναι: 1. Log records για μεταβληθέντα στοιχεία της ΒΔ 2. COMMIT log record 3. Τα ίδια τα μεταβληθέντα στοιχεία της ΒΔ 39

T1: Read (A,t); t t*2 Write (A,t); Read (B,t); t t*2 Write (B,t); Output (A); Output (B); A: 5 B: 5 10 10 Redo Logging A:5 B:5 <START T1> <T1, A, 10> 10 <T1, B, 10> <COMMIT T1> 10 memory disk log Παρατήρηση: Στα log records <T1, A, 10> και <T1, B, 10> φαίνονται οι νέες τιμές του Α και Β, όχι οι παλιές. 40

Recovery με Redo Logging Κατά την αποκατάσταση αντιμετωπίζουμε τις ανολοκλήρωτες δοσοληψίες σαν να μην εκτελέστηκαν ποτέ αν δεν υπάρχει το <COMMIT T> δεν έχουν γίνει αλλαγές στην ΔΒ Πρόβλημα: Τι γίνεται με τις ολοκληρωμένες δοσοληψίες? δεν γνωρίζουμε ποιες από τις μεταβολές έχουν πραγματικά γραφτεί στο δίσκο αλλά αυτό δεν μας ενοχλεί: έχουμε όλες τις πληροφορίες που χρειαζόμαστε (νέες τιμές) ώστε να τις ξαναγράψουμε στο δίσκο, ακόμα και ήδη βρίσκονται εκεί. Σε περίπτωση αστοχίας κάνουμε τα ακόλουθα: 1. Εντοπίζουμε τις οριστικοποιημένες δοσοληψίες 2. Ξεκινάμε από την αρχή του log και σαρώνουμε τα πρακτικά προς τα εμπρός. Για κάθε <T, X, v> : a. Αν η Τ δεν είναι οριστικοποιημένη, δεν κάνουμε τίποτα b. Αν η Τ είναι οριστικοποιημένη, τότε γράφουμε την τιμή v στο X 3. Για κάθε ανολοκλήρωτη δοσοληψία T, γράφουμε <ABORT T> στο log και κάνουμε flush log ώστε να σταλεί το log στο δίσκο. 41

Recovery με Redo Logging Παράδειγμα: Α=5, Β=5 Log (on disk) failure failure failure Read (A, t); t t*2 Write (A, t); Read (B, t); t t*2 Write (B, t); FLUSH LOG; Output (A); Output (B); <START T> <T, A, 10> <T, B, 10> <COMMIT T> To <COMMIT T> είναι ήδη στο δίσκο και η Τ έχει ολοκληρωθεί. Οι τιμές για τα A και B θα γραφτούν στο δίσκο κατά το recovery (ακόμα και αν δεν χρειάζεται) 42

Recovery με Redo Logging Παράδειγμα: Α=5, Β=5 Log (on disk) Read (A, t); t t*2 Write (A, t); Read (B, t); t t*2 Write (B, t); FLUSH LOG; Output (A); Output (B); <START T> failure 1 <T, A, 10> failure 1 <T, B, 10> failure 1 failure 2 failure 1 : To <COMMIT T> δεν είναι στο δίσκο και η Τ είναι ανολοκλήρωτη. Δεν θα γραφτούν τιμές για τα A και B στο δίσκο κατά το recovery. Θα γραφτεί στο log το <ABORT T>. failure 2 :Το <COMMIT T> έχει γραφτεί στο log (μνήμη) αλλά δεν έχει φτάσει με βεβαιότητα στο δίσκο. 43

Checkpoints με Redo Logging Πρόβλημα: Οι μεταβολές μιας οριστικοποιημένης δοσοληψίας μπορεί να γραφτούν στο δίσκο πολύ αργότερα από την στιγμή της οριστικοποίησης. Έτσι, δεν μπορούμε να περιορίσουμε το ενδιαφέρον μας μόνο στις δοσοληψίες που είναι ενεργές την στιγμή του σημείου ελέγχου. Επομένως, είτε για αδρανές είτε για μη-αδρανές checkpoints, πρέπει να εγγράφουμε στο δίσκο τις τροποποιήσεις που έγιναν σε στοιχεία της ΒΔ από οριστικοποιημένες δοσοληψίες. Πρέπει να γνωρίζουμε ποιοι buffers είναι dirty, δηλαδή το περιεχόμενο ενός στοιχείου έχει μεταβληθεί αλλά η μεταβολή δεν έχει εγγραφεί ακόμα στο δίσκο. Πρέπει επίσης να γνωρίζουμε ποιες δοσοληψίες έχουν τροποποιήσει το κάθε buffer. 44

Checkpoints με Redo Logging Όμως, μπορούμε να ολοκληρώσουμε το σημείο ελέγχου χωρίς να περιμένουμε το commit ή abort των ενεργών δοσοληψιών, αφού έτσι κι αλλιώς δεν τους επιτρέπεται να εγγράψουν εκείνη την στιγμή τις αλλαγές τους στο δίσκο. Βήματα για μη-αδρανή checkpoints με redo logging: 1. Γράψε ένα log record <START CKPT(T 1,T 2,,T k )> για κάθε ενεργή (μη οριστικοποιημένη) δοσοληψία T 1, T 2,, T k και κάνε flush log 2. Γράψε στο δίσκο όλα τα στοιχεία που ήταν γραμμένα σε buffers (αλλά όχι ακόμα στο δίσκο) από οριστικοποιημένες δοσοληψίες όταν γράφτηκε το <START CKPT(T 1,T 2,,T k )> στο log 3. Γράψε <END CKPT> στο log και κάνε flush log 45

Μη-αδρανή checkpoints με redo logging Παράδειγμα : <START T 1 > <T 1, A, 5> <START T 2 > <COMMIT T 1 > <T 2, B, 10> <START CKPT(T 2 )> <T 2, C, 15> <START T 3 > <T 3, D, 20> <END CKPT> <COMMIT T 2 > <COMMIT T 3 > Η T 2 είναι η μόνη ενεργή δοσοληψία. Όμως, η τιμή του Α της T 1 ενδέχεται να μην έχει φτάσει στο δίσκο. Για να μπορέσει να ολοκληρωθεί το checkpoint πρέπει να γραφτεί το Α στο δίσκο. 46

Επαναφορά με Checkpointed Redo Log Όταν σαρώνουμε το log file, η αναζήτηση μας περιορίζεται στο τμήμα μεταξύ του τέλους και της αρχής του checkpoint. Υπάρχουν δύο περιπτώσεις: 1. Αν στο log βρούμε <END CKPT> πριν το failure, γνωρίζουμε ότι όλες οι τιμές που τροποποιήθηκαν από κάθε οριστικοποιημένη δοσοληψία πριν το αντίστοιχο <START CKPT(T 1,T 2,, T k )> είναι στο δίσκο και δεν ασχολούμαστε με αυτές. Ωστόσο, οι μεταβολές που μπορεί να έχει κάνει κάποια από τις T 1,T 2,,T k ή από αυτές που άρχισαν μετά το <START CKPT> ενδέχεται να μην έχουν γραφτεί ακόμα στο δίσκο. Στην περίπτωση αυτή συνεχίζουμε την αποκατάσταση όπως πριν. Δεν χρειάζεται να κοιτάξουμε πιο πίσω από το προγενέστερο εκ των <START T i > 47

Επαναφορά με Checkpointed Redo Log 2. Αν στο log βρούμε <START CKPT(T 1,T 2,, T K )> πριν το failure, τότε δεν μπορούμε να γνωρίζουμε με βεβαιότητα αν οι μεταβολές στις τιμές που πραγματοποίησαν οριστικοποιημένες δοσοληψίες πριν την έναρξη του checkpoint έχουν εγγραφεί στο δίσκο. Πρέπει να ψάξουμε προς τα πίσω μέχρι το προηγούμενο <END CKPT>, μετά να βρούμε το αντίστοιχο <START CKPT(T 1,T 2,, T k )> και να κάνουμε redo της αλλαγές όπως στην περίπτωση 1 προηγουμένων.

Επαναφορά με Checkpointed Redo Log Παράδειγμα recovery: failure 3 failure 2 failure 1 <START T 1 > <T 1, A, 5> <START T 2 > <COMMIT T 1 > <T 2, B, 10> <START CKPT(T 2 )> <T 2, C, 15> <START T 3 > <T 3, D, 20> <END CKPT> <COMMIT T 2 > <COMMIT T 3 > failure 1 : Ψάχνουμε προς τα πίσω και βρίσκουμε το <END CKPT>. Υποψήφιες δοσοληψίες: T 3 και T 2. Υπάρχουν τα COMMIT τους οπότε πρέπει να γίνουν και οι δύο redo. Δηλαδή επανεγγράφουμε τις τιμές 10,15,20 για τα B,C,D αντίστοιχα. failure 2 : Ψάχνουμε προς τα πίσω και βρίσκουμε το <END CKPT>. Υποψήφιες δοσοληψίες: T 3 και T 2. Υπάρχει μόνο τo COMMIT της T 2 οπότε πρέπει να γίνει redo η T 2 (αγνοούμε την T 3 ). Δηλαδή επανεγγράφουμε τις τιμές 10,15 για τα B,C αντίστοιχα. Γράφουμε <ABORT T 3 >. failure 3 : Ψάχνουμε προς τα πίσω μέχρι το προτελευταίο <START CKPT> για να πάρουμε κατάλογο ενεργών δοσοληψιών. Επειδή δεν υπάρχει, φτάνουμε μέχρι την αρχή του log. Υπάρχει μόνο τo COMMIT μόνο της T 1 οπότε είναι και η μόνη που πρέπει να γίνει redo (αγνοούμε τις T 2 και T 3 ). Δηλαδή επανεγγράφουμε την τιμή 5 στο Α. Γράφουμε <ABORT T 2 > και <ABORT T 3 >. 49

Σύγκριση Undo Logging με Redo Logging Undo logging: απαιτεί τα δεδομένα να εγγραφούν στο δίσκο μόλις τελειώσει μια δοσοληψία, πιθανώς προκαλώντας αύξηση του αριθμού απαιτούμενων ενεργειών Ι/Ο στο δίσκο. Redo logging: απαιτεί να διατηρούνται τα τροποποιημένα blocks στους buffers μέχρι την οριστικοποίηση της δοσοληψίας και την αποστολή του log στο δίσκο. Πιθανώς προκαλεί αύξηση του απαιτούμενου μέσου αριθμού από buffers που χρειάζονται από τις δοσοληψίες. Και οι δύο μέθοδοι μπορεί να επιβάλλουν αντιφατικές απαιτήσεις στον τρόπο χειρισμού ενός checkpoint. Νέα μέθοδος: Undo/Redo logging. Είναι πιο ευέλικτη αλλά έχει επιπλέον κόστος τηρούμε περισσότερες πληροφορίες στο log. 50

Undo/Redo Logging Ένα log στην Undo/Redo διαφέρει μόνο στο record ενημέρωσης: <T, X, v, w> το οποίο σημαίνει ότι η δοσοληψία T άλλαξε την τιμή του στοιχείου Χ της ΒΔ από v σε w. Κανόνας: πριν τροποποιηθεί οποιοδήποτε στοιχείο Χ της ΒΔ στο δίσκο, το record ενημέρωσης <T, X, v, w> πρέπει να εμφανιστεί στο δίσκο το <COMMIT T> μπορεί να είναι πριν ή μετά από κάθε αλλαγή των στοιχείων της ΒΔ στο δίσκο Κατά την διάρκεια του recovery, επιτρέπει είτε την επαναφορά είτε την επανάληψη. Πολιτική αποκατάστασης (recovery policy): Επανέφερε (Redo) όλες τις οριστικοποιημένες δοσοληψίες (earliest first) Αναίρεσε (Undo) τις μη-οριστικοποιημένες δοσοληψίες (latest first) Και τα δύο είναι απαραίτητα για να αποφύγουμε ημιτελή recovery 51

T1: Read (A,t); t t*2 Write (A,t); Read (B,t); t t*2 Write (B,t); Output (A); Output (B); A: 5 B: 5 10 10 Undo/Redo Logging A:5 B:5 <START T1> <T1, A, 5, 10> 10 <T1, B, 5, 10> <COMMIT T1> 10 Παρατηρήσεις: Στα log records <T1, A, 5, 10> και <T1, B, 5, 10> φαίνονται και οι παλιές και οι νέες τιμές του Α και Β. Το <COMMIT T1> μπορεί να γίνει και ενδιάμεσα της εγγραφής των Α και Β στο δίσκο. memory disk log 52

Recovery με Undo/Redo Logging Παράδειγμα: Α=5, Β=5 Log (on disk) failure 1 Read (A, t); t t*2 Write (A, t); Read (B, t); t t*2 Write (B, t); FLUSH LOG; Output (A); Output (B); failure 1 <START T> <T, A, 5, 10> <T, B, 5, 10> <COMMIT T> failure 1 : Αν η αποτυχία γίνει μετά που έχει γραφτεί το <COMMIT T> στο δίσκο, τότε η Τ θεωρείται ολοκληρωμένη και γίνεται redo, δηλαδή θα γραφτεί η τιμή 10 και για το A και για το B στο δίσκο κατά το recovery. 53

Recovery με Undo/Redo Logging Παράδειγμα: Α=5, Β=5 Log (on disk) failure 2 failure 2 failure 2 failure 2 failure 2 Read (A, t); t t*2 Write (A, t); Read (B, t); t t*2 Write (B, t); FLUSH LOG; Output (A); Output (B); failure 2 failure 2 failure 2 <START T> <T, A, 5, 10> <T, B, 5, 10> failure 2 : Αν η αποτυχία γίνει πριν γραφτεί το <COMMIT T> στο δίσκο, τότε η Τ θεωρείται ανολοκλήρωτη και γίνεται undo, δηλαδή θα γραφτεί η τιμή 5 και για το A και για το B στο δίσκο κατά το recovery. 54

Recovery με Undo/Redo Logging Ένας επιπλέον κανόνας μπορεί να χρησιμοποιηθεί για να αποφύγουμε περιπτώσεις όπου ο χρήστης θεωρεί ότι μια δοσοληψία ολοκληρώθηκε (π.χ. κράτηση εισιτηρίου) αλλά το COMMIT δεν έχει σταλεί ακόμα στο δίσκο μια πιθανή κατάρρευση θα είχε αποτέλεσμα να γίνει undo και όχι redo! Νέος επιπλέον κανόνας: ένα <COMMIT T> πρέπει να στέλνεται στο δίσκο με το που θα εμφανιστεί στο log πρακτικά πρέπει να προσθέσουμε ένα FLASH LOG 55

Checkpoints με Undo/Redo Logging Μη-αδρανή (non-quiescent) checkpoints (απλούστερα): 1. Γράψε <START CKPT(T 1,T 2,,T k )> στο log για όλες τις ενεργές δοσοληψίες T 1,T 2,,T k και κάνε flush το log 2. Γράφουμε στο δίσκο όλους τους dirty buffers (όσους περιέχουν στοιχεία της ΒΔ που έχουν μεταβληθεί όχι μόνο από οριστικοποιημένες δοσοληψίες όπως στο Redo Logging) 3. Γράψε <END CKPT> και κάνε flush το log στο δίσκο. Το βήμα 2, λόγω της ευελιξίας του Undo/Redo, επιβάλει την εγγραφή στοιχείων στο δίσκο που προέρχονται από ανολοκλήρωτες δοσοληψίες. Υπάρχει όμως η εξής απαίτηση: Μια δοσοληψία δεν πρέπει να εγγράψει καμία τιμή (ούτε καν στο buffer μνήμης) μέχρι να είναι σίγουρο ότι δεν θα ματαιωθεί (abort). 56

Παράδειγμα recovery: failure 2 failure 1 Επαναφορά με Checkpointed Undo/Redo Logging <START T 1 > <T 1, A, 4, 5> <START T 2 > <COMMIT T 1 > <T 2, B, 9, 10> <START CKPT(T 2 )> <T 2, C, 14, 15> <START T 3 > <T 3, D, 19, 20> <END CKPT> <COMMIT T 2 > <COMMIT T 3 > Στο ξεκίνημα του checkpoint, η τιμή του Β θα σταλεί στο δίσκο. Η τιμή του Α από την ολοκληρωμένη T 1 θα σταλεί επίσης στο δίσκο, αν δεν βρίσκεται ήδη εκεί. failure 1 : Ψάχνουμε προς τα πίσω και βρίσκουμε το <END CKPT>. Οι T 3 και T 2 είναι οριστικοποιημένες οπότε πρέπει να γίνουν και οι δύο redo. Δηλαδή επανεγγράφουμε τις τιμές 15,20 για τα C,D αντίστοιχα. Την T 1 την αγνοούμε γιατί έχει ήδη εγγραφεί στο δίσκο. Δεν χρειάζεται να κοιτάζουμε πριν από το <START CKPT> failure 2 : Βλέπουμε ότι η T 2 είναι οριστικοποιημένη ενώ η T 3 είναι ανολοκλήρωτη. Επαναλαμβάνουμε (redo) την T 2 θέτοντας την τιμή του C ίση με 15 (δεν χρειάζεται να γράψουμε την τιμή του Β ίση με 10). Αναιρούμε (undo) την T 3 ) και θέτουμε την τιμή του D ίση με 19. Δεν χρειάζεται να κοιτάζουμε πριν από το <START CKPT> 57