Overview
Η καθημερινότητα ενός DBA μόνο απλή δεν είναι, αν και πολλοί πιστεύουν αυτό.
Καθημερινά πρέπει να φροντίζει ώστε τα instance/databases του να είναι σε εύρυθμη λειτουργία. Για να το πετύχει αυτό παρακολουθεί αυτά στενά ώστε να ενεργεί προληπτικά/προδραστικά στις διάφορες καταστάσεις.
Παράλληλα έχει να φροντίσει για την εξέλιξη όλων αυτών ώστε ο οργανισμός να είναι σε θέση να ακολουθήσει τα κελεύσματα των καιρών μιας και όλοι πλέον μιλάνε για την 4η Βιομηχανική επανάσταση.
Αν λοιπόν βλέπετε ένα DBA να κοιτάζει μια οθόνη με νούμερα ή γραφήματα ή να διαβάζει το sqlschool.gr να είστε σίγουροι ότι είναι αρκετά απασχολημένος και ίσως προβληματισμένος για αυτό να μην τον απασχολείται με θέματα άλλα, το καλύτερο που έχετε να κάνετε είναι να του δώσετε ένα καφέ και πολύ νερό. Πιστέψτε με θα καταλάβετε πότε θα είναι έτοιμος να σας ακούσει.
The sys.dm_os_performance_counters DMV
Πολυαγαπημένε μου DBA,
Ξέροντας ότι καθημερινά προσπαθείς σκληρά να κρατήσεις σφικτά τα γκέμια από το θηρίο για να μην βγει από το σωστό δρόμο σε παρακαλώ διάβασε προσεκτικά το συγκεκριμένο άρθρο καθώς έχει να σου προσφέρει αρκετά στην καθημερινότητα σου.
Ένα από τα βασικά εργαλεία που έχεις στην διάθεση σου είναι τα performance counters που έχει ο SQL Server και τα οποία σου δείχνουν πολλά και ενδιαφέροντα πράγματα. Συνήθως για να δεις αυτά χρησιμοποιείς το performance monitor tool των windows.
Φαντάζομαι ότι γνωρίζεις ότι δεν είναι απαραίτητο να χρησιμοποιείς αυτό καθώς εδώ και πολλά χρόνια από την έκδοση του SQL Server 2008 (αν δεν με απατάει η μνήμη μου) υπάρχει ένα αρκετά χρήσιμο DMV το οποίο σου προσφέρει αυτή την πληροφορία εύκολα μέσα από την εκτέλεση ενός απλού query, και αυτό είναι το sys.dm_os_performance_counters.
Τι δεν έχει αυτό; Δεν σου επιστρέφει τα σχετικά με το OS performance counters όπως processor usage, disk activity κ.α. Ναι θέλουμε να τα είχαμε αλλά αυτό δεν σημαίνει ότι επειδή δεν τα έχουμε τώρα δεν θα χρησιμοποιήσουμε αυτό το καλό DMV. Δυστυχώς αυτό είναι το μεγαλύτερο λάθος που όλοι οι DBA κάνουν και μου θυμίζει την ιστορία που κάποιος ήθελε ένα άλογο για μεταφέρει τα ξύλα για το τζάκι του αλλά δεν είχε και κάποια στιγμή κάποιος του χάρισε ένα γάιδαρο και τον κοίταζε στα δόντια για να δει αν είναι γερά.
To συγκεκριμένo DMV εκτελείται εύκολα όπως παρακάτω
select * from sys.dm_os_performance_counters
Επιστρέφει 1663 rows / 46 counter categories / 592 counters (ανάλογα με την έκδοση του SQL Server ίσως φέρει και λιγότερα ή περισσότερα, τα νούμερα αυτά είναι από SQL Server 2017).
Σημείωση
Εάν το παρακάτω query επιστέψει μηδέν σημαίνει ότι οι performance counters έχουν απενεργοποιηθεί
select count(*) from sys.dm_os_performance_counters
Τα αποτελέσματα αποτελούνται από 5 columns οι οποίες είναι οι παρακάτω
οbject_name
Η κατηγορία που ο συγκεκριμένος counter ανήκει
counter_name
Το όνομα του counter
instance_name
To counter instance name, σε κάποιους είναι το instance σε άλλους το database name ή _Τotal και υποδεικνύει το σημείο αναφοράς του
cntr_value
Είναι η τρέχουσα τιμή του counter κατά την εκτέλεση του query. Ανάλογα με τον τον counter αυτή μπορεί να είναι cumulative όπως πχ για τους counters που είναι ανά second.
cntr_type
Η τιμή σε αυτή την κολώνα είναι η σημαντικότερη που πρέπει να γνωρίζει ένας DBA καθώς από αυτή θα καταλάβει το πως θα ερμηνεύσει την τιμή που διαβάζει στην προηγούμενη κολώνα.
Σε όλες τις εκδόσεις μέχρι τώρα στην κολώνα αυτή υπάρχουν 6 διακριτές τιμές που στην ουσία ορίζουν τον τύπο του counter όπως αυτός ορίζεται στο Windows performance architecture
Οι τιμές αυτές μαζί με τη ονομασία τους και την χρήση τους είναι οι παρακάτω:
65792 - PERF_COUNTER_LARGE_RAWCOUNT
Οι counters αυτοί επιστρέφουν την τελευταία παρατήρηση της τιμής και είναι decimal data type. Δεν είναι μέσος όρος. Συνήθως χρησιμοποιείται για count monitoring πχ
Στο object_name SQLServer:General Statistics και ο counter User Connections δείχνει στο lab μου τη στιγμή της εκτέλεσης τον αριθμό 4 που σημαίνει 4 χρήστες είναι αυτή την στιγμή συνδεδεμένοι στο instance
ή
Στο object_name SQLServer:Buffer Manager και ο counter Database Pages δείχνει στο lab μου τη στιγμή της εκτέλεσης τον αριθμό 4965 που σημαίνει 4965 page είναι αυτή την στιγμή στην Buffer pool
272696320 - PERF_COUNTER_COUNTER
Οι counters αυτοί επιστρέφουν το ΜΟ των διαδικασιών που υποδεικνύει ο κάθε ένας από αυτούς ανά δευτερόλεπτο και είναι decimal data type.
Συνήθως χρησιμοποιούνται για count monitoring πχ.
Στο object_name SQL Server 2017 XTP Transactions και ο counter Transactions created/sec δείχνει στο lab μου τη στιγμή της εκτέλεσης τον αριθμό 466 που σημαίνει έχω κατά μ.ο. 466 in-memory Transactions / sec
272696576 - PERF_COUNTER_BULK_COUNT
Οι counters αυτοί επιστρέφουν πληροφορίες που είναι cumulative από την στιγμή που ξεκίνησε το instance και είναι decimal data type.
Αυτό σημαίνει ότι δεν θέλει προσοχή στο διάβασμα τους όταν αυτό γίνεται με την εκτέλεση του dmv αυτού και για να γίνω ξεκάθαρος ας πάρουμε ένα παράδειγμα
Aς επιλέξουμε από το object name το SQLServer:Databases και τον counter Transactions/sec για μια συγκεκριμένη database (Τ για το παραδειγμα μου) που είναι στο instance name. Σε αυτό θα προσθέσουμε και το ms_ticks field από ένα ακόμα dmv το sys.dm_os_sys_info το οποίο δείχνει σε milliseconds το χρόνο που ο server είναι ξεκινημένος. Το query αυτό είναι όπως το παρακάτω.
select i.ms_ticks, c.*
from sys.dm_os_performance_counters as c
cross join sys.dm_os_sys_info as i
where c.object_name='SQLServer:Databases' and c.counter_name='Transactions/sec' and c.instance_name='T'
Εκτελώντας το query αυτό θα μου δείξει μια τιμή Α.
Η τιμή αυτή είναι ο αριθμός των transactions/sec συνολικά από την στιγμή που ξεκίνησε το instance και όχι πόσα transactions έχω ανά δευτερόλεπτο.
Μπέρδεμα ε; Να το κάνω ακόμα χειρότερο ;
Όταν χρησιμοποιείς το performance monitor για να δεις το συγκεκριμένο counter δείχνει σωστά αυτό που λέει. Άρα εύκολα θα πει κάποιος ότι υπάρχει bug, αλλά δεν υπάρχει κανένα, απλά το performance monitor κάνει αυτό που θα περιγράψω παρακάτω.
'Εστω ότι την χρονική στιγμή Τ1 εκτελώ το παραπάνω query και έχω την τιμή Α για το cntr_value και την τιμή Α' για την τιμή ms_ticks
Tην χρονική στιγμή Τ2 εκτελώ το παραπάνω query και έχω την τιμή B για το cntr_value και την τιμή B' για την τιμή ms_ticks
Άρα η τιμή των Τransactions/sec για το διάστημα Τ1-Τ2 είναι ίση με (Α-Β)/((Α'-Β')/1000)
1073939712 - PERF_LARGE_RAW_BASE
Οι τιμές στους counter αυτούς είναι ακατέργαστα δεδομένα που χρησιμοποιούνται ως παρονομαστής ενός counter που απεικονίζει ένα στιγμιαίο αριθμητικό κλάσμα. Συνδυάζονται με τους PERF_LARGE_RAW_FRACTION που ακολουθούν.
537003264 - PERF_LARGE_RAW_FRACTION
Οι counters αυτοί είναι κλασματικές τιμές αναλογίας του αντίστοιχου PERF_LARGE_RAW_BASE.
Επειδή καταλαβαίνω την σύγχυση που έχει δημιουργηθεί ας το εξηγήσω με ένα παράδειγμα
Στο counter object SQLServer:Buffer Manager έχω τους counter Buffer cache hit ratio που είναι PERF_LARGE_RAW_FRACTION και Buffer cache hit ratio base που είναι PERF_LARGE_RAW_BASE
Για να βρω το Hit ratio % = (100 * Buffer cache hit ratio) / Buffer cache hit ratio base
1073874176 - PERF_AVERAGE_BULK
Οι counters αυτοί είναι cumulative και απεικονίζουν ένα M.O. Αυτό σημαίνει ότι για να πάρουμε την πραγματική τιμή του counter θα πρέπει να δούμε εκτός από την τιμή αυτή και την τιμή του αντίστοιχου PERF_LARGE_RAW_BASE counter και να κάνουμε τις πράξεις αφού πρώτα έχουμε τα δεδομένα δύο διαδοχικών τιμών πχ
Αν εκτελέσουμε το συγκεκριμένο query θα πάρουμε τα ζευγάρια που μας ενδιαφέρουν
select *
from sys.dm_os_performance_counters
where cntr_type in (1073939712,1073874176)
order by 3,2
Για παράδειγμα το πρώτο ζευγάρι που αυτό το query επιστρέφει είναι το SQLServer:Latches-Average Latch Wait Time (ms) και SQLServer:Latches-Average Latch Wait Time base, PERF_AVERAGE_BULK & PERF_LARGE_RAW_BASE counter types αντίστοιχα.
Ας κρατήσουμε τις τιμές των δύο αυτών μετρητών σαν Α για τον πρώτο και Β για τον δεύτερο και ας εκτελέσουμε ξανά το ίδιο και να καταγράψουμε τις νέες τιμές σαν Α' και Β' αντίστοιχα.
Για να υπολογίσουμε το Average Latch Wait time (ms) μεταξύ των δύο αυτών διαδοχικών χρονικών στιγμών εφαρμόζουμε τον τύπο (Α'-Α) / (Β'-Β)
Conclusion
Δεν είναι δύσκολο να κάνεις όλα αυτά αγαπητέ DBA απλά θέλει λίγο προπόνηση και όρεξη
//antonch