Ich verwende Java 1.6, JTDS 1.2.2 (habe auch 1.2.4 ohne Erfolg ausprobiert) und SQL Server 2005, um eine CallableStatement zum Ausführen einer gespeicherten Prozedur (ohne Parameter) zu erstellen. Ich sehe, dass der Java-Wrapper dieselbe gespeicherte Prozedur 30% langsamer ausführt als SQL Server Management Studio. Ich habe den MS SQL-Profiler ausgeführt und es gibt kaum Unterschiede bei den E / A-Vorgängen zwischen den beiden Prozessen. Daher glaube ich nicht, dass dies mit dem Zwischenspeichern von Abfrageplänen zusammenhängt.

Der gespeicherte Prozess akzeptiert keine Argumente und gibt keine Daten zurück. Es verwendet einen serverseitigen Cursor, um die Werte zu berechnen, die zum Auffüllen einer Tabelle erforderlich sind.

Ich kann nicht sehen, wie der Aufruf eines gespeicherten Prozesses aus Java einen Overhead von 30% verursachen sollte. Sicherlich ist es nur eine Pipe zur Datenbank, die SQL herunter sendet und dann von der Datenbank ausgeführt wird. Könnte die Datenbank Java bereitstellen App einen anderen Abfrageplan?

Ich habe auf beiden gepostetdie MSDN-ForenIch habe mich gefragt, ob jemand Vorschläge dazu hat, warum dies passieren könnte.

Danke im Voraus,

-James

(NB. Fürchte dich nicht, ich werde alle Antworten, die ich in anderen Foren bekomme, hier zusammenstellen, sobald ich die Lösung gefunden habe.)

Java-Code-Snippet:

sLogger.info("Preparing call...");
stmt = mCon.prepareCall("SP_WB200_POPULATE_TABLE_limited_rows");
sLogger.info("Call prepared.  Executing procedure...");
stmt.executeQuery();
sLogger.info("Procedure complete.");

Ich habe SQL Profiler ausgeführt und Folgendes festgestellt:

Java-App: CPU: 466.514 Liest: 142.478.387 Schreibt: 284.078 Dauer: 983.796

SSMS: CPU: 466,973 Liest: 142,440,401 Schreibvorgänge: 280,244 Dauer: 769,851

(Beide mit DBCC DROPCLEANBUFFERS werden vor der Profilerstellung ausgeführt und produzieren die richtige Anzahl von Zeilen.)

Mein Fazit ist also, dass beide die gleichen Lese- und Schreibvorgänge ausführen. Es ist nur so, dass die Art und Weise, wie sie dies tun, unterschiedlich ist. Was denkt ihr?

Es stellt sich heraus, dass die Abfragepläne für die verschiedenen Clients erheblich unterschiedlich sind (der Java-Client aktualisiert einen Index während einer Einfügung, die sich nicht im schnelleren SQL-Client befindet, und die Art und Weise, wie Joins ausgeführt werden, ist unterschiedlich (verschachtelte Schleifen Vs. Ströme sammeln, verschachtelte Schleifen Vs Index-Scans, argh!)). Warum das so ist, weiß ich noch nicht.

Epilog

Ich konnte das nicht richtig zum Laufen bringen. Ich habe versucht, die Verbindungseigenschaften zu homogenisieren (arithabort, ansi_nulls etc) zwischen den Java und Mgmt Studio Clients. Es stellte sich heraus, dass die beiden verschiedenen Clients sehr ähnliche Abfrage- / Ausführungspläne hatten (jedoch immer noch mit unterschiedlichen tatsächlichen plan_ids). Ich habe eine Zusammenfassung dessen gepostet, was ich gefunden habedie MSDN SQL Server-Foren Da sich die Leistung nicht nur zwischen einem JDBC-Client und Management Studio, sondern auch zwischen dem Microsoft-eigenen Befehlszeilen-Client SQLCMD unterscheidet, überprüfte ich auch einige radikalere Dinge wie den Netzwerkverkehr oder das Einschließen des gespeicherten Procs in einen anderen gespeicherten Proc, nur für grinst.

Ich habe das Gefühl, dass das Problem irgendwo in der Art und Weise liegt, wie der Cursor ausgeführt wurde, und dass der Java-Prozess irgendwie angehalten wurde, aber warum sollte ein anderer Client dieses andere Sperr- / Warteverhalten hervorrufen, wenn nichts anderes ausgeführt wird? und der selbe Ausführungsplan ist in Betrieb, geht ein wenig über meine Fähigkeiten hinaus (ich bin kein DBA!).

Aus diesem Grund habe ich entschieden, dass 4 Tage genug Zeit für jemanden sind, der etwas davon verschwenden möchte. Ich werde es daher widerwillig umschreiben (wenn ich ehrlich bin, musste die gespeicherte Prozedur neu codiert werden, um inkrementeller zu sein als neu - Berechnen Sie ohnehin jede Woche alle Daten), und geben Sie diese an, um Erfahrungen zu sammeln. Ich lasse die Frage offen, ein großes Dankeschön an alle, die ihren Hut in den Ring gesteckt haben, es war alles nützlich, und wenn jemand etwas anderes findet, würde ich gerne weitere Optionen hören ... und wenn jemand etwas findet Wenn Sie diesen Beitrag als Ergebnis des Sehens dieses Verhaltens in ihrer eigenen Umgebung sehen, dann gibt es hoffentlich einige Hinweise, die Sie selbst ausprobieren können und die Sie hoffentlich weiter sehen können als wir.

Ich bin jetzt bereit für mein Wochenende!

-James