[Gelöst] SQL Reads
23. Juli 2010 15:30
Hallo
Bei Öffnen einer Form "produziert" der SQL-Server jedesmal 4000 Reads.
Im SQL-Profiler sehe ich nur exec sp_execute 86,''.
Man sieht aber nichts, wo er sich die sp zusammenstellt.
Weiss jemand was das zu bedeuten hat, oder leses ich im Profiler da etwas falsch?
Gruss
Bei Öffnen einer Form "produziert" der SQL-Server jedesmal 4000 Reads.
Im SQL-Profiler sehe ich nur exec sp_execute 86,''.
Man sieht aber nichts, wo er sich die sp zusammenstellt.
Weiss jemand was das zu bedeuten hat, oder leses ich im Profiler da etwas falsch?
Gruss
Zuletzt geändert von martinst am 26. Juli 2010 16:36, insgesamt 1-mal geändert.
Re: SQL Reads
23. Juli 2010 19:24
Hi,
nun, Du hast offenbar nur den "Remote Procedure Call" (SP: RPC Completed) aufgezeichnet. Mit benötigt man aber mindestens die Ereignisse ...
Stored Procedures:
SP: Stmt Completed
SP: RPC Completed
Das "Statement" zeigt die Abfrage an, also z.B. ein ...
... wobei der tatsächliche Filter-Wert durch einen Platzhalter (@P1) belegt ist.
Im "RPC" wird dann das Statement (als SP gekapselt) ausgeführt, wobei die Filterwerte übergeben werden; z.B. ...
... wobei die erste Zahl (hier 86) die ID des vorangegangen Statements wieder gibt, dann folgen die Werte hier '' also <blank>.
D.h. die eigentliche Abfrage könnte also gewesen sein (z.B. - wir kennen das echte Statement ja nicht):
Mehr dazu (uvm). hier zum downloaden: http://www.stryk.info/Performance%20Checklists%201.08.pdf
nun, Du hast offenbar nur den "Remote Procedure Call" (SP: RPC Completed) aufgezeichnet. Mit benötigt man aber mindestens die Ereignisse ...
Stored Procedures:
SP: Stmt Completed
SP: RPC Completed
Das "Statement" zeigt die Abfrage an, also z.B. ein ...
- Code:
SELECT * FROM "Navision"."dbo"."CRONUS$Item" WHERE "No_" > @P1
... wobei der tatsächliche Filter-Wert durch einen Platzhalter (@P1) belegt ist.
Im "RPC" wird dann das Statement (als SP gekapselt) ausgeführt, wobei die Filterwerte übergeben werden; z.B. ...
- Code:
exec sp_execute 86,''
... wobei die erste Zahl (hier 86) die ID des vorangegangen Statements wieder gibt, dann folgen die Werte hier '' also <blank>.
D.h. die eigentliche Abfrage könnte also gewesen sein (z.B. - wir kennen das echte Statement ja nicht):
- Code:
SELECT * FROM "Navision"."dbo"."CRONUS$Item" WHERE "No_" > ''
Mehr dazu (uvm). hier zum downloaden: http://www.stryk.info/Performance%20Checklists%201.08.pdf
Re: SQL Reads
23. Juli 2010 21:35
Hallo
Danke für die Hinweise.
Ich kenne dieses Vorgehensweise grundsätzlich. Schliesslich habe ich Dein Buch gelesen, Dein Blog studiert und eine Menge dabei gelernt.
Es ist aber nicht zu glauben. Ich schalte den Profiler ein, als einzigen Filter im Profiler habe ich den Loginname angegeben.
An der interessanten Stelle in NAV starte ich dann den Profiler.
Danach erscheint 2 x
SQL:BatchStarting IF @@TRANCOUNT > 0 COMMIT TRAN Microsoft Dynamics NAV client
Dann x mal:
RPC:Completed exec sp_cursorunprepare 1073741970 Microsoft Dynamics NAV client
Aber nie ein:
SP: Stmt Completed
Kann es sein, dass das Statement irgwndwie vorher bereits Complete ist, und gar nicht mehr gebildet werden muss?
Welche Tabelle es ist, habe ich nun gesehen. Natürlich wieder die blöde Setup-Table mit den vielen BLOB-Feldern (treibt mich noch zum Wahnsinn).
Gruss
Danke für die Hinweise.
Ich kenne dieses Vorgehensweise grundsätzlich. Schliesslich habe ich Dein Buch gelesen, Dein Blog studiert und eine Menge dabei gelernt.
Es ist aber nicht zu glauben. Ich schalte den Profiler ein, als einzigen Filter im Profiler habe ich den Loginname angegeben.
An der interessanten Stelle in NAV starte ich dann den Profiler.
Danach erscheint 2 x
SQL:BatchStarting IF @@TRANCOUNT > 0 COMMIT TRAN Microsoft Dynamics NAV client
Dann x mal:
RPC:Completed exec sp_cursorunprepare 1073741970 Microsoft Dynamics NAV client
Aber nie ein:
SP: Stmt Completed
Kann es sein, dass das Statement irgwndwie vorher bereits Complete ist, und gar nicht mehr gebildet werden muss?
Welche Tabelle es ist, habe ich nun gesehen. Natürlich wieder die blöde Setup-Table mit den vielen BLOB-Feldern (treibt mich noch zum Wahnsinn).
Gruss
Re: SQL Reads
23. Juli 2010 23:02
Also ich fürchte da stimmt was nicht mit deinen Profiler Einstellungen ...
Anbei ein paar Vorlagen.
Anbei ein paar Vorlagen.
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Re: SQL Reads
23. Juli 2010 23:05
Die x-fachen RPC "sp_cursorunprepare" treten normalerweise am Ende von bestimmten Verarbeitungen auf, oder beim Log-Off eines Users etc. ...
Re: SQL Reads
25. Juli 2010 10:40
Hallo Jörg
Danke für Deine Unterstützung.
Das Problem war, dass ich als Profiler-Template "Standard" eingestellt hatte.
Dort wird StmtCompleted nicht angezeigt.
Der Falschenhals ist trotzdem gefunden.
Es sind definitiv die Blobs. Bei einem Kunden werden dort pro Zugriff 14000 Reads verursacht. Leider wird auf diese Tabelle sehr oft zugegriffen.
Also werde ich morgen beginnen, diese Tabelle zu "entschlacken". Blobs raus und in eine sep. Tabelle implementieren.
Vermutet hatte ich dieses Problem schon länger.
P.S.
Unter Nativ hatten wir dieses Problem nie. Es scheint, dass Nativ Tabellen mit Blobs schneller liest, solangen keine CalcFields auf den Blobs abgesetzt wird.
Gruss und Danke
Danke für Deine Unterstützung.
Das Problem war, dass ich als Profiler-Template "Standard" eingestellt hatte.
Dort wird StmtCompleted nicht angezeigt.
Der Falschenhals ist trotzdem gefunden.
Es sind definitiv die Blobs. Bei einem Kunden werden dort pro Zugriff 14000 Reads verursacht. Leider wird auf diese Tabelle sehr oft zugegriffen.
Also werde ich morgen beginnen, diese Tabelle zu "entschlacken". Blobs raus und in eine sep. Tabelle implementieren.
Vermutet hatte ich dieses Problem schon länger.
P.S.
Unter Nativ hatten wir dieses Problem nie. Es scheint, dass Nativ Tabellen mit Blobs schneller liest, solangen keine CalcFields auf den Blobs abgesetzt wird.
Gruss und Danke
Re: SQL Reads
25. Juli 2010 10:44
Re: SQL Reads
25. Juli 2010 10:57
Ganau das werde ich machen.
Blob's weg aus der viel gelesenen Tabelle in eine BLOB-Tabelle.
Als wir diesen Teil damals entwickelt haben, arbeiteten wir noch ausschliesslich mit Nativ-DB's.
Das Problem tauchte jetzt eben erst mit dem Umstieg auf SQL auf.
Im Prinzip ist es ja logisch, dass es dort Probleme geben muss. Damals war man sich dessen eben noch nicht bewusst.
Gruss
Blob's weg aus der viel gelesenen Tabelle in eine BLOB-Tabelle.
Als wir diesen Teil damals entwickelt haben, arbeiteten wir noch ausschliesslich mit Nativ-DB's.
Das Problem tauchte jetzt eben erst mit dem Umstieg auf SQL auf.
Im Prinzip ist es ja logisch, dass es dort Probleme geben muss. Damals war man sich dessen eben noch nicht bewusst.
Gruss
Re: SQL Reads
26. Juli 2010 16:35
Statusmeldung:
Blobs aus dieser viel verwendeten Tabelle entfernt und in ausgelagerte Tabelle verschoben.
Reads < 20
Vorher z.T. > 16'000
Gruss
Blobs aus dieser viel verwendeten Tabelle entfernt und in ausgelagerte Tabelle verschoben.
Reads < 20
Vorher z.T. > 16'000
Gruss
Re: [Gelöst] SQL Reads
26. Juli 2010 16:47
Ja, Ja! 