7. Mai 2015 13:17
Hallo an alle,
jetzt, da 2013 R2 und 2015 mittlerweile zum Alltag gehören eine Frage von mir an alle:
Wer kann mit sagen, wie ich im Falle von Sperrverhalten auf dem SQL-Server herausbekomme, wer der Schuldige ist?
HintergrundZum Thema Debug und SQL-Profiler ist viel interessantes und wissenswertes geschrieben und gefilmt worden. Aber alles Geschriebene und Gefilmte trifft m. E. nicht so ganz des Pudels Kern. Zwar bilden die Werkzeuge, vom Debugging über SQL-Profiler bis hin zum EVENT-Tracing alles, was das Herz begehrt, allerdings immer nur dann, wenn bekannte Szenarien nachgestellt werden müssen/können.
Immer dann, wenn es zu akuten Problemen beim Kunden kommt, läuft ein Großteil der beschriebenen Vorgehensweisen ins Leere, da das Kind ja bereits in den Brunnen gefallen ist.
Beispiel:Ich hatte unlängst eine Situation beim Kunden, in der der SQL-Server gegen die virtuelle Performance-Wand fuhr, und zwar so, dass selbst der Aufruf des Aktivitätenmonitors vom Server nicht mehr zu bewerkstelligen war. Zwar konnten die Spids , welche sperrten und blockiert waren über Scripts identifiziert werden, aber was bringst, wenn man daraus nur maximal die jeweilige Instanz herauslesen kann und nicht den BAD-Boy (oder BAD-Girl), der die Sperren verursacht hat oder verursacht.
Hier schlägt die Delegierung zu, die ja den eigentlichen Benutzer auf dem SQL-Server verbirgt bzw. dem Kammeraden gar nicht sagt, wer da gerade was von ihm will. Ist ja auch in Ordnung und so gewollt. Nur für die Diagnostik beim akuten Auftreten eines "Störfalls" nicht gut.
Was nun ?Wie gesagt; ich will wissen, welcher tatsächliche Benutzer hinter einer sperrenden oder blockierten SPID steckt. Soweit ich aus dem Profiler entnehmen kann, fordert das Tier vor jeder SQL-Anforderung eines Clients mit "Get Connection from Pool" (oder so ähnlich) eine SPID von SQL-Server an und arbeitet unter dieser SPID die gewünschten Anforderungen ab. Das kann man im Protokoll auch wunderschön nachlesen. Aber wer schaltet schon im vorauseilendem Gehorsam den Debugger und den Profiler genau dann ein, wenn 5 Sekunden später ein Problem auftritt? Keiner; natürlich!
Also die spannenden Frage:
Wer von unseren Schichten weiß, welcher Session ID NAV welche Spid aus dem SQL-Server gerade zugeordnet ist bzw. zuletzt war und kann man diese Information irgendwie nach oben bringen ?
In den Tabellen und Sichten des SQL-Servers habe ich nichts gefunden, was mich wirklich weiterbringt. Keine geheimen Views, keine geheime Tabellen nichts, keine zusätzlichen Informationen (man könnte ja mit SET Context Info ja mal was in das Feld der Sicht sys.dm_exec_sessions schreiben, aber neee, is nicht).
Ich habe auch mal sicherheitshalber ind den CMDLET's geguckt, aber leider auch nichts.
Aber vielleicht weiß ja einer von euch was oder kann sachdienliche Informationen zu diesem Thema liefern.
Ziel wäre es, aus einer Session-ID NAV die aktuellen oder zuletzt benutzten Spids des SQL-Servers ableiten zu können oder eben auch umgekehrt.
beste Grüße Micha
Zuletzt geändert von Fido am 7. Mai 2015 14:55, insgesamt 1-mal geändert.