JDBC Verbindung zu sehr beschäftigt SQL 2000: selectMethod = Cursor vs selectMethod = direkt?

Question

Bei dem Versuch, einem App-Entwicklungsteam mit Leistungsproblemen auf einem SQL 2000-Server (aus einer Reihe von Java-Anwendungen auf separaten Anwendungsservern) zu helfen, führte ich eine SQL-Ablaufverfolgung durch und stellte fest, dass alle Aufrufe an die Datenbank voll waren von API-Server-Cursor-Anweisungen (sp_cursorprepexec, sp_cursorfetch, sp_cursorclose).

Sieht wie sie einige Verbindungszeicheneigenschaften sind spezifiziert, die die Verwendung von serverseitige Cursors zwingen, zu einer Zeit nur 128 Datenzeilen Abrufen: (Von http://msdn.microsoft.com/en-us/library/Aa172588)

Wenn die API-Cursor-Attribute oder Eigenschaften sind auf etwas anderes als die Standardwerte, die OLE DB Provider für SQL Server und dem SQL Server ODBC-Treiber verwenden API-Server Cursor statt Standardresultset Sets. Jeder Aufruf einer API-Funktion , die Zeilen abruft, generiert einen Roundtrip zum Server, um die Zeilen vom API-Servercursor abzurufen.

UPDATE: Die Verbindungszeichenfolge in Rede ist ein JDBC-Verbindung String-Parameter, selectMethod=cursor (die die serverseitige Cursors ermöglicht wir oben diskutiert) vs den alternativen selectMethod=direct. Sie haben selectMethod=cursor als Standard-Verbindungszeichenfolge aus allen Apps verwendet.

Aus meiner DBA-Perspektive, das ist nur ärgerlich (es verstopft die Spur mit nutzlosem Müll), und (ich würde spekulieren) führt zu vielen zusätzlichen App-zu-SQL-Server Rundreisen, die Gesamtleistung zu reduzieren.

Sie haben anscheinend Testwechsel (nur eine von etwa 60 verschiedenen App-Verbindungen) zu selectMethod=direct, aber einige Probleme (von denen ich keine Details habe) und sind besorgt über die Anwendung brechen.

Also, meine Fragen sind:

• selectMethod=cursor niedriger Anwendungsleistung Kann verwenden, wie ich zu argumentieren versucht haben? (durch Erhöhung der Anzahl der erforderlichen Rundreisen auf einem SQL-Server, der bereits sehr hohe Abfragen pro Sekunde aufweist)
• Ist selectMethod= eine anwendungstransparente Einstellung für eine JDBC-Verbindung? Könnte das ihre App kaputt machen, wenn wir sie ändern?
• Allgemeiner, wann sollten Sie cursor vs direct verwenden?

Auch cross-posted to SF.

BEARBEITEN: Erhalten tatsächliche technische Details, die eine signifikante Bearbeitung von Titel, Frage und Tags gewährleisten.

EDIT: Zusätzliche Prämie hinzugefügt. Außerdem wurde der SF-Frage ein Bounty hinzugefügt (diese Frage konzentriert sich auf das Anwendungsverhalten, die SF-Frage konzentriert sich auf die SQL-Leistung.) Danke !!

Answer 1

Kurz gesagt,

1. selectMethod=cursor
   • erfordert theoretisch more server-side resources als selectMethod=direct
   • nur Lasten höchstens Batch-Größe Datensätze in Client-Speicher auf einmal, in einem besser vorhersagbaren Client Speicherbedarf resultierenden
2. selectMethod=direct
   • erfordert theoretisch weniger serverseitige Ressourcen als selectMethod=cursor
   • wird die gesamte Ergebnismenge in die Client-Lese-Speicher (es sei denn, der Fahrer nativ asynchronen Ergebnismenge Retrieval unterstützt), bevor die Client-Anwendung kann über sie iterieren; Dies kann die Leistung auf zwei Arten reduzieren:
     1. reduzierte Leistung mit großen Ergebnismengen, wenn die Client-Applikation so geschrieben wird, wie die Verarbeitung zu stoppen, nachdem nur einen Bruchteil der Ergebnismenge (mit direct sie bereits durchquerte bezahlt die Kosten für das Abrufen von Daten wird es im Wesentlichen wegwerfen, mit cursor die Verschwendung ist begrenzt auf höchstens Batch-Größe - 1 Zeilen - die frühe Abbruchbedingung sollte wahrscheinlich in SQL trotzdem wie zB SELECT TOP oder Fensterfunktionen recycled
     2. reduzierte Leistung mit großen Ergebnismengen wegen möglicher Speicherbereinigung und/oder o ut-of-memory Probleme im Zusammenhang mit einem erhöhten Speicherbedarf

Zusammengefasst

• Kann mit selectMethod=cursor niedriger Leistung Anwendung? - Beide Methoden können die Leistung aus verschiedenen Gründen verringern. Bei einer bestimmten Ergebnissatzgröße ist cursor möglicherweise immer noch vorzuziehen. Siehe unten für die Verwendung des einen oder des anderen
• Ist selectMethod= eine anwendungstransparente Einstellung für eine JDBC-Verbindung? - es ist transparent, aber es kann immer noch ihre App brechen, wenn die Speicherauslastung deutlich genug wächst, um ihr Client-System (und dementsprechend Ihren Server) zu hacken oder den Client insgesamt
• Allgemeiner, wann sollten Sie cursor verwenden vs direct? - Ich persönlich verwende cursor, wenn es um potenziell große oder anderweitig unbegrenzte Ergebnismengen geht. Der Roundtrip-Overhead wird dann amortisiert, wenn eine ausreichend große Batchgröße vorhanden ist und der Speicherbedarf des Clients voraussagbar ist. Ich verwende direct, wenn die Größe der Ergebnismenge, die ich erwarte, bekanntermaßen schlechter ist als die Batchgröße, die ich mit cursor verwende, oder in irgendeiner Weise gebunden ist, oder wenn Speicher kein Problem ist.

Answer 2

selectMethod=cursor wird verhindert, dass SQL Server verwenden Parallel Query Processing, die eine große Auswirkung auf die Leistung haben kann, zum Beispiel, wenn: (und wer nicht)

• Sie viele CPU-Kerne haben
• Sie haben Sie Ihre Datenbank durch das Partitionieren von Tabellen optimiert
• Sie viele Aggregatabfragen (sum(), count(), etc.)

laufen Schließlich

, Microsoft states folgendes:

(selectMethod=direct) bietet die schnellste Leistung, wenn die Anwendung alle Zeilen verarbeitet.

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