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

Question

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

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

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

Answer 1

Это то, что я узнал из своего исследования.

.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 для выбора наиболее эффективного плана запроса. При изменении одного из параметров подключения оптимизатор запросов может выбрать другой план, и в этом случае он явно выбрал плохой.

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

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

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

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

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

Answer 2

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

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

Answer 3

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

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

Answer 4

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

Answer 5

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

объявите @option int

set @option = @@ options | 64

exec sp_configure 'user options', @ Вариант

RECONFIGURE

Answer 6

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

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

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

Answer 7

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

Answer 8

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

DataAdapter.SelectCommand.CommandTimeout = 120;