Μέσα στα τόσα νέα features που υπάρχουν στον SQL Server 2012 κάποια είναι δημοφιλέστερα από κάποια άλλα. Κάποια τραβάνε εύκολα την προσοχή γιατί πουλάνε περισσότερο κάποια άλλα όχι. Για τα πρώτα θα βρείτε αρκετά άρθρα στον ιστό. Για τα δεύτερα, αυτά που δεν φαίνονται με γυμνό μάτι θα βρείτε λίγα ή καθόλου. Αυτά τα δεύτερα όμως είναι αυτά που κάνουν την ουσιαστική διαφορά και είναι η πεμπτουσία, πάντα κατά την ταπεινή μου γνώμη, στον SQL Server.
Ένα από αυτά που μου τράβηξαν από την αρχή την προσοχή ήταν τα Indirect Checkpoints.
Αρκετές φορές μέχρι τώρα έχω γράψει για την διαδικασία του CHECKPOINT. Θα θυμίσω απλά ότι η συγκεκριμένη διαδικασία έρχεται και γράφει τις αλλαγμένες σελίδες (dirty pages) που υπάρχουν στην μνήμη (buffer cache) στον δίσκο.
Μέχρι τώρα στον SQL Server είχαμε τα automatic checkpoints, τα manual checkpoints και τα internal checkpoints.
Ένα automatic checkpoint γίνεται κάθε φορά που ο αριθμός των log records φτάνει στον αριθμό αυτό που το Database Engine έχει εκτιμήσει ότι μπορεί να επεξεργαστεί στον χρόνο που έχει ορισθεί στο Recovery Interval property του SQL Server. Περισσότερα για αυτό μπορείτε να δείτε σε παλιότερο post.
Ένα manual checkpoint γίνεται όταν απλά στην συγκεκριμένη database εκτελέσουμε την εντολή CHECKPOINT.
Ένα internal checkpoint γίνεται όταν εκτελούνται εργασίες όπως database backup, database snapshot, προσθέτουμε ή αφαιρούμε αρχεία από μια βάση, εάν έχουμε ορίσει στην βάση το AUTO_CLOSE property ON και στη συγκεκριμένη βάση δεν υπάρχει ενεργό connection, εάν είμαστε σε failover cluster instance και αυτό το γίνεται offline ή τέλος όταν σταματάμε στο service του SQL Server.
Τι ήταν όμως αυτό που οδήγησε το SQL Server PG να δημιουργήσει το νέο αυτό τρόπο για τα checkpoints;
To recovery interval property σε ένα OLTP σύστημα με σύντομα σε διάρκεια transactions λειτουργεί εξαιρετικά. Όμως το property αυτό δεν έχει καμία απολύτως επίδραση στο χρόνο που χρειάζεται για να γίνει η φάση UNDO σε μεγάλα σε χρόνο transactions. Τι σημαίνει πρακτικά αυτό;
Έστω ότι έχω ένα transaction το οποίο κάνει κάποια updates και έχουν περάσει δύο ώρες που εκτελείται όταν για οποιοδήποτε αιτία πέφτει ο SQL Server. Ο χρόνος που θα χρειαστεί για να γίνει η φάση RECOVERY για το συγκεκριμένο transaction θα είναι αρκετά μεγαλύτερος από τον χρόνο που έχει ορισθεί στο recovery interval property. Επίσης θα πρέπει να επισημανθεί ότι το συγκεκριμένο property είναι σε επίπεδο server και οποιαδήποτε αλλαγή σε αυτό έχει σαν αποτέλεσμα να επηρεάσει όλες τις βάσεις που υπάρχουν στον server αυτό, και όπως είναι εύκολα κατανοητό, όλες οι βάσεις δεν έχουν την ίδια απαίτηση.
Για το λόγο αυτό στον SQL Server 2012 εμφανίστηκε το indirect checkpoint. Τι όμως κάνει αυτό;
Καταρχήν μου δίνει την δυνατότητα να ορίσω σε επίπεδο database το recovery interval. Από εκεί και πέρα ένα background thread συνεχόμενα κοιτάζει για dirty page με τρόπο που είναι aggressive σε σχέση με τα automatic checkpoints.
Με αυτό τον τρόπο κερδίζω καθώς έχω:
- Σημαντική μείωση του χρόνου που χρειάζεται για το recovery μιας βάσης.
- Έλεγχο του χρόνου recovery μιας βάσης
- Μείωση των σχετικών με checkpoints Ι/Ο καθώς γράφονται συνεχώς οι dirty pages στο δίσκο με background εργασία.
Όμως όλα αυτά έχουν και συνέπειες. Η βασική είναι ότι σε ένα OLTP σύστημα θα πρέπει να κάνω εκτεταμένο τεστ για το αν μου χρειάζονται τα indirect checkpoints καθώς όπως ειπώθηκε και παραπάνω υπάρχει συνεχόμενο γράψιμο των dirty pages στο δίσκο και αυτό θα πρέπει να μετρηθεί γιατί μπορεί να οδηγηθούμε σε performance πέναλτι. Παρόλα αυτά όμως είναι ένα αρκετά δυνατό χαρακτηριστικό.
Πως όμως το ορίζω;
Αυτό μπορώ να το κάνω είτε μέσα από το SSMS στα Properties της database
Είτε με T-SQL
USE [master]
GO
ALTER DATABASE [AdventureWorks2012RC0]
SET TARGET_RECOVERY_TIME = 90 SECONDS
WITH NO_WAIT
GO
/*antonch*/