Bestellung im Systemmonitor mitverfolgen
Jeder hat schon mal den Systemmonitor in der Hand gehabt, um festzustellen wo es gerade zickt.
Komischerweise eigtl immer erst dann, wenn es brennt. Andererseits wärs doch auch ganz interessant nicht nur die vordefinierten Leistungsindikatoren wie Speicher, CPU etc mitzuverfolgen, sonedrn Dinge die tatsächlich auf der Datenbank passieren.
Ich würde gern anhand von einer Kurve wissen, wie stark mein Umsatz wächst, d.h wann werden wieviele Produkte gekaut. Nichts leichter als das. Der SQL Server installiert 10 benutzerdefinierbare Leistungsindikatoren.
Sie alle werden mit einer Stored procedure gestartet:
sp_user_counter1 (bis) sp_user_counter10 |
Als Übergabeparameter wird ein int-Datentyp verlangt. Also meinetwegen so:
use northwind declare @umsatz int select @umsatz = count(*) from orders exec sp_user_counter2 @umsatz
|
Als Ergebnis kann man sehr schön den Verlauf der Bestellung mitverfolgen. Aus Performancegründen würde ich allerdings darauf verzichten einen Trigger einzubauen, der jedesmal bei einem Insert diese Counter aktiviert. Ich könnte mir da schon eher eine Job vorstellen der per Termin immer wieder mal gestartet wird.
Uuupps.. was ist denn bei mir los!
Nicht selten, oder besser gesagt, sehr häufig wird mir die Frage gestellt, wie man mitverfolgen kann, wer alles auf der Datanbank rumhuscht, welches select-Statement denn so schlecht ist usw. usw.
Den Fragen ihre Antwort zu geben ist in erster Linie SQL zu beherrschen ;-)
Mit Hilfe des Profilers erstellen wir eine Ablaufverfolgung, die allerdings statt in einer Date in eine Tabelle geschrieben wird.
Mit Hilfe des Assistenten ist das so einfach, dass ich mir weitere Erklärungen dazu erspare. Die dazu verwendetete Tabelle muss nicht mal vorher erstellt werden.
Nach Start der Ablaufverfolgung können wir unsere Fragen stellen:
Wer war alles auf meiner DB:
Select distinct NT-Login from profilertabelle (oder LoginName) |
Welche Abfrage hat am längsten gebraucht?
select top 5 * from profiler where textdata like 'select%'order by duration asc |
Allerdings würde ich hier bei meine Fragen darauf achten, dass die Werte auch vergleichbar sind:
Welche Aktion war am rechenintensivsten und vor allem im Vergleich zu allen anderen Aktionen
select max(cpu), avg(cpu), min(cpu), max(cpu) from profiler |
Auch hier würde ich aus Performancegründen, die Ablaufverfolgung zuerst einmal nicht den ganzen Tag laufen zu lassen, sondern nur zu "bestimmten" Zeiten. Das Schreiben der Tabllen auf einen anderen Server ist zwar möglich, verfälscht allerdings durch die zusätzliche Netzwerklast die Ergebnisse.
Ich hoffe mit diesen Ideen kann man durchaus sein eigenes Süppchen brauen und all die Dinge abfragen, die einem schon immer beschäftigt haben.
Viel Spaß