Πριν από καιρό είχα κάνει το SQL Saturday Night #15 στο οποίο είχα ασχοληθεί με τα Virtual Log Files (VLFs) του transaction log μιας database.

Πάρα πολλοί είδαν το συγκεκριμένο SQL Saturday Night και αρκετοί είχαν απορίες που μου απέστειλαν είτε μέσω τις φόρμας επικοινωνίας του SqlSchool.gr είτε μέσω email στην ηλεκτρονική διεύθυνση [help at sqlschool dot gr].

Όλες οι ερωτήσεις απαντήθηκαν αλλά δεν δημοσιοποιήθηκαν καθώς είχαμε μπροστά μας τη διοργάνωση του IT PRO | DEV CONNECTIONS 2012.

Αφού πλέον ηρεμήσαμε είναι νομίζω η στιγμή να δημοσιευθούν οι σημαντικότερες ερωτήσεις από αυτές που υποβλήθηκαν και οι απαντήσεις που πήραν.

Ας ξεκινήσουμε με μερικές από αυτές σε αυτό το post και αργότερα θα συνεχίσουμε με άλλες.

Q1: Αναφέρθηκε στο SQL Saturday Night ότι θα πρέπει να έχουμε κάτω από 1000 VLFs σε ένα transaction log. Αυτό είναι κανόνας;

Α1: Στον SQL Server όπως και στην ζωή υπάρχουν κανόνες που έχουν όμως και εξαιρέσεις. Αν έχω πάρα πολύ μεγάλο transaction log file, και δεν εννοώ μεγάλο κάτι που είναι μικρότερο από 10GB,  είναι αρκετά πιθανό να έχω περισσότερα από 1000 VLFs. Φυσικά δεν πρέπει να ξεχνάμε, ακόμα και σε αυτή την περίπτωση, ότι σημαντικό ρόλο παίζει το πώς έχω αρχικά δημιουργήσει το transaction log file και ακόμα ποιο σημαντικό ρόλο παίζει το πώς μεγαλώνω αυτό σε μέγεθος είτε ορίζοντας το autogrowth είτε κάνοντας την διαδικασία χειροκίνητα.

Q2: Αν έχω πολλά VLFs τι προβλήματα μπορεί να έχω;

Α2: Αν και έχει απαντηθεί στο SQL Saturday Night θα το επαναλάβω ακόμα μια φορά. Τα πολλά VLFs επηρεάζουν την απόδοση της database όταν σε αυτή υπάρχουν ενεργοποιημένες διαδικασίες όπως replication, database mirroring, availability groups (SQL Server 2012), log shipping κ.α. Αυτό όμως που ίσως δεν έγινε σαφές είναι ότι τα πολλά VLFs οδηγούν μαθηματικά στο φαινόμενο που ονομάζουμε VLF Fragmentation (θα σας εξηγήσω περισσότερα για αυτό και πως το λύνουμε σε άλλο post) το οποίο με την σειρά του έχει αρνητική επίδραση σε όλες τις δραστηριότητες που γίνονται στο transaction log πχ διαδικασία checkpoint, αλλά κυρίως έχει μεγάλη αρνητική επίδραση στην περίπτωση που χρειάζεται να γίνει κάποιο recovery της βάσης αυτής από κάποιο κρασάρισμα π.χ. πτώση ρεύματος.

Q3: Άρα καλό είναι να έχω όσο το δυνατόν λιγότερα VLFs σωστά;

Α3: Θα είμαι τελείως σαφής στην απάντηση μου σχετικά με την ερώτηση αυτή. Δηλώνω ευκρινώς ότι ούτε και τα λίγα είναι καλά καθώς είναι μεγάλα σε μέγεθος με αποτέλεσμα να μην γίνονται εύκολα ανενεργά και να γίνονται truncate όταν παίρνουμε transaction log backups. Φανταστείτε ότι φτιάχνουμε μια βάση και σε αυτή δημιουργούμε ένα transaction log που έχει μέγεθος 50GB. Σύμφωνα με την φόρμουλα που έχω δώσει στο SQL Saturday Night με την οποία ο SQL Server δημιουργεί τα VLFs θα φτιαχτούν 16 VLFs με μέγεθος το κάθε ένα περίπου 3,2GB. Αυτό σημαίνει ότι ένας μεγάλος όγκος δεδομένων ανά VLF θα πρέπει να γίνει inactive ώστε να μπορέσει αυτό το VLF να καθαριστεί (πάντα με transaction log backup εφόσον είμαστε σε Full ή Bulk recovery model) και να επαναχρησιμοποιηθεί στο κύκλο του transaction log.

Q4: Υπάρχει τελικά κάποιος κανόνας – μπούσουλας που θα μπορούσαμε να ακολουθήσουμε;

Α4: Δυστυχώς κάποιος τέτοιος κανόνας δεν υπάρχει. Αυτό όμως που έχει βρεθεί από την εμπειρία σε μεγάλα συστήματα και μέχρι τώρα κανείς δεν έχει βρει κάτι που να είναι καλύτερο από αυτό, είναι το γεγονός ότι VLFs με μέγεθος γύρω στο ½ του GB συμπεριφέρονται αρκετά καλά. Μάλιστα αυτό έχει βγει από έρευνα που έχει κάνει ο Paul Randal εκ των αρχιτεκτόνων του SQL Server. Αυτό που προτείνετε είναι όταν φτιάχνουμε μια νέα database να φροντίζουμε/υπολογίζουμε σύμφωνα με την φόρμουλα που σας έχω δώσει στο SQL Saturday Night να δημιουργούνται VLFs που να είναι στο ½ του GB. Στο παράδειγμα που ανέφερα παραπάνω θα πρέπει να φτιαχτεί αρχικά ένα transaction log με αρχικό μέγεθος δημιουργία 8GB αυτό θα φτιάξει 16 VLFs που θα είναι γύρω στο ½ του GB. Μετά με επαναλαμβανόμενα extensions (16,24,32,40,48GB) θα φτάσουμε στο αρχικά επιθυμητό μέγεθος που είναι τα 50GB έχοντας έτσι δημιουργήσει 96 VLFs που θα είναι κοντά στο ½ του GB. Με την ίδια λογική θα πρέπει να ορισθεί και το auto growth στο transaction log.

Σε επόμενο post θα συνεχίσω με το θέμα αυτό καθώς έχει πιστεύω αρκετά ενδιαφέρον. Μέχρι τότε να είστε όλοι καλά.

/*antonch*/