Σαν DBA καθημερινά ερχόμαστε αντιμέτωποι με κάποιες περιπτώσεις δεν είναι εύκολο άμεσα να εντοπιστούν τα αίτια που τις δημιούργησαν. Εδώ έρχεται αυτό που χρόνια λέω και γράφω ότι πρέπει να γνωρίζουμε τα εσωτερικά του εργαλείου.
Πρόσφατα δέχθηκα μια ερώτηση από έναν συνάδελφο που απετέλεσε το ερέθισμα για το post αυτό.
Ο συγκεκριμένος συνάδελφος αντιμετώπισε ένα πρόβλημα με την απόδοση ενός query που ενώ δούλευε μια χαρά ξαφνικά άρχισε να εμφανίζει μεγάλο χρόνο εκτέλεσης. Το συγκεκριμένο query διάβαζε πραγματικά μεγάλο όγκο εγγραφών και η αρχική έρευνα έδειξε ότι τα στατιστικά ενός από τους πίνακες που εμπλέκονταν σε αυτό ήταν outdated.
Μετά από την ενημέρωση αυτών το συγκεκριμένο query επανήλθε στον φυσιολογικό ,για το μέγεθος των δεδομένων και των διαθέσιμων πόρων, χρόνο του. Εύλογη ήταν λοιπόν η απορία του συναδέλφου γιατί δεν είχαν ενημερωθεί αυτόματα τα στατιστικά του πίνακα καθώς είχε ενεργοποιημένο, και σωστά το είχε, το auto update statistics.
Για όσους δεν το γνωρίζουν πρέπει να αναφέρω ότι στον SQL Server υπάρχει ένας "κανόνας" για το πότε θα ενημερώνονται τα στατιστικά και αυτός δε είναι άλλος από τον "κανόνα" του 20%+500 rows. Τι σημαίνει αυτό;
Σημαίνει ότι αν υπάρχουν αλλαγές τέτοιες στον πίνακα που να είναι αθροιστικά πάνω από το 20%+500 εγγραφές του συνόλου των εγγραφών στον πίνακα τα στατιστικά χαρακτηρίζονται σαν outdated και ο query optimizer όταν θα τα ζητήσει θα βγάλει άλλο execution plan από αυτό που θα έβγαζε αν ήταν ενημερωμένα.
Αν έχω για παράδειγμα ένα πίνακα με 10000 εγγραφές αυτός ο "κανόνας" είναι στην ουσία 2500 εγγραφές που έχουν αλλάξει σε αυτό. Αντίστοιχα αν έχω 100000 εγγραφές πάμε στις 25000 και να έχω 1000000 εγγραφές πάμε στις 250000 εγγραφές.
Ο "κανόνας" αυτός στις περισσότερες περιπτώσεις δουλεύει, υπάρχει όμως ένα θέμα όταν έχω αρκετά μεγάλους πίνακες καθώς η στιγμή που θα ενημερωθούν αυτά αργεί να έρθει επειδή το 20%+500 threshold δεν έχει "πιαστεί". Αυτό είναι ένα γνωστό θέμα και αποτελεί εφιάλτη των απανταχού DBAs για αυτό και πάντα λέω και έχω γράψει ότι πάντα κάνουμε σε τακτά χρονικά διαστήματα update statistics.
Επειδή όμως αυτή η διαδικασία δεν μπορεί να τρέχει συνέχεια καθώς έχει Ι/Ο από τον SQL Server 2008 R2 SP1 έχουμε ένα φάρμακο αρκετά δραστικό, και μάλιστα δεν βλέπω και τον λόγο γιατί να μην χρησιμοποιείτε πάντα.
Αυτό δεν είναι άλλο από το να ξεκινήσουμε τον SQL Server instance με το trace flag 2371. To οποίο αλλάζει την συμπεριφορά του κανόνα του 20%+500 rows σε δυναμικό threshold το οποίο βασίζεται στον αριθμό των γραμμών του πίνακα. Με αυτό σε μεγάλους σε αριθμό εγγραφών πίνακες έχω μικρότερο threshold με αποτέλεσμα σε αυτούς να έχω συχνότερη ενημέρωση των στατιστικών.
Ιδανικές περιπτώσεις για την ενεργοποίηση του trace flag αυτού είναι ERP όπως το SAP, Dynamic AX ή databases που αντιμετωπίζουν συχνά το σενάριο που παραπάνω περιεγράφηκε.
Keep Rocking with SQL Server
/*antonch*/