Снижение производительности SQL Server ODBC?

Это странно, но я надеюсь, что кто-нибудь сможет мне помочь.

У меня есть вызов хранимой процедуры, выполнение которого занимает около 42 секунд - при вызове из приложения, подключенного через соединение ODBC. Однако, если я запустил тот же вызов в SSMS (Sql Server Management Studio), для выполнения потребуется всего 10 или 15 секунд… как записано трассировкой.

Это не похоже на проблему с сетью. Я передаю клиенту только около 1200 записей - и в любом случае время, которое я вам дал, было получено прямо из поля продолжительности трассировки ... поэтому SQL Server требуется в 3 или 4 раза дольше для обработки одного и того же вызова - когда выполняется через вызов ODBC. Я могу воспроизводить это снова и снова. Что более интересно, это то, что чтение и запись (взятые из трассировки) немного выше для вызова ODBC, но загрузка ЦП в 3 или 4 раза больше, чем при вызове SSMS.

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

Мы используем SQL Server 2005

Есть идеи о том, что здесь происходит?


odbc sql-server performance stored-procedures sql-server-2005
person Clinemi    schedule 14.02.2011    source источник
comment
Возможно параметр нюхать. Проверьте оба плана выполнения на предмет различий. В SSMS, вероятно, будут отличаться некоторые set параметры, что означает, что он не будет использовать план из другого соединения, вместо этого он получит новый план, который может быть более подходящим для этого набора параметров.   -  person Martin Smith    schedule 15.02.2011

Ответы (2)


arrow_upward
1
arrow_downward

Возможно, вы извлекаете данные из «подогретого» кеша в SSMS. Попробуйте запустить его с этими строками перед сохраненным вызовом процесса в SSMS и посмотрите, будет ли он работать так же быстро:

CHECKPOINT
GO
DBCC DROPCLEANBUFFERS
GO
DBCC FREEPROCCACHE
GO

-- Your SQL begins here

Как говорит @Martin, это также может быть результатом обнюхивания параметров. Вот хороший пост SO, в котором говорится об этом.

person Abe Miessler    schedule 14.02.2011
comment
Вау ... это имело огромное значение! Похоже, что вычистил все кеши. Мой запрос SSMS занял больше минуты (как и следовало ожидать), но соединение ODBC теперь намного быстрее! Что там дает? - person Clinemi; 15.02.2011
comment
@Clinemi - Если очистка кеша планов решила проблему, я бы определенно заподозрил обнюхивание параметров. - person Martin Smith; 15.02.2011
comment
Да, очистка наличных должна была продлить время для обоих. Вы передаете одни и те же параметры в хранимую процедуру каждый раз при тестировании? - person Abe Miessler; 15.02.2011
comment
Кроме того, если вы очистили кеш, запустили процедуру через SSMS, а затем повторно запустили ее через ODBC, то запуск ODBC был бы против разогретого кеша. - person Abe Miessler; 15.02.2011
comment
Я считаю, что это определенно анализ параметров. После выполнения приведенного выше кода я сначала запустил вызов SSMS - это перестроило план запроса и заняло много времени. Однако после этого и вызовы ODBC, и SSMS были быстрыми. SSMS все еще составляет около 10-15 секунд, но ODBC - около 4 секунд! Я использовал те же параметры для этих вызовов, и изменение параметров может изменить ситуацию, но симптомы выглядят как перехват параметров. Спасибо! - person Clinemi; 15.02.2011

arrow_upward
0
arrow_downward

Похоже на время первого подключения. Можете ли вы воспроизвести проблему с двумя звонками и только с одним разом во втором? Возможно, также стоит синхронизировать вызов с другой библиотекой, чтобы увидеть, не отличается ли это.

person Preet Sangha    schedule 14.02.2011