Benutzer mit den meisten Antworten
Anzahl aktiver Cursor begrenzt?

Frage
-
In einem Programm möchte ich 2000 aktive Cursor auf eine SQL Server 2014 Enterprise Datenbank halten. Der Zugriff erfolgt über ODBC. Nach ca. 500-700 (schwankende Zahl) aktiven Cursor reagiert die Datenbank nicht mehr. Auch weitere Programme können dann auf dieser DB keinen Cursor mehr erzeugen. Erst wenn wieder einige von den erzeugten Cursor freigegeben werden können wieder ein paar neue Cursor erzeugt werden.
Gibt es irgendwo eine Einstellung mit welcher die maximale Anzahl der aktiven (keyset) Cursor rekonfiguriert werden kann?
Antworten
-
Hallo,
soweit ich weiß gibt es kein direktes Limit für Cursor, in Spezifikationen der maximalen Kapazität für SQL Server wie unter Serverkonfigurationsoptionen wird nichts dazu genannt. Nur bei der extraordinären Menge kann man an andere Limits stoßen, wie die Zahl der Verbindungen[1], Speicher, Sperren uam.; bei Keysets können auch Limits durch tempdb zum Tragen kommen. Die erste zutreffende Engstelle könnte man nur durch Profiling heraus finden.
(Viele) Cursor sind noch nie eine gute Idee gewesen und bei den angepeilten 2000 wirst Du nie eine befriedigende Performance erreichen. und sollte die Datenbank im Multi-User Betrieb laufen, solltest Du Dich nicht von anderen wartenden und verärgerten Anwendern erwischen lassen ;)
Ich würde Dir raten, Dein Konzept generell in Frage zu stellen und nach einer alternativen Lösung zu suchen, die mit weniger Ressourcen auskommt. Wenn es unbedingt Cursor sein müssen, sollten es zumindest FAST_FORWARD, FORWARD_ONLY Servercursor sein und diese sollten tunlichst nacheinander abgearbeitet werden.
Gruß Elmar
[1] siehe dazu Verwenden von Multiple Active Result Sets (MARS) - sollte dabei aktiviert sein,.
- Als Antwort vorgeschlagen Andreas.WolterMicrosoft employee Dienstag, 10. Mai 2016 21:29
- Als Antwort markiert Aleksander Chalabashiev Montag, 23. Mai 2016 06:34
-
Hallo
das Problem liegt hier in der maximalen Anzahl an Worker Threads des SQL Server. Hierdurch wird die maximale Anzahl an Sessions (Verbindungen) bestimmt. Der Wert ist fest und kann softwareseitig nicht geändert werden.
https://msdn.microsoft.com/en-us/library/ms190219.aspx
Nur die Anzahl der Cores bestimmt den Wert.
Was die Cursor betrifft kann ich mich nur Elmar anschließen.
Benjamin Hoch
MCSE: Data Platform
MCSA: Windows Server 2012
Blog- Als Antwort vorgeschlagen Elmar BoyeEditor Donnerstag, 12. Mai 2016 08:41
- Als Antwort markiert Aleksander Chalabashiev Montag, 23. Mai 2016 06:34
Alle Antworten
-
Hallo,
soweit ich weiß gibt es kein direktes Limit für Cursor, in Spezifikationen der maximalen Kapazität für SQL Server wie unter Serverkonfigurationsoptionen wird nichts dazu genannt. Nur bei der extraordinären Menge kann man an andere Limits stoßen, wie die Zahl der Verbindungen[1], Speicher, Sperren uam.; bei Keysets können auch Limits durch tempdb zum Tragen kommen. Die erste zutreffende Engstelle könnte man nur durch Profiling heraus finden.
(Viele) Cursor sind noch nie eine gute Idee gewesen und bei den angepeilten 2000 wirst Du nie eine befriedigende Performance erreichen. und sollte die Datenbank im Multi-User Betrieb laufen, solltest Du Dich nicht von anderen wartenden und verärgerten Anwendern erwischen lassen ;)
Ich würde Dir raten, Dein Konzept generell in Frage zu stellen und nach einer alternativen Lösung zu suchen, die mit weniger Ressourcen auskommt. Wenn es unbedingt Cursor sein müssen, sollten es zumindest FAST_FORWARD, FORWARD_ONLY Servercursor sein und diese sollten tunlichst nacheinander abgearbeitet werden.
Gruß Elmar
[1] siehe dazu Verwenden von Multiple Active Result Sets (MARS) - sollte dabei aktiviert sein,.
- Als Antwort vorgeschlagen Andreas.WolterMicrosoft employee Dienstag, 10. Mai 2016 21:29
- Als Antwort markiert Aleksander Chalabashiev Montag, 23. Mai 2016 06:34
-
Hallo
das Problem liegt hier in der maximalen Anzahl an Worker Threads des SQL Server. Hierdurch wird die maximale Anzahl an Sessions (Verbindungen) bestimmt. Der Wert ist fest und kann softwareseitig nicht geändert werden.
https://msdn.microsoft.com/en-us/library/ms190219.aspx
Nur die Anzahl der Cores bestimmt den Wert.
Was die Cursor betrifft kann ich mich nur Elmar anschließen.
Benjamin Hoch
MCSE: Data Platform
MCSA: Windows Server 2012
Blog- Als Antwort vorgeschlagen Elmar BoyeEditor Donnerstag, 12. Mai 2016 08:41
- Als Antwort markiert Aleksander Chalabashiev Montag, 23. Mai 2016 06:34
-
Hallo
das Problem liegt hier in der maximalen Anzahl an Worker Threads des SQL Server. Hierdurch wird die maximale Anzahl an Sessions (Verbindungen) bestimmt. Der Wert ist fest und kann softwareseitig nicht geändert werden.
https://msdn.microsoft.com/en-us/library/ms190219.aspx
Nur die Anzahl der Cores bestimmt den Wert.
...Achtung, das ist nicht ganz korrekt:
Zum einen bestimmt die Anzahl der Worker lediglich die Anzahl der gleichzeitig durchführbaren tasks ("work-units" , wenn man so will), und ist völlig unabhängig von der Anzahl der sessions.
- Beispielsweise kann ein Server 1000 gleichzeitige Sessions haben, aber nur 256 davon haben einen task am laufen, der aktiv von einem worker (aktiv) abgearbeitet wird.
Zum anderen kann man den Wert der maximalen worker threads durchaus anpassen - wenngleich es selten sinnvoll ist. Er wird automatisch nach Anzahl der CPU Cores gesetzt, soweit so richtig.
Ich hoffe die Korrektur am Rande wird nicht krumm genommen. :)
Gruß
Andreas
Andreas Wolter (Blog | Twitter)
MCSM: Microsoft Certified Solutions Master Data Platform/SQL Server 2012
MCM SQL Server 2008
MVP Data Platform
www.SarpedonQualityLab.com | www.andreas-wolter.com -
Hallo,
vielen Dank für die wertvollen Hinweise.
Das Problem konnte ich durch das Hochsetzen der Workerthreads lösen.
Mit 1600 aktiven Usern ist es nicht einfach, die Anzahl der aktiven Cursor niedrig zu halten. Aber wir werden nun daran arbeiten.
Gruß
Ingolf
IB