DevTrain Startseite Visual Studio 1 Magazin  
  
  
SUCHEN:  
ARTIKEL ONLINE: 525   

Kategorien
.NET
Datenbanken
Web
XML

Allgemein
Camp
Foren
Events
Persönliche Einstellungen
Registrieren
Prämien Shop
Kontakt
Impressum
Über DevTrain

Autoren


   Autor: Andreas Rauch Artikel Drucken
        
Gern vergessen - nützliches rund um den SQL Server

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ß

 


DevTrain Camp - Schneller zum .NET 3.5 Developer
 
Verwandte Artikel      Verlinkte Dokumente
    Keine verknüpften Dokumente
    Keine Links vorhanden

  Erfasst am: 14.10.2004
  Gültig bis: 12.01.2005
11 Ratings
Bewertung: 78,2%
schlecht    sehr gut  

 
© Copyright 2007 ppedv AG