02. stappenplan troubleshooting ms sql

an (web) application  has become unresponsive , the support guys suspect the database server faullty, how would you check ?

1) db is accessible  / qry can be exececuted / login is valid /
2) locking &  blocking  / resources ( mem / cpu )
3) connection from web server to sql server

=======================================================

probleem : EPD is niet beschikbaar of zeer traag / slecht werkbaar

I. niet zomaar aannemen dat de oorzaak (enkel) bij ms sql server en/of de database ligt. Netwerk , storage, ev. middleware kunnen ook een rol spelen of de oorzaak zijn. Naargelang van de gebruikte architectuur kunnen de applicatieserver of webserver , cloud toegang , security problemen , een rol spelen

II.
a) met aanname dat er monitoring tools opgezet zijn :
een vlugge check status van de ms sql server(s) :
- up & running & accessable
- cpu / comitted ram / network load / io activity
- alerts
( indien niet : dm_os_performance_counters, natuurlijk als de sql
b) always on cluster : cluster status , syncronizatie status nagaan
(
c) mijn ervaring is dat een goed deel van specifieke ms sql server problemen te wijten zijn aan uit de hand gelopen locking/ blocking en ook run away query plans, normaal bekijk ik dat eerst , daarna de rest
d) soms kan gewoon een extra index de perfromance weer redelijk maken, dat isdan meestal doordat een release gebeurde of nieuwe data structuren gemaakt werden, waardoor de sql een ander plan gaat maken.

III. blocking
1. de hoofd blocker nagaan ; er kan een ketting(reactie) zijn van een spid die een spid blokkeert die op z’n beurt een volgende blokkeert, etc
met exec sp_block , maar indien mogelijk met sp_whoisacive (er is ook een standaard report voorin SSMS, gebruik ik zelden)
2. nagaan of dat die blocker veilig gekilled mag worden (bv in het geval van een orphaned sessie)
3. deadlocks worden normaal vanzelf afgehandeld , als er veel deadlocks zijn, moet de code herwerkt (volgorde van data access en
4. met blocking query van Glenn Bery kan je nagaan op welke tables/ indexes de meeste lock waits liggen , dat geeft vaak aan waar je moet zoeken
5. het kan nodig zijn om dieper te moeten zoeken => extended event trace opzetten

IV. query plans
meestal hoge cpu of IO activity
de schuldige query zoeken met activity monitor of met speciale query op dm_os_schedulers & joinen naar sys.dm_sessions
hopelijk staat ook de sql query plan cache aan, uitstekend voor een meer historische onderzoek
als je de query hebt, het eraan verbonden plan uit de query cache halen
vaak kan je in het plan de oorzaak achterhalen (missing index , table scan ipv. enkel lookups, etc )
dat kan je dan gaan (tijdelijk) fixen , waardor je tijd hebt om het grondig te bekijken

V. de wait stats bekijken
kunnen bijvb.een tempdb bottlenek aangeven, en andere oorzaken die je dan in detail kan gaan bekijken

VI. indexes & statistieken
de gekende monitring queries gebuiken om een lijst met missing indexes , slechte performance queries , indexes met meeste impact bekijken

VII. overige
als bijvb. de sql log volgelopen is (gebrek aan disk ruimte) dan is de database niet beschikbaar
met AO syncronizatie (of problemen) is dat een pak sneller mogelijk

Dit is een vrij beperkte aanpak van performantie problemen, er komt veel meer bij ms sql server performantie te kijken, maar een goede start om mee te beginnen bij dringendheid.