Я использую Java 1.6, JTDS 1.2.2 (также просто пробовал 1.2.4 безрезультатно) и SQL Server 2005 для создания CallableStatement для запуска хранимой процедуры (без параметров). Я вижу, что оболочка Java выполняет ту же хранимую процедуру на 30% медленнее, чем в SQL Server Management Studio. Я'мы запустили профилировщик MS SQL, и разница между операциями ввода-вывода невелика, поэтому я нене думаю, что этосвязанные с кэшированием плана запроса.

Хранимая процедура не принимает аргументов и не возвращает данных. Он использует серверный курсор для вычисления значений, необходимых для заполнения таблицы.

Я могу'не понимаю, как вызов хранимого процесса из Java должен добавить 30% накладных расходов, конечно же,это просто канал к базе данных, который отправляет SQL, а затем база данных выполняет его ... Может ли база данных дать приложению Java другой план запроса?

мы отправили обоимфорумы MSDNи форумы JTDS на sourceforge (тема: "в JTDS процесс хранится медленнее, чем в БД ") Мне было интересно, есть ли у кого-нибудь предложения относительно того, почему это может происходить?

Заранее спасибо,

-Джеймс

(N.B. Не бойтесь, я соберу все ответы, которые я получаю на других форумах здесь, как только я найду решение)

Фрагмент кода Java:

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.");

Я запустил SQL Server Profiler и обнаружил следующее:

Приложение Java: ЦП: 466 514 Чтений: 142 478 387 Пишет: 284 078 Продолжительность: 983 796

SSMS: процессор: 466 973 чтение: 142 440 401 запись: 280 244 продолжительность: 769 851

(Оба с DBCC DROPCLEANBUFFERS запускаются до профилирования, и оба выдают правильное количество строк)

Поэтому я пришел к выводу, что они оба выполняют одинаковые операции чтения и записи,просто то, как они это делают, отличается, как вы думаете, ребята?

Оказывается, что планы запросов значительно различаются для разных клиентов (клиент Java обновляет индекс во время вставки, которая не 't в более быстром клиенте SQL также отличается способ выполнения соединений (вложенные циклы Vs. собирать потоки, вложенные циклы Vs сканирование индекса, аааа!)). Почему это так?еще не знаю (яПерепишу, когда доберусь до сути дела)

эпилог

Я не могне заставить это работать должным образом. Я попытался гомогенизировать свойства соединения (,arithabortansi_nulls и т. д.) между клиентами Java и студии Mgmt. В итоге у двух разных клиентов были очень похожие планы запросов / выполнения (но все же с разными фактическими plan_ids). Я опубликовал краткое изложение того, что я нашелфорумы MSDN SQL Server как я обнаружил, разная производительность не только между клиентом JDBC и студией управления, но и между Microsoft 'Собственный клиент командной строки, SQLCMD, я также проверил некоторые более радикальные вещи, такие как сетевой трафик или обертывание хранимого процесса внутри другого хранимого процесса, просто для ухмылки.

У меня есть ощущение, что проблема заключается где-то в способе выполнения курсора, и это каким-то образом приводило к приостановке Java-процесса, но почему другой клиент должен вызывать это другое поведение блокировки / ожидания, когда больше ничего не работает и тот же план выполнения находится в действии, немного вне моих навыков (ям нет DBA!).

В результате я решил, что 4 дня достаточно для всехвремя тратить на что-то вроде этого, поэтому я буду неохотно кодировать вокруг него (если яЕсли честно, хранимая процедура нуждалась в перекодировании, чтобы быть более инкрементным, а не пересчитывать все данные каждую неделю в любом случае), и записать это на собственном опыте. Я'Оставлю вопрос открытым, большое спасибо всем, кто поставил свою шляпу на ринг, все это было полезно, и если кто-нибудь придумает что-нибудь еще, яЯ хотел бы услышать еще несколько вариантов ... и если кто-то найдет этот пост в результате просмотра этого поведения в их собственной среде, то, надеюсь, есть "Вот несколько советов, которые вы можете попробовать сами и надеетесь увидеть дальше, чем мы.

Я готов к моим выходным сейчас!

-Джеймс