SQL Profiler

Hallo @all,

ich denke viele von euch schlagen sich mit dem SQL Profiler rum! Nun ist ein solches Trace ja nicht ganz einfach zu lesen. Ich schlage also vor, dass wir uns in diesem Thema einmal speziel dem SQL Profiler widmen.

Folgendes Problem seit etwa 2 Tagen stellen wir fest, dass das Formular Debitorenverkaufshistorie extrem langsam geworden ist. Laufzeiten von 5 Minuten sind mitmal völlig normal.
Das gleiche in der Testumgebung (gleiche DB auf gleichem Server) läuft in 5 Sekunden.

Also habe ich das ganze mit dem Profiler analysiert und muss feststellen, dass er beispielsweise bei folgendem SQL Befehl:

exec sp_cursoropen @p1 output,N'SELECT * FROM "Ehlert"."dbo"."Ehlert GmbH & Co_ KG$Sales Invoice Line" WITH (READUNCOMMITTED) WHERE (("Sell-to Customer No_"=@P1)) AND "Sell-to Customer No_"=@P2 AND "Document No_">@P3 ORDER BY
"Sell-to Customer No_","Document No_","Line No_" OPTION (FAST 5)',@p3 output,@p4 output,@p5 output,N'@P1 varchar(20),@P2 varchar(20),@P3 varchar(20)','100100','100100',''

auf einen READ Wert von 305201
einen CPU Wert von 4469
einen Duration von 67236

Mir stellt sich erstmal folfgende Frage: In welcher Einheit wird dieser Wert angegeben?
Offenbar müssen die Werte extrem hoch sein, weil sie soviel höher sind als vergleichbare Abfragen bringen.
Nächste Frage: Warum ist der Unterschied zwischen Echt und Teststand so groß? Im Echtstand werden die Statistiken wöchentlich geflasht, im Teststand geschieht praktisch garnichts und doch ist er 100 mal schneller.

Ich geh mal davon aus, dass im Teststand wesentlich weniger gebuchte Rechnungen sind, oder?
Ausserdem sieht man da wieder mal eine unzulänglichkeit der Umsetzung von Navision Abfragen auf SQL-Abfragen:
Where Kundennr=100100 and Kundennr=100100 and Rechnungsnr>''
IMHO ist alles ab dem ersten AND überfllüssig....

Hallo Michael,

Nein im Teststand gibt es nahezu genausoviele gebuchte Rechnungen, da es eine Kopie des Echtstandes ist. Der Unterscied ist, es arbeitet nur einer Live daran.
Was die SQL Umsetzung betrifft ist das auf buntem "GUI Wizard Niveau", nicht zu vergleichen mit dem was man selbst schreiben würde.
Die doppelte where Klausel ist das eine, das andere ist das "Document No." >0 das am Ende steht. Document No ist Varchar!!! Gibt man den Befehl direkt ab, bekommt man die Fehlertmeldung Fehler bei Typumwandlung, weil man kein größer Varchar auswerten kann.

Teststand auf dem gleichen Server wie Echtstand oder nur native Client Only?

Ein SQL Server 2005 Std. mit 3 Datenbanken: Echtstand, Teststand, Cronus. Unterschied: nur der Echtstand arbeitet mit Full Recouvery und Multiuser ca. 40.

Wie oft führt der Warungsplan die Transaktionsprotokollsicherung der Echtstand DB aus?

sequentiell alle 15 Minuten
voll jeden Sontag vor dem Optimierungsjob

Das sollte eigentlich reichen. Dann kann es nur sein, dass die 40 Leute so viel buchen, dass da ständig irgendwo ne Sperre steht....
oder hattest du das auch mal ausprobiert, wenn keiner mehr online ist?

Also abends ist es schon erheblich schneller, aber ich kann tagsüber keine nennenswerten Sperren ermitteln, die hab ich eigentlich fast nie.

