none
Anzahl aktiver Cursor begrenzt? RRS feed

  • 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?

    Dienstag, 10. Mai 2016 14:26

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,.

    Dienstag, 10. Mai 2016 15:31
    Beantworter
  • 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.

    Gruß Benjamin


    Benjamin Hoch
    MCSE: Data Platform
    MCSA: Windows Server 2012
    Blog

    Dienstag, 10. Mai 2016 16:26

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,.

    Dienstag, 10. Mai 2016 15:31
    Beantworter
  • 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.

    Gruß Benjamin


    Benjamin Hoch
    MCSE: Data Platform
    MCSA: Windows Server 2012
    Blog

    Dienstag, 10. Mai 2016 16:26
  • 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

    Dienstag, 10. Mai 2016 21:39
  • 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

    Donnerstag, 12. Mai 2016 08:06