Время ожидания запроса из веб-приложения, но отлично работает из студии управления

Это вопрос, который я задал на другом форуме, который получил несколько достойных ответов, но я хотел посмотреть, есть ли у кого-нибудь здесь более глубокие идеи.

Проблема в том, что одна из ваших страниц в веб-приложении блокируется по времени, когда он попадает на вызов хранимой процедуры, поэтому вы используете Sql Profiler или журналы трассировки приложения, чтобы найти запрос, и вставляете его в Management Studio для расчета наша почему работает медленно Но вы запускаете его оттуда, и он просто горит, возвращаясь менее чем за секунду каждый раз.

В моем конкретном случае использовались ASP.NET 2.0 и Sql Server 2005, но я думаю, что проблема может относиться к любой системе СУБД.

13.08.2008 15:49:41
У меня была та же проблема, и stackoverflow.com/questions/250713/… решил мою проблему
David 16.06.2010 20:22:25
8 ОТВЕТОВ

Попробуйте изменить значение времени ожидания SelectCommand:

DataAdapter.SelectCommand.CommandTimeout = 120;
-1
13.08.2008 15:52:35
РЕШЕНИЕ

Это то, что я узнал так далеко от моих исследований.

.NET отправляет параметры подключения, которые не совпадают с настройками, которые вы получаете при входе в Management Studio. Вот что вы увидите, если понюхаете соединение с Sql Profiler:

-- network protocol: TCP/IP  
set quoted_identifier off  
set arithabort off  
set numeric_roundabort off  
set ansi_warnings on  
set ansi_padding on  
set ansi_nulls off  
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  

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

В этом случае я попробовал каждый параметр отдельно, после отключения и повторного подключения, и обнаружил, что изменение arithabort с выключенного на включенное уменьшило проблему запроса с 90 секунд до 1 секунды.

Наиболее вероятное объяснение связано с анализом параметров, который Sql Server использует для выбора наиболее эффективного плана запроса. При изменении одного из параметров подключения оптимизатор запросов может выбрать другой план, и в этом случае он явно выбрал плохой.

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

Есть ли в настройке arithabort что-то еще, что в некоторых случаях может привести к медленному выполнению запроса?

Решение казалось простым: просто поместите set arithabort в верхнюю часть хранимой процедуры. Но это может привести к противоположной проблеме: изменить параметры запроса, и внезапно он будет работать быстрее с «выключено», чем «включено».

В настоящее время я запускаю процедуру «с перекомпиляцией», чтобы убедиться, что план обновляется каждый раз. Это нормально для этого конкретного отчета, поскольку для его перекомпиляции может потребоваться секунда, и это не слишком заметно в отчете, для возврата которого требуется 1-10 секунд (это монстр).

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

27
4.04.2012 14:38:01
+1 Получение этих настроек из SQL Profiler и вставка их в Management Studio - отличный совет и помог мне загрузить.
Alex Humphrey 10.05.2012 11:00:25
+1 SET ARITHABORT OFF было достаточно, чтобы мой запрос на тайм-аут начал работать прекрасно.
Spud 2.01.2013 04:23:07
@ eric-z-beard Где вы положили эти значения? Внутри SP или до EXEC sp_wh независимо от .NET
djandreski 4.03.2014 11:03:19

сначала проверьте это в промежуточном окне, измените его на уровне сервера для сервера sql

объявить @option int

установить @option = @@ options | 64

exec sp_configure 'user options', @option

RECONFIGURE

1
13.08.2008 16:19:24

Вы уже включили трассировку ASP.NET? У меня был случай, когда проблема заключалась не в самой хранимой процедуре SQL, а в том, что процедура возвращала 5000 строк, а приложение пыталось создать элементы ListItems с данными из этих 5000 элементов, что вызывало проблему.

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

2
13.08.2008 18:22:10

Вы можете попробовать использовать команду sp_who2, чтобы увидеть, что делает рассматриваемый процесс. Это покажет вам, заблокирован ли он другим процессом или использует слишком много процессорного времени и / или времени.

0
9.09.2008 01:35:47

Та же проблема, что у меня была с службами отчетов SQL. Попробуйте проверить тип переменных, я отправлял переменные другого типа в SQL, например, отправлял varchar туда, где он должен быть целым числом, или что-то в этом роде. После того, как я синхронизировал типы переменных в Reporting Service и в хранимых процедурах на SQL, я решил проблему.

1
15.03.2011 06:59:08

У меня были похожие проблемы. Попробуйте установить параметр with WITH RECOMPILE в sproc create, чтобы заставить систему пересчитывать план выполнения при каждом его вызове. Иногда процессор запросов запутывается в сложных хранимых процедурах с множеством ветвлений или операторов case и просто использует действительно неоптимальный план выполнения. Если кажется, что это «решает» проблему, вам, вероятно, потребуется проверить актуальность статистики и / или устранить проблему.

Вы также можете подтвердить это, профилировав sproc. Когда вы выполняете его из SQL Managment Studio, как сравнивается IO с тем, когда вы профилируете его из приложения ASP.NET. Если их очень много, он просто усиливает, что это тянет плохой план выполнения.

6
1.11.2008 18:01:36

У нас была та же проблема, и вот что мы узнали.

размер журнала нашей базы данных оставался по умолчанию (814 МБ), а автоматический рост составил 10%. На сервере максимальная память сервера также сохранялась по умолчанию (2147483647 МБ).

Когда наш журнал заполнился и его нужно было увеличить, он использовал всю память сервера, и для запуска кода не осталось ничего, поэтому время истекло. В итоге мы установили начальный размер файла журнала базы данных равным 1 МБ, а максимальный объем памяти сервера - 2048 МБ. Это сразу решило нашу проблему. Конечно, вы можете изменить эти два свойства в соответствии с вашими потребностями, но это идея для тех, кто сталкивается с проблемой тайм-аута при выполнении хранимой процедуры с помощью кода, но она работает очень быстро в SSMS, и приведенные выше решения не помогают.

0
25.11.2013 18:02:38