JDBC-Verbindung zu sehr damit beschäftigt SQL 2000: select = Cursor vs select = direct?

Question

In dem Prozess zu helfen, ein App Dev-Team mit Performance-Problemen auf einem SQL 2000 Server zu versuchen (aus einem Bündel von Java-Anwendungen auf separaten Applikationsserver), lief ich eine SQL-Trace und entdecken, dass alle Anrufe auf die Datenbank sind voller API Server Cursor-Anweisungen (sp_cursorprepexec, sp_cursorfetch, sp_cursorclose).

Sieht aus wie sie spezifizieren einige Verbindungszeichenfolgen Eigenschaften, dass Kraft der Verwendung von serverseitige Cursors, nur 128 Zeilen von Daten zu einem Zeitpunkt abrufen: (von http://msdn.microsoft.com/en-us/library/Aa172588 )

  

Wenn die API Cursor Attribute oder   Eigenschaften sind auf etwas anderes gesetzt   als die Standardwerte, die OLE-DB   Anbieter für SQL Server und SQL   Server-ODBC-Treiber verwenden API-Server   Cursor statt Standardresultset   Sets. Jeder Aufruf einer API-Funktion   dass ruft Zeilen erzeugt ein   Roundtrip zum Server zu holen, die   Zeilen aus den API-Server-Cursor.

UPDATE : Die Verbindungszeichenfolge in Frage ist eine JDBC-Verbindung String-Parameter, selectMethod=cursor (die die serverseitige Cursors ermöglicht wir oben besprochen) vs alternativen selectMethod=direct. Sie wurden als ihre Standard-Verbindungszeichenfolge aus allen Apps mit selectMethod=cursor.

Aus meiner DBA Perspektive, die nur ärgerlich ist (es die Spur clutters mit nutzlosen Plunder nach oben), und (ich würde spekulieren) ist was viele zusätzliche App-to-SQL-Server-Rundreisen, die Gesamtleistung zu reduzieren.

Sie haben anscheinend Test (nur eine von etwa 60 verschiedenen App-Verbindungen) zu selectMethod=direct ändern, aber einige Probleme erfahren (von denen ich keine Details) und sind über die Anwendung Bruch betroffen.

Also, meine Fragen sind:

• kann mit selectMethod=cursor niedriger Anwendungsleistung, wie ich versucht habe, zu argumentieren? (Durch die Anzahl der Umläufe notwendig auf einem SQL-Server erhöht, dass bereits eine sehr hohe Abfragen / s)
• Sie selectMethod= eine anwendungs ??transparente Einstellung auf einer JDBC-Verbindung? Könnte dies ihre App brechen, wenn wir es ändern?
• Allgemeiner gesagt, wann sollten Sie cursor vs direct verwenden?

Auch Quer gebucht SF .

Bearbeiten :. Empfangene tatsächliche technische Details, die ein wesentliches bearbeiten Titel, Frage rechtfertigen und Tags

Bearbeiten : hinzugefügt Huld. Auch hinzugefügt Prämie auf die SF Frage (diese Frage auf das Anwendungsverhalten fokussiert ist, wird die SF Frage konzentrierte sich auf SQL-Performance.) Vielen Dank !!

Answer 1

Kurz gesagt,

1. selectMethod=cursor
   • erfordert theoretisch mehr serverseitige Ressourcen als selectMethod=direct
   • nur Lasten höchstens Batch-size Datensätze in Client-Speicher sofort, was zu einem besser vorhersagbaren Client Speicherbedarf
2. selectMethod=direct
   • theoretisch erfordert weniger serverseitige Ressourcen als selectMethod=cursor
   • wird die gesamte Ergebnismenge in Client-Lese-Speicher (es sei denn, der Fahrer nativ asynchronen Ergebnismenge Retrieval unterstützt), bevor die Client-Anwendung es iterieren kann; dies kann auf zwei Arten reduziert Leistung :
     1. reduzierte Leistung mit großen Ergebnismengen, wenn die Client-Anwendung wie zum Stoppen der Verarbeitung in einer solchen Art und Weise geschrieben, nachdem nur einen Bruchteil der Ergebnismenge durchlaufen (mit direct es bereits die Kosten für die Beschaffung von Daten gezahlt hat es im Wesentlichen weg werfen; mit cursor wird der Abfall auf höchstens begrenzt Batch-size - 1 Reihe - der vorzeitige Beendigung Zustand wahrscheinlich in SQL umcodiert sowieso zB als SELECT TOP oder Fensterfunktionen)
     werden soll
     2. reduzierte Leistung mit großen Ergebnismengen wegen der möglichen Garbage Collection und / oder Out-of-Memory-Probleme im Zusammenhang mit einem erhöhten Speicherbedarf

Insgesamt

• kann mit selectMethod=cursor geringerer Leistung Anwendung - entweder Methode kann die Leistung senken, aus verschiedenen Gründen. Ab einem gewissen resultset Größe kann cursor noch vorzuziehen. Siehe unten für die, wenn man verwenden oder die andere
• Is selectMethod= eine anwendungs ??transparente Einstellung auf einer JDBC-Verbindung - es ist transparent, aber es kann immer noch ihre App brechen, wenn die Speicherauslastung deutlich genug wächst ihr Client-System Schwein (und entsprechend Ihr Server) oder den Client völlig abstürzen
• Allgemeiner gesagt, wann sollten Sie cursor vs direct verwenden - ich persönlich cursor verwenden, wenn mit potentiell großen oder sonst unbegrenzten Ergebnismengen zu tun. Diese Rundkopf amortisiert dann eine ausreichend große Losgröße gegeben, und mein Klient Speicherbedarf ist vorhersehbar. Ich benutze direct, wenn die Größe des Ergebnisses gesetzt ich bekannt erwarten ist, dass sie minderwertig, was auch immer Losgröße ich mit cursor verwenden, oder in irgendeiner Weise gebunden ist, oder wenn der Speicher ist kein Problem.

Answer 2

selectMethod=cursor wird verhindert, dass SQL Server verwenden, parallele Abfrageverarbeitung , die eine große Auswirkung auf die Leistung, zum Beispiel haben kann, wenn:

• Sie haben viele CPU-Kerne (und wer nicht?)
• Sie haben Ihre Datenbank durch das Partitionieren von Tabellen optimiert
• Sie werden viele Aggregate Ausführen von Abfragen (sum(), count() usw.)

Schließlich Microsoft Staaten die folgende:

  

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

Sie sollten auf jeden Fall versuchen und sehen, ob selectEinstellung = Direkt macht einen Unterschied für Sie.