Leistungsprobleme mit einem gespeicherten proc - Schließen einer Verbindung zu langsam

Ich habe zuvor eine question über eine gespeicherte Prozedur, die zu langsam auf einem SQL Server-Feld ausgeführt wurde gefragt, aber wenn ich den Sproc in Query Analyzer ausgeführt würde, würde es zurückkehren unter einer Sekunde. Der Client ist eine .NET 1.1 Winforms App.Leistungsprobleme mit einem gespeicherten proc - Schließen einer Verbindung zu langsam

Ich konnte VNC in die Box des Benutzers und natürlich, sie hatten keine SQL-Tools installiert, so dass ich Excel, ging in VBA und schrieb eine schnelle Funktion, um die SPROC mit genau die gleichen Parameter aufrufen.

Es stellt sich heraus, dass der Sproc Subsecond zurückgibt und ich alle Zeilen in kürzester Zeit durchlaufen kann. Das Schließen der Verbindung dauert jedoch sehr lange und reicht von 5 Sekunden bis 30 Sekunden.

Warum würde das Schließen einer Verbindung so lange dauern?

Quelle

2009-04-09 AngryHacker

Wir haben das Problem gefunden. Der Lese-/Schreib-Cache im RAID-Array wurde aufgrund einer leeren Batterie von der lokalen IT deaktiviert. Fragen Sie mich nicht, warum auf der Welt das RAID-Array auf einer Batterie läuft. – AngryHacker

Die Batterie wird verwendet, um den Cache des RAID-Controllers im Speicher zu speichern. Wenn der Strom während eines Schreibvorgangs ausfällt, hält der RAID-Controller die Daten fest, die auf die Festplatte geschrieben werden müssen, damit Ihre Arrays sicher sind. Wenn diese Batterie ausfällt, ist das Caching deaktiviert. –

Danke. Das erklärt es. – AngryHacker

Die von Ihnen beschriebenen Symptome sind fast immer auf einen "inkorrekten" zwischengespeicherten Abfrageplan zurückzuführen. Während dies ein großes Thema ist (siehe parameter sniffing hier auf SO), können Sie das Problem oft (aber nicht immer) beheben, indem Sie die Indizes einer Datenbank neu aufbauen und sicherstellen, dass alle Statistiken aktuell sind.

Quelle

2009-04-10 01:47:42

Ich habe Parameter-Sniffing als möglichen Täter eliminiert. Das ist es nicht. Ich habe auch Indizes neu erstellt und eine vollständige Update-Statistik mit Fullscan erstellt. Beachten Sie, dass die Daten schnell zurückkommen. Die Verbindung braucht ewig, um geschlossen zu werden. – AngryHacker

@AngryHacker: Wenn Sie "die Verbindung schließen" sagen, sprechen Sie davon, dass es in den Verbindungspool zurückgegeben wird? Können Sie einen Beispielcode veröffentlichen, der dieses Verhalten zeigt? –

Das Problem ist gelöst (siehe mein Kommentar zum OQ). Ich habe jedoch gelernt, dass wenn Sie die Verbindung schließen (conn.Close), aber die Zeilen nicht durchgeschleift haben, die Methode tatsächlich alle Zeilen auf den Client herunterzieht, bevor die Verbindung tatsächlich geschlossen wird. – AngryHacker

Wenn Sie einen SqlDataReader verwenden, können Sie versuchen, sobald Sie alle benötigten Daten haben, Cancel auf dem SqlCommand aufzurufen, bevor Sie Close auf dem SqkDataReader aufrufen. Dies verhindert, dass die out-Parameter und Rückgabewerte ausgefüllt werden, was die Ursache für die Langsamkeit beim Schließen der Verbindung sein könnte. Tun Sie es in einem try-catch-Block, weil es eine Ausnahme vom Typ "canceled by user" auslösen kann.

Quelle

2009-04-10 02:18:54

Verbindungspooling?

Das, oder ich würde nach Service Packs oder KB-Artikeln für die Client-Bibliothek suchen.

Quelle

2009-04-10 14:52:50

Leistungsprobleme mit einem gespeicherten proc - Schließen einer Verbindung zu langsam

Antwort

Verwandte Themen