PRINCIPLES OF TRANSACTION-ORIENTED DATABASE RECOVERY Theo Haerder Andreas Reuter Μαρία Κουτσουλιέρη Για να συλλάβουµε την ιδέα της ανάνηψης στις βάσεις δεδοµένων (database recovery) πρέπει να έχουµε υπ όψιν µας δυο παράγοντες : τον τύπο του σφάλµατος µε την οποία έχουµε να κάνουµε. Υπάρχουν τρείς τύποι σφαλµάτων: 1. Σφάλµα σε επίπεδο συναλλαγής(transaction failure): συµβαίνει όταν η transaction δεν γίνεται commit για διαφόρους λόγους και πρέπει να ξαναρχίσει. 2. Σφάλµα σε επίπεδο συστήµατος(system failure): συµβαίνει λόγω λάθους στον DBMS κώδικα ή λόγω λάθους στο λειτουργικό ή προβλήµατος hardware. Σε κάθεµιά από αυτές τις περιπτώσεις θεωρούµε ότι τα περιεχόµενα της κύριας µνήµης χάνονται. 3. Σφάλµα Μέσου(media failure): συµβαίνει λόγω λάθους στις ρουτίνες του λειτουργικού που γράφουν στο δίσκο, ή λάθους στο κανάλι, η crash της κεφαλής, ή σε χάσιµο πληροφορίας εξαιτίας µαγνητικής σήψης. Θεωρούµε ότι χάνεται µέρος του δίσκου στον οποίο βρίσκεται η βάση δεδοµένων. την αντίληψη που έχουµε για τη συνέπεια της βάσεως δεδοµένων που χρησιµεύει ως κριτήριο για την κατασταση στην οποία θα πρέπει να την επαναφέρουµε µετά την αποτυχία Κατ αρχάς έχει παρατηρηθεί πως ο χειρισµός των δεδοµένων σε ένα περιβάλλον µε πολλούς χρήστες απαιτεί ένα είδος αποµόνωσής τους για τον εξής λόγο: ένας χρήστης ή µια διαδικασία πολύ συχνά κάνουν ενέργειες οι οποίες έχουν δοκιµαστικό χαρακτήρα Εποµένως µπορεί να δηµιουργήσουν βρώµικα δεδοµένα τα οποία µπορεί να διαβαστούν και να χρησιµοποιηθούν από άλλους χρήστες. Εποµένως πρέπει να βρούµε έναν τρόπο να ελέγχουµε την αξιοπιστία αυτών των δεδοµένων. Γι αυτόν τον λόγο εισάγουµε την έννοια της συναλλαγής (transaction).
Η συναλλαγή είναι µια ατοµική µονάδα εκτέλεσης, δηλαδή µια ακολουθία εντολλών όπως FIND και MODIFY που είτε εκτελείται µέχρι το τέλος της, είτε δεν εκτελείται καθόλου. Η συναλλαγή έχει 4 βασικές ιδιότητες: ΑΤΟΜΙΚΟΤΗΤΑ: σηµαίνει πως είτε όλη η συναλλαγή εκτελείται είται καµιά εντολή της δεν εκτελείται. Ο χρήστης πρέπει να ξέρει κάθε στιγµή σε ποιά κατάσταση βρίσκεται. Γι αυτό τον λόγο, αν µία συναλλαγή διακοπεί από ένα σφάλµα (crash ή media failure), ότι έχει διεξαχθεί στη βάση γίνεται UNDONE. ΣΥΝΕΠΕΙΑ: τα αποτελέσµατα κάθε επιτρεπτής συναλλαγής που έχει κάνει commit, είναι νόµιµα για τη βάση δεδοµένων. ΑΠΟΜΟΝΩΣΗ: µια συναλλαγή που δεν έχει τελειώσει δε µπορεί να αποκαλύψει τις αλλαγές που έχει κάνει στις άλλες συναλλαγές. Αυτή η ιδιότητα χρειάζεται για να αποφύγουµε το πρόβληµα των cascading aborts, δηλαδή την ανάγκη να κάνουµε abort όλες τις µετέπειτα transactions που έχουν διαβάσει τα αποτελέσµατα της transaction που θέλουµε να κάνουµε abort. ΜΟΝΙΜΟΤΗΤΑ: απο τη στιγµή που µια συναλλαγή εχει κάνει commit, το σύστηµα πρέπει να διασφαλίσει πως τα αποτελέσµατά της δε θα χαθούν ανεξάρτητα από το αν θα συµβούν µετέπειτα σφάλµατα συστήµατος ή άλλου είδους σφάλµατα Για να διασφαλιστούν αυτές οι ιδιότητες έχουµε εισαγάγει τέσσερεις ενέργειες ανάνηψης: UNDO συναλλαγής (Transaction UNDO): συµβαίνει όταν µια συναλλαγή κάνει abort τον εαυτό της (π.χ επειδή ανακάλυψε λάθη στα δεδοµένα εισόδου ή άλλες παραβιάσεις συνέπειας) ή γίνεται aborted από το σύστηµα (π.χ να είναι το θύµα σε ένα deadlock). Αυτό που κάνει είναι να διαγράφει από τη βάση ότι αλλαγές έχει κάνει αυτή η συναλλαγή και δεν επηρεάζει τις υπόλοιπες. Ολικό UNDO (Global UNDO): όταν γίνεται ανάνηψη µετά από ένα σφάλµα συστήµατος, όλες οι αλλαγές που προκλήθηκαν από ατελείς συναλλαγές πρέπει να γίνουν rolled back.
Μερικό REDO (Partial REDO): όταν γίνεται ανάνηψη µετά από ένα σφάλµα συστήµατος, τα αποτελέσµατα ολοκληρωµένων συναλλαγών µπορεί να µην έχουν αποτυπωθεί στη βάση. Σε αυτήν την περίπτωση οι συναλλαγές αυτές πρέπει να επανεκτελεστούν. Ολικό REDO (Global REDO): Ο Gray του δίνει τον όρο ανάνηψη αρχείου. Η βάση θεωρείται κατεστραµένη. Εποµένως πρέπει να ξεκινήσουµε από µια κόπια της η οποία απεικονίζει την κατάστασή της σε παλιότερο χρόνο. Εποµένως πρέπει να εµπλουτίσουµε την κόπια µε τις αλλαγές όλων των transactions που έχουν κάνει commit από τη στιγµή που δηµιουργήθηκε η κόπια Τα παραπάνω συντελούνται µε τη χρήση των αρχείων LOG. Τα αρχεία LOG περιέχουν επιπλέον πληροφορία, η οποία συλλέγεται για το σκοπό της ανάνηψης µετά από σφάλµα συστήµατος ή Μέσου. Περιέχουν πληροφορία για UNDO ή REDO των ενεργειών που εκτελούνται από τις συναλλαγές. ύο τύποι αρχείων LOG µας χρειάζονται: Προσωρινό LOG: Το αρχείο αυτό υποστηρίζει ανάνηψη µετά από crash, δηλαδή περιέχει πληροφορία για την επανοικοδόµηση του πιο πρόσφατου database buffer (περιοχή µνήµης). Το επιλεκτικό transaction UNDO απαιτεί τυχαία προσπέλαση στα records του log αρχείου, εποµένως το προσωρινό log βρίσκεται στο δίσκο. Αρχειακό LOG: Υποστηρίζει ολικό REDO µετά από σφάλµα Μέσου. Εφόσον η ανάνηψη γίνεται µε σειριακό τρόπο (τηρείται η χρονική σειρά), είναι γραµµένο σε µαγνητική ταινία. Σε αυτή τη φάση, για να καταλάβουµε πως επανακτούµε τα περιεχόµενα µιας σελίδας σε περίπτωση σφάλµατος, πρέπει να καταλάβουµε τους τρείς διαφορετικούς τρόπους µε τους οποίους φανταζόµασετ τη βάση δεδοµένων : Τρέχουσα βάση (Current database): τα τρέχοντα περιεχόµενα όλων των σελίδων βρίσκονται στο δίσκο, εκτός από αυτά που έχουν αλλάξει πρόσφατα, οπότε βρίσκονται στο batabase buffer, στην κύρια µνήµη.
Υλοποιηµένη βάση (Materialized database) : είναι η κατάσταση στην οποία το DBMS βρίσκει τη βάση µετά από ένα crash. Οι αλλαγές σε ορισµένες σελίδες µπορεί να µην έχουν γίνει σε αυτήν την κόπια, οπότε κάθε αναφορά σε αυτές τις σελίδες θα δώσει µια παλιότερη τιµή. Εποµένως, το σύστηµα ανάνηψης πρέπει να µετατρέψει την υλοποιηµένη βάση στην τρέχουσα βάση. Υλική βάση (Physical Database) : περιέχει εικόνες των σελίδων (page images). Μπορεί να έχουµε διάφορες τιµές για µια σελίδα, καµία κατ ανάγκην τρέχουσα. Υπάρχουν τρείς τύποι UPDATE λειτουργιών: 1. αλλαγές στα περιεχόµενα των σελίδων που επηρεάζουν µόνο την τρέχουσα βάση, 2. η λειτουργία εγγραφής που επηρεάζει την υλική βάση, 3. η λειτουργία του να γίνει η γραµµένη εικόνα της σελίδας (written page image) µέρος της υλοποιηµένης βάσης. Αυτή η λειτουργία ονοµαζεται διάδοση (propagation). Όµως, κάθε αλλαγή σε µια σελίδα πρώτα γίνεται σε ενα database buffer, δηλαδή αποθηκεύεται σε ασταθές µέρος (κύρια µνήµη). Για να σωθεί αυτή η κατάσταση της σελίδας, πρέπει να αποθηκευτεί σε µη ασταθές µέρος (δίσκος) Υπάρχουν δύο διαφορετικοί τρόποι µε του οποίους αυτό µπορεί να επιτευχθεί: Άµεση διανοµή σελίδων (Direct page allocation) : κάθε διάδοση µπορεί να διακοπεί από ένα συστηµικό σφάλµα. Εποµένως, η υλοποιηµένη βάση µπορεί να βρεθεί σε µη συνεπή κατάσταση. Έµµεση διανοµή σελίδων (indirect page allocation) : πάντα υπάρχει τρόπος να ξαναπάµε πίσω σε µια παλιά κατάσταση. εν επηρεάζεται από τα συστηµικά σφάλµατα.
Παίρνοντας σα βάση αυτά που είπαµε παραπάνω, ξεχωρίζουµε δύο στρατηγικές διάδοσης: 1. ATOMIC : όλα ή τίποτα update στρατηγική. Κάθε σύνολο αλλαγµένων σελίδων διαδίδεται σαν µονάδα και γίνεται µέρος της υλοποιηµένης βάσης. 2. ATOMIC : οι σελίδες γράφονται στα blocks σύµφωνα µε µια update-in-place στρατηγική. Αφού κανένα σύνολο σελίδων δε µπορεί να γραφεί αδιαίρετο, η διάδοση είναι ευπαθής στα συστηµικά σφάλµατα. Μετά από ένα συστηµικό σφάλµα έχουµε την υλοποιηµένη βάση και το προσωρινό LOG για να αρχίσουµε τη διαδικασία της ανάνηψης. Στην περίπτωση της άµεσης διανοµής σελίδων και της ATOMIC διάδοσης, κάθε λειτουργία εγγραφής εππηρεάζει την υλοποιηµένη βάση, αφήνοντας την κατάστασή της µή προβλέψιµη µετά από ενα crash. Εποµένως, δεν ξέρουµε αν πρέπει να κάνουµε UNDO ή REDO. Στην περίπτωση της έµµεσης διανοµής σελίδων και της ATOMIC διάδοσης, ξέρουµε πολύ περισσότερα για την κατάσταση της υλοποιηµένης βάσης µετά από ένα crash. Αυτή η κατάσταση µπορεί πάλι να µην είναι συνεπής, παρόλλα αυτά η ATOMIC διάδοση καθιστά σίγουρο πως η διάδοση θα λάβει µέρος σε µια χρονική στιγµή που η τρέχουσα βάση θα πληρεί ορισµένους περιορισµούς συνέπειας (consistency constraints). Εποµένως, µετά από ένα crash : ATOMIC διάδοση:η κατάσταση της υλοποιηµένης βάσης είναι χαώδης ATOMIC διάδοση: η υλοποιηµένη βάση είναι συνεπής. Υπάρχουν επιπλέον µέτρα για να µειώσουµε το µέγεθος της αβεβαιότητας που προκαλεί η ATOMIC διάδοση, δηλαδή ο manager του buffer να είναι τέτοιος, ώστε να αποτρέπει την εγγραφή ή διάδοση των βρώµικων σελίδων σε κάθε περίπτωση. Εποµένως, απλοποιούνται οι UNDO λειτουργίες. ύο διαφορετικές µέθοδοι εισαγάγονται µε αυτήν την ιδέα: STEAL : οι αλλαγµένες σελίδες εγγράφονται ή διαδίδονται κάθε χρονική στιγµή. Χρειαζόµαστε πληροφορίες για να κάνουµε UNDO. STEAL : οι αλλαγµάνες σελίδες φυλάσσονται στο buffer τουλάχιστον µέχρι το τέλος της συναλλαγής (EndOfTransaction: EOT). ε χρειαζόµαστε logging για UNDO.
Υπάρχει και άλλο ένα κριτήριο που αφορά τον χειρισµό του buffer, το οποίο σχετίζεται µε την αναγκαιότητα του REDO µε την επανεκκίνηση µετά το σφάλµα (συστηµικό ή άλλο) : FORCE : Όλες οι αλλαγµένες σελίδες εγγράφονται και διαδίδονται κατά τη διάρκεια του ΕΟΤ. Εποµένως, δε χρειαζόµαστε logging για µερικό REDO Χρειαζόµαστε όµως πληροφορία για ολικό REDO. FORCE : η διάδοση δεν ενεργοποιείται µε το EOT, εποµένως χρειαζόµαστε logging για µερικό REDO. Υπάρχουν διάφοροι τύποι logging. Όµως, ανεξάρτητως τύπου, η εγγραφή πλαροφορίας στα log διέπεται από δυο κανόνες, οι οποίοι είναι προφανείς αν λάβουµε υπ όψιν µας πως υπάρχουν τα σφάλµατα: 1. Η πληροφορία για UNDO πρέπει να γράφεται στο log πρίν οι σχετιζόµενες αλλαγές διαδοθούν στην υλοποιηµένη βάση. 2. Η πληροφορία για REDO πρέπει να γράφεται στο προσωρινό και το αρχειακό log πρίν το EOT γνωστοποιηθεί στο πρόγραµµα της συναλλαγής. Υπάρχει όµως ένα πρόβληµα, το πρόβληµα των καυτών σελίδων ( hot spot pages ) το οποίο είναι το εξής: Παρόλλο που οι περισσότερες σελίδες θα έχουν υποστεί αλλαγές πρόσφατα, υπάρχουν και ορισµένες ( hot spots ), οι οποίες αλλάζουν συνεχώς και επειδή αναφερόµαστε σε αυτές πολύ συχνά, δεν έχουν γραφτεί ακόµα από τον buffer στον δίσκο.αυτές οι σελίδες, µετά από ένα διάστηµα, θα περιέχουν πολλές αλλαγές που οφείλονται σε ολοκληρωµένες συναλλαγές. Εποµένως, η REDO recovery (ανάνηψη), θα πρέπει να πάει πολύ πίσω στο προσωρινό log. Γενικά, το πλήθος των πληποφοριών του log που χρειάζεται να επεξεργαστούµε για µερικό REDO θα αυξάνει µε το χρονικό διάστηµα µεταξύ δυο συνεχόµενων crashes. Αυτό δεν είναι αποδεκτό για µεγάλες εφαρµογές Γι αυτό το λόγο, εισάγουµε τη µέθοδο των checkpoints. Το να παράγουµε ένα checkpoint είναι το να µαζεύουµε πληροφορία σε ένα ασφαλές µέρος, το οποίο έχει το αποτέλεσµα να µειώσει το πλήθος των REDO που απαιτούνται µετά από ένα crash. Η παραγωγή checkpoint έχει τρία βήµατα: 1. Γράψε ένα BEGIN_CHECKPOINT record στο προσωρινό αρχείο log 2. Γράψε όλα τα δεδοµένα του checkpoint στο log αρχείο και/ή στη βάση 3. Γράψε ένα END_CHECKPOINT record στο προσωρινό αρχείο log.
ΤΥΠΟΙ CHECKPOINTS Transaction-Oriented checkpoints (TOC) : Εφόσον η FORCE µέθοδος αποφεύγει το µερικό REDO, γεγονός το οποίο είναι ο σκοπός των checkpoints, τα transaction-oriented checkpoints υπονοούνται από την FORCE µεθοδολογία. Εποµένως, το ΕΟΤ record κάθε συναλλαγής µπορεί να ερµηνευτεί ώς ένα BEGIN_CHECKPOINT και ένα END_CHECKPOINT. Παρόλλα αυτά, οι hot spot σελίδες θα διαδίδονται κάθε φορά που υπόκεινται αλλαγές από µία συναλλαγή, παρά το γεγονός ότι µένουν στον buffer για µεγάλο χρονικό διάστηµα. Εποµένως, για DBMS που στηρίζει µεγάλες εφαρµογές, τα transaction-oriented checkpoints δεν είναι η σωστή επιλογή. Transaction-consistent checkpoints (TCC) : Tα transaction-consistent checkpoints είναι ολικά στο ότι σώζουν τη δουλειά όλων των συναλλαγών που έχουν αλλάξει τη βάση δεδοµένων µέχρι εκείνη τη στιγµή. Το πρώτο TCC, όταν παράγεται επιτυχώς, δηµιουργεί µια βάση η οποία είναι transaction-consistent. Όταν το recovery component δίνει σήµα για την παραγωγή ενός checkpoint, όλες οι ατελείς update συναλλαγές τελειώνουν και δεν επιτρέπονται καινούριες. Μετά το επιτυχές γράψιµο του END_CHECKPOINT, η κανονική λειτουργία συνεχίζεται. Επίσης, γράφεται ένα record στο log, το οποίο ενηµερώνει την υλοποιηµένη βάση ότι τώρα βρισκόµαστε σε µια νέα transaction-consistent κατάσταση. Εποµένως, οι REDO πληροφορίες του log χρειάζεται να επεξεργαστούν µόνο από το τέλος µέχρι το νεότερο END_CHECKPOINT record που βρίσκεται στο log. Και αυτή η µέθοδος έχει µειονεκτήµατα για µεγάλες εφαρµογές µε πολλούς χρήστες: υπάρχει καθυστέρηση για τις καινούριες συναλλαγές και ακόµη υπάρχει µεγάλο κόστος στην περίπτωση που έχουµε µεγάλους buffers. Παρόλλα αυτά είναι πολύ χρήσιµη µέθοδος για µικρές εφαρµογές µε έναν χρήστη Action-Consistent checkpoints (ACC) : Τα action-consistent checkpoints παράγονται µόνο όταν δεν υπάρχει update ενέργεια. Όταν δίνεται σήµα για ένα action-consistent checkpoint σταµατούν όλες οι άλλες ενέργειες στο σύστηµα. Επίσης, το END_CHECKPOINT υπονοεί µία συνεπή βάση σε επίπεδο ενεργειών αντί για επίπεδο συναλλαγών. Τα πλεονεκτήµατα αυτής της µεθόδου είναι πως µε αυτόν τον τρόπο µπαίνει ένα φράγµα στο µερικό REDO καθώς και το ότι
η REDO πληροφορία που βρίσκεται στο log πρίν το τελευταίο checkpoint, δε µας χρειάζεται για το crash recovery. Fuzzy checkpoints : Η διάδοση τη στιγµή του checkpoint αποφεύγεται αν είναι δυνατόν. Αυτό επιτυγχάνεται µε την εγγραφή πληροφορίας σχετικά µε τους buffers στο log αρχείο αντί για την εγγραφή της στις σελίδες. Τα βασικά στοιχεία αυτής της µεθόδου είναι α) πως ασχολούµαστε µόνο µε το προσωρινό log, αφήνοντας τη βάση ώς έχει και β) αν υπάρχουν hot spot pages,η REDO πληροφορία πρέπει να εντοπιστεί πολύ πίσω στο προσωρινό log, το οποίο είναι και µειονέκτηµα Οι συνδυασµοί των στρατηγικών που συζητήσαµε φαίνινται στο παρακάτω σχήµα: Εκ πρώτης όψεος, schemes όπως ATOMIC, FORCE, TOC φαίνονται πολύ καλά για crash recovery, π.χ σύµφωνα µε το παραπάνω η υλοποιηµένη βάση θα βρίσκεται πάντα στην πιο πρόσφατη transaction-consistent κατάσταση καθώς δεν θα επηρεάζεται από ατελείς συναλλαγές. Επίσης, οι ολοκληρωµένες συναλλαγές θα διαδοθούν µε το ΕΟΤ. Παρόλλα αυτά στην περίπτωση της κανονικής λειτουργίας το overhead είναι πολύ υψηλό για να δικαιολογήσει τη χρήση τους Εποµένως πρέπει να ζυγιστούν τα υπέρ και τα κατά για να διαλέξουµε ένα scheme και αυτή η απόφαση λαµβάνει υπ όψιν της πολλούς παράγοντες, η συζήτηση όµως αυτή ξεφεύγει από το σκοπό αυτού του paper.
ON OPTIMISTIC METHODS FOR CONCURENCY CONTROL H.T KUNG JOHN T.ROBINSON Μαρία Κουτσουλιέρη Υπάρχουν τουλάχιστον δύο περιπτώσεις στις οποίες είναι επιθυµητή η ταυτόχρονη προσπέλαση στα αντικείµενα της βάσης : όταν υπάρχουν πολλά δεδοµένα, ώστε κάθε στιγµή µόνο ένα κλάσµα της βάσης µπορεί να βρίσκεται στην κύρια µνήµη υπάρχουν πολλοί επεξεργαστές. Όµως, η µη περιορισµένη ταυτόχρονη προσπέλαση δηµιουργεί το εξής πρόβληµα: χάσιµο της συνέπειας της βάσης δεδοµένων Οι πιο πρόσφατες προσεγγίσεις στο πρόβληµα αυτό περιλαµβάνουν κλείδωµα (LOCKING). Αυτός είναι ένας µηχανισµός σύµφωνα µε τον οποίον µια διαδικασία (process) αρνείται σε ορισµένες άλλες διαδικασίες την προσπέλαση σε κάποιο κοµµάτι της βάσης. Παρόλλα αυτά, η προσέγγιση αυτή έχει ορισµένα µειονεκτήµατα: 1. Ακόµη και οι read-only συναλλαγές χρησιµοποιούν κλείδωµα 2. εν υπάρχει γενικευµένο deadlock-free πρωτόκoλλο που πάντα παρέχει υψηλή ταυτόχρονη προσπέλαση 3. Στην περίπτωση που µεγάλα κοµµάτια της βάσης βρίσκονται στη δευτερεύουσα µνήµη, αν ένας υπερπλήρης κόµβος (congested node) είναι κλειδωµένος ενώ περιµένουµε για τη µεταφορά δεδοµένων από τη δευτερέυουσα µνήµη, το επίπεδο της ταυτόχρονης προσπέλασης µειώνεται 4. Τα locks δεν µπορούν να ελευθερωθούν πρίν το τέλος της συναλλαγής, αφού πρέπει να επιτρέψουµε σε µια συναλλαγή να κάνει abort σε περίπτωση αποτυχίας 5. Αν το πλήθος των κόµβων στον object γράφο είναι πολύ µεγαλύτερο από τον συνολικό αριθµό των κόµβων που περιλαµβάνονται σε όλες τις συναλλαγές που τρέχουν, το κλείδωµα είναι απαραίτητο µόνο στην χειρότερη περίπτωση.
Εποµένως, προτείνουµε optimistic ( αισιόδοξες ) µεθόδους που δεν χρησιµοποιούν κλείδωµα και βασίζονται στην ελπίδα πως δε θα υπάρξουν συγκρούσεις µεταξύ των συναλλαγών. Έτσι αυτή η µέθοδος είναι deadlockfree. H optimistic µέθοδος συνοψίζεται ώς εξής: Το διάβασµα (reads) είναι χωρίς περιορισµούς Το γράψιµο (writes) είναι βαριά περιορισµένο. Αποτελείται από τρείς φάσεις: 1. Φάση διαβάσµατος (read phase) : ολα τα writes γίνονται σε τοπικές κόπιες των κόµβων (nodes) που θέλουµε να αλλάξουµε 2. Φάση επαλήθευσης (validation phase) : κατα τη διάρκεια αυτής της φάσης επαληθεύεται πως οι αλλαγές που επιφέρει η συναλλαγή δε θα προκαλέσουν χάσιµο της συνέπειας στη βάση 3. Φάση γραψίµατος (write phase) : οι αλλαγές γίνονται δηµοσία γνωστές. Συντελείται µόνο αν η επαλήθευση επιτύχει. Εποµένως, έχουµε κέρδος αφού στην προσέγγιση του κλειδώµατος, το κλείδωµα είναι απαραίτητο µόνο στη χειρότερη περίπτωση, ενώ στην αισιόδοξη προσέγγιση η επαλήθευση θα αποτύχει µόνο στη χειρότερη περίπτωση Από τις τρείς φάσεις, το µεγαλύτερο ενδιαφέρον παρουσιάζει η φάση επαλήθευσης. Η ΦΑΣΗ ΕΠΑΛΗΘΕΥΣΗΣ Ένα ευρείας χρήσης κριτήριο για την επαλήθευση της σωστότητας της ταυτόχρονης εκτέλεσης των συναλλαγών ονοµάζεται σειριακή ισοδυναµία (serial equivalence). ύο συναλλαγές Τ i και T j εκτελούνται σειριακά, αν η τελευταία λειτουργία του Τ i έρχεται πρίν την πρώτη λειτουργία του Τ j. Εποµένως, υπάρχει σειριακή ισοδυναµία των ταυτόχρονων συναλλαγών T 1, T 2,, T n, αν υπάρχει κάποια µετάθεση π του συνόλου {1,2,,n} τέτοια ώστε η τελική κατάσταση της βάσης στην ταυτόχρονη εκτέλεση να είναι ίδια µε την τελική κατάσταση στην σειριακή εκτέλεση, δηλαδή
d τελική = T π(n) T π(n-1) T π(2) Τ π(1) (d αρχική ) Πρέπει να βρεθεί µια µετάθεση π. Αυτό επιτυγχάνεται µε το να αναθέσουµε σε κάθε συναλλαγή Τ i, έναν µοναδικό ακέραιο ο οποίος καλείται transaction number t(i). Η ιδέα είναι η εξής: πρέπει να υπάρχει ένα σειριακά ισοδύναµο schedule στο οποίο η συναλλαγή Τ i έρχεται πρίν από τη συναλλαγή Τ j, όποτε t(i) < t(j). ΠΡΟΫΠΟΘΕΣΕΙΣ ΕΠΑΛΗΘΕΥΣΗΣ: για κάθε συναλλαγή Τ j µε transaction number t(j) και για όλες τις συναλλαγές Τ i µε t(i) < t(j), µια από τις παρακάτω τρείς προϋποθέσεις πρέπει να ισχύει: 1. H T i συµπληρώνει τη φάση γραψίµατος πρίν η Τ j ξεκινήσει τη φάση διαβάσµατος 2. Το σύνολο εγγραφών (write set) της Τ i δεν τέµνει το σύνολο διαβασµάτων (read set) της Τ j και η Τ i συµπληρώνει τη φάση γραψίµατος πρίν η Τ j ξεκινήσει τη φάση γραψίµατος 3. Το write set της Τ i δεν τέµνει το read set ή το write set της Τ j και η T i συµπληρώνει τη φάση διαβάσµατος πρίν η Τ j συµπληρώσει τη φάση διαβάσµατος. Πώς όµως αναθέτουµε transaction numbers; Σε πρώτη σκέψη θα τα αναθέταµε στην αρχή της φάσης διαβάσµατος. Όµως αυτό δεν είναι optimistic: σκεφτείτε την περίπτωση που οι T 1, T 2 ξεκινούν περίπου την ίδια στιγµή και έχουν transaction numbers n και n+1 αντίστοιχα. Αν η Τ 2 συµπληρώσει τη φάση διαβάσµατος πρίν την Τ 1, πρέπει να περιµέναι την Τ 1 να συµπληρώσει τη φάση της επαλήθευσης αφού για να επαληθευτεί η Τ 2 πρέπει να γνωρίζουµε το write set της Τ 1. Εποµένως, αναθέτουµε transaction numbers στο τέλος της φάσης διαβάσµατος. Τί όµως πρέπει να κάνουµε όταν η φάση επαλήθευσης αποτυγχάνει; Σε αυτήν την περίπτωση, η συναλλαγή γίνεται aborted και επαναξεκινά παίρνοντας ένα καινούριο transaction number στο τέλος της φάσης διαβάσµατος. Παρόλλα αυτά, αν αποτυγχάνει συνεχώς έχουµε µια κατάσταση πείνας (starving). Εποµένως, οι συναλλαγές µπαίνουν σε ένα συντοµο critical section στο τέλος της φάσης γραψίµατος.
Αν το concurrency control εντοπίσει µια πεινασµένη συναλλαγή, τότε η συναλλαγή αυτή θα ξαναρχίσει χωρίς να ελευθερώσει την critical section semaphore. Αυτή η τακτική είναι ισότιµη του κλειδώµατος σε επίπεδο γραψίµατος (write-locking) ολόκληρης τη βάσης δεδοµένων και έτσι η πεινασµένη συναλλαγή θα τρέξει έως το τέλος της. Όπως είδαµε, σε µια locking προσέγγιση, έχουµε έλεγχο πάνω στις συναλλαγές µε το να τις έχουµε να περιµένουν σε ορισµένες χρονικές στιγµές, ενώ στην optimistic προσέγγιση της κάνουµε abort και τις ξαναρχίζουµε. Όπως όµως διαπιστώσαµε, το locking δεν µπορεί να αποφευχθεί ούτε στην optimistic προσέγγιση εξαιτίας του starvation