So lang stehen die Sperren ja nicht, da ist es schon Zufall, wenn man auf eine trifft bei einem Snapshot...
aber während der abfragen (ist ja nicht nur die eine, die für die Vorgangsstatistik gefeuert wird) stößt Navision sicher häufiger drauf. zusätzlich ist der Server natürlich auch mit den anderen Abfragen an die Datenbank beschäftigt. die Testdatenbank liegt vermutlich auf einer eigenen Platte?

Ja das kann schopn sein, dass es zwischendurch Sperren gibt.

Nein die Datenbank liegt auf dem gleichen Laufwerk, wie die Echte Datenbank!

Tja, dann weiß ich auch nicht mehr weiter, vielleicht hat Stryk ja noch eine Idee....

Ja erstmel vielen Dank für Deine Mühe! Vielleich schaut er ja mal rein.

Vielleich schaut er ja mal rein

Ja, ja, tut er ... danke für das Vertrauen ... bin diese Woche beim Kunden vor Ort und soz. "semi offline" ...

Here we go:

Code:

exec sp_cursoropen @p1 output,N'SELECT * FROM "Ehlert"."dbo"."Ehlert GmbH & Co_ KG$Sales Invoice Line" WITH (READUNCOMMITTED) WHERE (("Sell-to Customer No_"=@P1)) AND "Sell-to Customer No_"=@P2 AND "Document No_">@P3 ORDER BY
"Sell-to Customer No_","Document No_","Line No_" OPTION (FAST 5)',@p3 output,@p4 output,@p5 output,N'@P1 varchar(20),@P2 varchar(20),@P3 varchar(20)','100100','100100',''

auf einen READ Wert von 305201
einen CPU Wert von 4469
einen Duration von 67236

Dass die WHERE Klausel so seltsam aussieht, liegt daran, daß C/SIDE die verschiedenen Filterbedingungen wie TableView etc. mit SETRANGE etc. kombiniert; der Filter auf "Document No_" mit '' wird soz. von der ZUP Datei verursacht (SourceTablePlacement).
Mit über 300.000 Reads (= Seiten zu je 8kB) und einer Duration (msec) von über einer Minute kann man darauf Wetten, daß hier ein "Clustered Index Scan" - also das volständige Lesen der Tabelle ausgeführt wurde. Da nur 4 Sekunden davon auf der CPU verbracht worden sind, könnte die Abfrage zusätzlich blockiert worden sein ...

Ausführungsplan anzeigen (d.h. ad hoc Statement "zusammenbasteln" und ausführen, dabei Execution Plan anzeigen lassen):

Code:

SET STATISTICS IO ON
GO

SELECT * FROM "Ehlert"."dbo"."Ehlert GmbH & Co_ KG$Sales Invoice Line" WITH (READUNCOMMITTED) WHERE (("Sell-to Customer No_"='100100')) AND "Sell-to Customer No_"='100100' AND "Document No_">'' ORDER BY
"Sell-to Customer No_","Document No_","Line No_" OPTION (FAST 5)

In "Messages" wird nun u.a. die Anzahl der "logischen Reads" angezeigt und sollte die 300.000 Reads in etwa bestätigen.

Wie sieht der Ausführungsplan aus? Wenn kein "Clustered Index Scan" durchgeführt wird, welcher Index wurde benutzt?

Ist für den NAV Key "Sell-to Customer No_" die Eigenschaft "MaintainSQLIndex" gesetzt? Wenn Nein, dann bitte setzen.

Und: In der betroffenen Form bitte mal die Eigenschaft "SourceTablePlacement" auf "First" oder "Last" setzten!

Was verstehst Du unter "Statistiken geflasht"? Die Index-Statistiken sollten täglich aktualisiert werden via Job:

Code:

use [Navision]
go
exec sp_updatestats
go
exec sp_createstats 'indexonly'

Zu beachten ist hier, daß die DB Einstellungen "Auto. Create Stats" und "Auto. Update Stats" deaktiviert sind!

Wie verhält sich die Abfrage nun?

Hallo stryk,

das ist eine Antwort nach meinem Geschmack! Das muss ich erstmal durchexerzieren und meld mich dann.

Vorerst Besten Dank euch beiden!

mod