JDBC-Verbindung zu sehr beschäftigt, SQL 2000,: - selectMethod=cursor vs selectMethod direct=?

In den Prozess der versucht zu helfen, ein app-dev-team mit der performance-Probleme auf einem SQL 2000 server (aus einer Reihe von Java-Anwendungen auf separaten app-Server), ich lief ein SQL-trace und entdeckt, dass alle Aufrufe der Datenbank sind voll von API-Servercursor Aussagen (von sp_cursorprepexec verwendet werden, sp_cursorfetch, sp_cursorclose).

Aussieht, sind Sie unter Angabe einiger Eigenschaften der Verbindungszeichenfolge, die erzwingen, dass die Verwendung von server-side-cursors, abrufen von nur 128 Zeilen von Daten zu einem Zeitpunkt: (Von http://msdn.microsoft.com/en-us/library/Aa172588)

Wenn die API-cursor-Parametern oder
Eigenschaften werden gesetzt, was andere
als die Standardwerte, die OLE DB
provider für SQL Server und SQL
Server-ODBC-Treiber verwenden Sie API-server
Cursor anstelle der Standard-Ergebnis
Sätze. Jeder Aufruf einer API-Funktion
holt Zeilen erzeugt
roundtrip zum server zum abrufen der
Zeilen aus der API-Servercursor.

UPDATE: Der connection-string bei der Ausgabe ist ein JDBC-connection-string parameter, selectMethod=cursor (die es ermöglicht, die server-side Cursor, die wir oben besprochen) gegen die alternative selectMethod=direct. Sie wurden mit selectMethod=cursor als Ihre standard-Verbindungszeichenfolge aus allen apps.

Aus meiner DBA-Perspektive, das ist einfach nur nervig (es Rauschen die Ablaufverfolgung mit nutzlosen junk), und (würde ich spekulieren) führen zu viele extra app-zu-SQL-server round-trips, die Verringerung der Gesamt-performance.

Sie offenbar testen, ändern (nur eines von über 60 verschiedenen app-verbindungen) zu selectMethod=direct aber erlebt einige Probleme (von denen ich habe keine details) und sind besorgt über die Anwendung brechen.

So, meine Fragen sind:

  • Kann mit selectMethod=cursor geringere Anwendungsleistung, wie ich versucht habe zu argumentieren? (durch die Erhöhung der Anzahl der erforderlichen Roundtrips auf einem SQL server, der bereits einen sehr hohen Anfragen/Sek)
  • Ist selectMethod= eine Anwendung-transparente Einstellung, die auf einer JDBC-Verbindung? Könnte diese brechen Ihre app, wenn wir es ändern?
  • Mehr in der Regel, wenn Sie verwenden sollten cursor vs direct?

Auch cross-posted auf SF.

BEARBEITEN: Erhalten die tatsächlichen technischen details, die garantieren, einen erheblichen Bearbeiten, um Titel, die Frage und die tags.

BEARBEITEN: Added bounty. Auch Hinzugefügt Kopfgeld auf die SF-Frage (diese Frage konzentriert sich auf das Verhalten der Anwendung, die SF-Frage konzentriert sich auf die SQL-Leistung.) Danke!!

  • Wenn ich mich Recht erinnere, hast du Recht. Dies scheint wie ein ServerFault Frage, wie viel als SO eine, obwohl. Sie würde wahrscheinlich smart zu Fragen, an sqlservercentral.com zu.
  • Ich habe erwähnt das es auf der #sqlhelp-tag auf twitter. Keine Bisse dort, entweder. Ich denke, die schlecht angesehen, auf den cross-post eine Frage die sich über mehrere SO Seiten, richtig?
  • Meine beste Vermutung wäre, dass Sie es versuchen sollten. Vielleicht haben Sie UnitTests, die Sie feuern können, die gegen die Datenbank mit den geänderten string (oder eine kleine test-Anwendung).
  • Ich verstehe nicht, warum es wäre, und Q ' s get cross-posted die ganze Zeit-vor allem, wenn Sie "moderiert" von einem Ort zum anderen, 2 Kopien bleiben. Wenn Sie gute Antworten auf eine Website, so sicher sein, um den link zurück zu den anderen (zu helfen, die künftigen Forscher).
InformationsquelleAutor BradC | 2010-09-01
  1. 12

    Kurz,

    1. selectMethod=cursor
      • theoretisch erfordert mehr server-Ressourcen als selectMethod=direct
      • nur Lasten in den meisten batch-Größe Einträge in den client-Speicher auf einmal, wodurch eine vorhersagbare client Speicherbedarf
    2. selectMethod=direct
      • theoretisch benötigt weniger server-Ressourcen als selectMethod=cursor
      • Lesen Sie die gesamte Ergebnismenge in den client-Speicher (sofern es der Treiber unterstützt nativ asynchrone ResultSet abrufen), bevor die client-Anwendung kann Durchlaufen; diese verringern kann die Leistung auf zwei Arten:
        1. reduzierte Leistung bei großen Ergebnismengen, wenn die client-Anwendung ist in einer Weise geschrieben, um zu stoppen Verarbeitung nach der Durchquerung nur ein Bruchteil der Ergebnismenge (mit direct es bereits bezahlt hat, die Kosten für das abrufen der Daten es werden im wesentlichen wegwerfen; mit cursor der Abfälle ist begrenzt auf maximal batch-Größe - 1 Zeilen -- die vorzeitige Beendigung Bedingung sollte wohl rekodiert werden in SQL sowieso z.B. als SELECT TOP oder window-Funktionen)
        2. reduzierte Leistung bei großen Ergebnismengen wegen der möglichen garbage collection und/oder out-of-memory-Probleme, die im Zusammenhang mit einem erhöhten Speicherbedarf

    In der Zusammenfassung,

    • Kann mit selectMethod=cursor geringere Leistung der Anwendung? -- jede Methode kann eine geringere Leistung, aus unterschiedlichen Gründen. Vergangenheit einer bestimmten Ergebnismenge Größe cursor können immer noch vorzuziehen. Siehe unten für Wann eine oder die andere
    • Ist selectMethod= eine Anwendung-transparente Einstellung, die auf einer JDBC-Verbindung? - es ist transparent, aber es kann immer noch brechen, Ihre app, wenn die Speicherauslastung wächst deutlich genug, um hog Ihre client-system (und dementsprechend auch Ihre server) oder einen Absturz des client insgesamt
    • Mehr in der Regel, wenn Sie verwenden sollten cursor vs direct? - Ich persönlich benutze cursor beim Umgang mit potenziell großen oder anderweitig eingegrenzten Ergebnis-sets. Die hin-overhead ist dann abgeschrieben, da eine große genug, batch-Größe, und mein Mandant Speicherbedarf ist vorhersehbar. Ich benutze direct wenn die Größe der Ergebnismenge ich erwarte, dass bekannt ist, schlechter als was auch immer batch-Größe, die ich verwenden, mit cursor, gebunden oder in irgendeiner Weise, oder wenn der Speicher ist nicht ein Problem.
    • Danke, vladr. Klingt wie seine Einstellung, dass würde einige Tests. Ich weiß, die app-server ist ziemlich ausgelastet, so war es vielleicht ein Speicher-Problem, das verursacht einige Probleme, wenn Sie sich diese aus.
    InformationsquelleAutor vladr
  2. 0

    Mit selectMethod=cursor verhindert, dass SQL Server mit Parallele Abfrageverarbeitung, die haben eine große Auswirkung auf die Leistung, zum Beispiel wenn:

    • Sie haben viele CPU-Kerne (und wer tut das nicht?)
    • Sie haben optimiert Ihre Datenbank durch eine Partitionierung von Tabellen
    • Sie laufen viel aggregierten Abfragen ( sum() , count() usw.)

    Schließlich, Microsoft Staaten die folgenden:

    (selectMethod=direct) bietet die Schnellste Leistung, wenn die Anwendung die Verarbeitung aller Zeilen.

    Sollten Sie auf jeden Fall versuchen und sehen, ob die Einstellung selectMethod direct=einen Unterschied macht für Sie.

    InformationsquelleAutor László van den Hoek
Schreibe einen Kommentar