Сохраненное выполнение proc на 30% медленнее через Java по сравнению с выполнением непосредственно на базе данных

Вы можете подключить профилировщик и отслеживать события SQL: BatchCompleted и SP: завершено с фильтром по продолжительности> 1000. Запустите из вашего Java-клиента и из SSMS. Сравните чтение и запись двух событий (Java и SSMS). Они существенно отличаются? Это может указывать на существенно разные пути или планы выполнения со значительной разницей в вводе-выводе.

Также попробуйте захватить событие Showplan XML из двух и сравнить планы (сохраните событие как .sqlplan) файл, откройте его в SSMS для удобного анализа). Есть ли у них похожие планы? Есть ли резкие различия между оценками и фактическими данными (строки, перемотки, перемотки)? У них одинаковая степень параллелизма? Планы также можно получить из представления sys.dm_exec_requests .

Возникают ли какие-либо предупреждающие события, например Статистика по отсутствующим столбцам , Предупреждения о сортировке , Предупреждение о хешировании , Предупреждения о выполнении , ] Blocked Process ?

дело в том, что в вашем распоряжении целый арсенал инструментов расследования. Как только вы найдете основную причину разницы, вы можете отследить ее до того, чем отличаются настройки вашей среды Java и среды SSMS (ADO.Net SqlClient). Такие вещи, как уровень изоляции транзакции по умолчанию, настройки ANSI и т. Д.

Дело в том, что в вашем распоряжении целый арсенал инструментов расследования. Как только вы найдете основную причину разницы, вы можете отследить ее до того, чем отличаются настройки вашей среды Java и среды SSMS (ADO.Net SqlClient). Такие вещи, как уровень изоляции транзакции по умолчанию, настройки ANSI и т. Д.

Дело в том, что в вашем распоряжении целый арсенал инструментов расследования. Как только вы найдете основную причину разницы, вы можете отследить ее до того, чем отличаются настройки вашей среды Java и среды SSMS (ADO.Net SqlClient). Такие вещи, как уровень изоляции транзакции по умолчанию, настройки ANSI и т. Д.

Включает ли случай Java передачу результатов на сервер Java (накладные расходы сети) плюс некоторая обработка Java? 12-минутный запрос может дать довольно большой объем данных.

Если вы смотрите на профилировщик и нет разницы между исполнениями, тогда разница должна быть клиентские системы.

Кажется, что 4 минуты - это слишком много времени для подготовки оператора к отправке, поэтому 12-минутное ожидание должно вызвать какой-то другой эффект - не знаю, что это такое.

Проверка: ваша проблема в том, что два приложения (SSMS, Java) делают один и тот же идентичный вызов SQL Server, а SQL Server действует по-разному для каждого? Если так, я сталкиваюсь с подобными вещами каждый год или два, и они травмируют мой мозг на несколько дней.

Однажды я в конечном итоге изолировал каждый вызов процесса и регистрировал все для всего процесса в Profiler. В конце концов я заметил, что событие Login (в TextData) показало множество информации, например:

-- network protocol: TCP/IP
set quoted_identifier on
set arithabort off
set numeric_roundabort off
set ansi_warnings on
set ansi_padding on
set ansi_nulls on
set concat_null_yields_null on
set cursor_close_on_commit off
set implicit_transactions off
set language us_english
set dateformat mdy
set datefirst 7
set transaction isolation level read committed

Событие «Existing Connection» также покажет эту информацию, но иногда сразу же последующие вызовы (пакеты, RPC, я не помню только сейчас) отправлены [ ISQL или OSQL сделали это, я думаю ], чтобы немедленно сбросить некоторые из них - Arithabort и Quoted_Identifier кажутся фаворитами, и другие параметры SET также изменяются в зависимости от настроек или требований любых протоколов подключения, которые использует интерфейс базы данных вашего приложения.

Еще один: некоторые настройки сохраняются как атрибуты процедуры во время «создания», а другие учитываются в во время компиляции. С одной стороны, значения SET вашего соединения могут быть перезаписаны конфигурацией, сохраненной во время создания процедуры; с другой стороны, ваши два соединения могут настолько различаться, что для одной процедуры создаются два плана выполнения. (Вся эта информация после достаточного исследования доступна в системных таблицах и DMV.)

Короче говоря, мне кажется, что неясности SQL сбивают вас с толку. По сей день я ненавижу все эти настройки гумба. То, что ниже моего уведомления, продолжает с ними возиться [я имею в виду, правда, какой дурак установил бы implicit_transaction для пула соединений на? Но однажды они это сделали ...] и трудно строить структуры, когда основа (правила) постоянно меняются из-под вас. В конце концов, помните, что этот парень сказал про постройку замков на болоте ...

Почему вы не можете просто использовать трубы ?

Например, для автоматического автоматического принятия используйте да , который просто выводит неверный поток y .

yes | rm *.txt

_{(источник: wikimedia.org )}

Набор кода и эта запись блога предоставляют подробные способы повышения производительности приложения.

Скомпилированный запрос повысит производительность приложения, но не имеет ничего общего с ASP.NET MVC. Это ускорит каждое приложение БД, так что дело не в MVC.

Извините, я не нашел правильного ответа на это, поэтому я не хочу выделять ни один из них как правильный, поэтому я отмечу этот ответ как правильный и желаю всем удачи, кто столкнется с чем-то подобным!

Знаете ли вы, что Microsoft поставляет драйверы JDBC для своих баз данных?

Они могут быть более эффективными.

Очевидно ... вы, возможно, уже решили проблему.

Я вспоминаю, что некоторое время назад у меня была аналогичная проблема, потому что JTDS незаметно преобразовывал строковый параметр в Unicode или что-то подобное. В результате этого преобразования SQL Server не смог использовать индекс, который использовался, когда мы запускали сохраненную процедуру из SSMS.

HIH