Στην καθημερινότητα μας όλοι ερχόμαστε, κάποια στιγμή, αντιμέτωποι με προβλήματα που αφορούν την απόδοση του SQL Server. Έχω δεχθεί κατά καιρούς ερωτήματα από πολλούς που αφορούσαν τέτοια θέματα. Μέχρι σήμερα, αν και το έχω αναφέρει αρκετές φορές, δεν είχα γράψει κάτι σχετικά με το πως θα φτάσουμε στην αιτία που μας δημιουργεί το εκάστοτε πρόβλημα απόδοσης, πότε όμως δεν είναι αργά.

Αφορμή στάθηκε ένα γεγονός την προηγούμενη εβδομάδα με ένα θέμα καθυστέρησης σε έναν SQL Server 2008 R2 που ένας φίλος και συνάδελφος αντιμετώπιζε και το οποίο λύθηκε. Παρατηρώντας ο συνάδελφος την διαδικασία που ακολούθησα για να εντοπίσω την αιτία ώστε να δω τι είναι αυτό που προκαλεί την καθυστέρηση μου έκανε την παρατήρηση ότι δεν έχω γράψει κάτι σχετικά με αυτή την διαδικασία. Όταν μάλιστα του είπα ότι η αιτία της καθυστέρησης του είναι κάτι το οποίο το έχω δει αρκετές φορές και είναι κάτι το οποίο δείχνει ότι απλά στήθηκε ο SQL Server από έναν που απλά ήξερε να βάζει το cd και να πατάει next γέλασε.

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

Πριν ξεκινήσω να γράφω για την διαδικασία αυτή θα ήθελα να συγκεντρώσω κάποια στοιχεία που αφορούν την απόδοση που έχουν οι διάφοροι SQL Servers από 2005 και πάνω που είναι στην παραγωγή στην Ελλάδα, στη Κύπρο ή στο εξωτερικό (αρκεί κάποιος να ξέρει να διαβάζει ελληνικά). Σκοπός μου είναι αναλύσω τις αιτίες αυτές και να αποδείξω ότι με μερικές κινήσεις από την αρχή της εγκατάστασης μπορούν να βοηθήσουν μέγιστα στην απόδοση του SQL Server.

Με την ευκαιρία αυτή θα μάθουμε ότι το πρώτο πράγμα που πρέπει να κάνουμε όταν αντιμετωπίζουμε πρόβλημα απόδοσης είναι κοιτάμε τα wait statistics γιατί; Πολύ απλά ο SQL Server όταν κάπου έχει μια καθυστέρηση καταγράφει αυτή. Αναλύοντας αυτές τις καταγραφές μπορούμε να ξεκινήσουμε το ξετύλιγμα του κουβαριού στην άκρη του οποίου θα βρούμε την αιτία ή τις αιτίες.

Όπως έχω αναφέρει πολλές φορές στο παρελθόν τόσο μέσα από το SQLschool.gr όσο και στα μαθήματα που κάνω από την έκδοση του SQL Server 2005 έχουμε τα DMVs. Ένα από αυτά είναι και το sys.dm_os_wait_stats. Από εκεί ξεκινάμε για να λύσουμε το κουβάρι. Απλά πρέπει να γνωρίζουμε ότι αυτά μηδενίζονται κάθε φορά που γίνεται restart o SQL Server. Αν λοιπόν κάποιος έχει πρόβλημα και το πρώτο πράγμα που κάνει είναι να κάνει restart δυστυχώς δεν μπορέσουμε να βρούμε την αιτία καθώς αν αμέσως μετά ρωτήσουμε για τα στατιστικά θα είναι σχεδόν όλα μηδέν.

Τι θα ήθελα από εσάς. Όσοι θέλουν μπορούν με τo παρακάτω query να μου στείλουν σε ένα excel τα στοιχεία που αυτό θα τους επιστρέψει μαζί με την επισήμανση ποια είναι η έκδοση του SQL Server που έχουν το οποίο μπορείτε να το αντλήσετε με ένα απλό SELECT @@VERSION θα ήμουν ευγνώμων.

Όπως θα δείτε τα στοιχεία δεν περιέχουν ευαίσθητα δεδομένα, οπότε δεν νομίζω ότι θα έχετε κάποιο πρόβλημα. Το αρχείο αυτό μπορείτε να το στείλετε στο help του sqlschool.gr.

Θα περιμένω μερικές μέρες ώστε να συγκεντρωθεί ένας αξιόλογος όγκος ποιοτικών δεδομένων (μην μου στείλετε δεδομένα από μην παραγωγικά περιβάλλοντα δεν θα συμπεριληφθούν και πιστέψτε με μπορώ να τα ξεχωρίζω) ώστε να τα αναλύσω και να ξεκινήσω να περιγράφω την διαδικασία.
Όσοι θέλουν να συμμετάσχουν σε αυτό είναι ευπρόσδεκτοι.

Παρακάτω είναι το query το οποίο θα πρέπει να τρέξετε. Σε αυτό δεν έχω συμπεριλάβει κάποια wait stats που είναι συστεμικά και δεν αφορούν θέματα απόδοσης

select * from sys.dm_os_wait_stats
where wait_type NOT IN ('CLR_SEMAPHORE','LAZYWRITER_SLEEP','RESOURCE_QUEUE','SLEEP_TASK'
,'SLEEP_SYSTEMTASK','SQLTRACE_BUFFER_FLUSH','WAITFOR', 'LOGMGR_QUEUE','CHECKPOINT_QUEUE'
,'REQUEST_FOR_DEADLOCK_SEARCH','XE_TIMER_EVENT','BROKER_TO_FLUSH','BROKER_TASK_STOP','CLR_MANUAL_EVENT'
,'CLR_AUTO_EVENT','DISPATCHER_QUEUE_SEMAPHORE', 'FT_IFTS_SCHEDULER_IDLE_WAIT'
,'XE_DISPATCHER_WAIT', 'XE_DISPATCHER_JOIN', 'SQLTRACE_INCREMENTAL_FLUSH_SLEEP') OPTION (RECOMPILE)