Wir verwenden ein ORM, das einen Aufruf von .NET an die sp_executesql-gespeicherte Prozedur von SQL Server ausführt.
Wenn der gespeicherte Proc von .NET aufgerufen wird, erhalten wir eine Zeitüberschreitungsausnahme.
Wenn ich Profiler betrachte, kann ich sehen, dass die Abfrage sehr lange dauert.
Die Abfrage ist im Wesentlichen:
%Vor%Der verwirrende Teil für mich ist folgender: Wenn ich die Abfrage, die in SQL Management Studio ausgegeben wird, kopiere und einfüge und sie interaktiv ausführe, wird sie einfach ausgeführt.
Weiß jemand, warum dieselbe Abfrage bei Ausführung über .NET-Code wesentlich länger dauern würde? (Ich bin in der Lage, dies zu reproduzieren - die aus Code ausgeführte Abfrage überschreitet das Zeitlimit, und die interaktiv ausgeführte Abfrage funktioniert konsistent.)
Jede Hilfe wird geschätzt. Danke!
Eine Sache, die ich ein paar Mal gesehen habe, ist, wenn Sie zwischen nvarchar- und varchar-Typen für einen Abfrageparameter in einem indizierten Feld nicht übereinstimmen. Dies kann passieren, wenn Sie varchar in Ihrer Datenbank verwenden und nicht explizit den Typ Ihres Parameters in .Net festlegen, der standardmäßig nvarchar annimmt.
In diesem Fall wählt Sql Server die korrektere Option und nicht die leistungsstärkere Option. Statt nur Ihren Parameter in varchar zu konvertieren, was eine einschränkende Konvertierung wäre, die möglicherweise Informationen verlieren könnte, wird die Datenbank gezwungen, jeden Wert für diese Spalte in der Tabelle in einen nvarchar umzuwandeln (was ohne Informationsverlust garantiert ist). . Das ist nicht nur langsam, aber Sql Server wird den Index nicht mehr verwenden können. Unnötig zu sagen, dass die Ausführung der Abfrage sehr viel länger dauert.
Ich habe die gleichen Probleme, eine Prozedur, die von .net ausgeführt wird, die zu viel Zeit in Anspruch nimmt (und nicht viele Zeilen zurückgibt). Ich sende eine Zeichenfolge an sql: "execute stored_procedure @ parameter1 = value1" und ich kopiere dies und laufe auf SQL Management Studio, aber dort läuft alles gut. Das Interessante an diesem Fall ist, dass ich in meiner Anfrage einfach einen LETTER zu einem Parameterwert hinzufüge oder entferne, um es zu verursachen. Ich bin sehr verwirrt.
Als Info benutze ich Volltext-Index und temporäre Tabellen por paging, aber wie gesagt, die gleiche Abfrage (und ich bin mir sicher) läuft perfekt in SQL Management Studio.
Hatte das gleiche Problem.
Das Umbauen von Indizes löste das Problem.
Vielleicht liegt das Problem in dem Typ der Parameter, die nvarchar vs index sind, der auf einer varchar Spalte ... ist?
Ich denke, das liegt daran, dass sp_executelsql kompilierte Abfragepläne wiederverwenden soll, so dass es keine Parameter erneut schnüffelt, wenn die gleiche Abfrage es erneut trifft, so dass es einen Plan verwendet, der sehr langsam sein kann (wird es sagen) Sie warum ein langsamer Abfrage-Plan) mit dem aktuellen Parameter values.it scheint zu sein, dass sp_executesql verwendet eine andere Methode für die Auswahl von Indizes und anscheinend ist es eine gebrochene Methode im Vergleich zu einer Nur-Text-Abfrage.
Was anders ist, ist das Tabellenupdate für 'Firma (eine Tabelle)' unter einer sp_executesql wird über eine Kette von verschachtelten Schleifen zugeführt, während die Textanfrage über eine Kette von Hash-Übereinstimmungen zugeführt wird. Die Konstruktion der Ansichten scheint zwischen den beiden Versionen identisch zu sein (was ich erwarten würde). Leider ist der Rest sehr komplex und sie scheinen in der Mitte radikal andere Dinge zu tun; selbst das Ziehen eines "tatsächlichen" Ausführungsplans ergibt keine tatsächlichen Ausführungszeiten für die verschiedenen Unterkomponenten der Abfrage. Wirklich, ich kann keinen Grund für sp_executesql sehen, etwas anderes zu wählen, aber es baut zuverlässig einen wesentlich langsameren Plan.
Das Sniffing von Parametern ist eine Lösung, daher sollten Sie die Parameternamen umbenennen oder Sie können sogar die Spaltennamen in where-Klausel vertauschen, die sp_executesql dazu veranlassen, einen Abfrageplan neu zu erstellen, anstatt einen alten langsamen Plan zu verwenden die Lösung, aber es wird nicht so lange einen langsameren Plan Cache.
Grüße.
Hier ist was ich gefunden habe. Ich habe eine sehr komplexe gespeicherte Prozedur, die immer Informationen zählt und die Daten in eine Matrix mit 8 Spalten und 17 Zeilen stellt, wie es von Crystal Reports jeden Monat aufgerufen wird. Die Produktdatenbank war auf einem 96 GB verrückten schnellen Server! Kürzlich wurde es auf eine 32 GB virtuelle Maschine verkleinert. Während herunterskaliert - es hat die App in vielerlei Hinsicht langsamer laufen lassen - bis ein paar Indizes hinzugefügt wurden.
Dann kam die Zeit des Monats, um diesen 17-Zeilen-Matrix-Monatsbericht zu führen ... und wie Sie sich vorstellen können, ist es abgelaufen!
Der Proc-Aufruf war ziemlich einfach - 3 Parameter. Ein Startdatum, ein Enddatum und ein zu filternder Bereich - null ist gleich ALL. Die 2 Daten wurden von Crystal Reports als Zeichen übergeben und diese gespeicherten PROC-Parameter wurden dann überall in diesem verrückten gespeicherten Prozess verwendet.
Jede der 17 Zeilen - verwendet im Wesentlichen WITH-Anweisungen und verrückte Verknüpfungen, um Datenzeilen vor dem Zählen / Schwenken in die Ergebnisse zu finden ... was in diesem Artikel NICHT wichtig ist.
Also hier ist es vereinfacht ....
%Vor%...
%Vor%...
%Vor%So moralisch von der Geschichte ist - der Optimierer war in der Lage, seine Sache zu machen, indem er die DECLARED Datetimes verwendete.
Tags und Links sql sql-server tsql llblgenpro