go backarticles

Articles of SQLschool.gr Team

Πριν από καιρό είχα κάνει το 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*/


 


Antonios Chatzipavlis

Antonios Chatzipavlis

Antonios is a Data Solutions Consultant and Trainer. He has been working in IT since 1988. In his career, he has worked as senior developer, IT Manager, Solutions Architect and IT Consultant. Since 1995 he has been devoted on new technologies and software development tools, mainly by Microsoft, either by training company staff and colleagues or assisting them in design, development and implementation as a consultant or chief developer. He has focused in Databases and Data Science since 1995. He specialized in Microsoft SQL Server since version 6.0 in areas like SQL Server Internals, Database Design and Development, Business Intelligence and in 2010 he has started working with Azure Data Platform, NoSQL databases, Big Data Technologies and Machine Learning. He is an active member of many IT communities in Greece, answering colleagues' questions and writing articles in his web site. He is the owner of SQLschool.gr which is a community portal with a lot of information about Microsoft SQL Server. He has been a Microsoft Certified Trainer (MCT) since 2000. Microsoft honored him as MVP on Data Platform due to his activities in SQL Server since 2010. He holds a large number of Microsoft Certifications and Microsoft SQL Server Certifications since version 6.5.


Leave your comment

COMMENT

FULL NAME

EMAIL ADDRESS

We use Gravatar

WEB SITE



captcha


 

Newsletter

If you want to receive updates from us subscribe below with your email.
Follow us in
PASS chapter logo

The Official PASS Local Group for Greece

About us Contact us Terms of Use Privacy Sing in Register
sql school greece logo
© 2010-2020 All rights reserved

This site uses cookies for operational and analytics purposes only. By continuing to browse this site, you agree to their use.