Asp.net sql server 2005 проблема тайм-аута

Question

HI Мы получаем тайм-ауты в нашем приложении asp.net. Мы используем SQL Server 2005 в качестве базы данных. Запросы выполняются очень быстро в анализаторе запросов. Однако, когда мы проверяем время через профилировщик, оно показывает время, во много раз превышающее то, что мы получаем в анализаторе запросов. (неоправданный грех) Любая помощь очень ценится

спасибо

Мы находимся в САН Очищены счетчики. Новые счетчики

ASYNC_NETWORK_IO 540 9812 375 78

WRITELOG 70 1828 328 0

Тайм-аут происходит только на определенном SP, который является определенным набором параметров. если мы изменим параметры и откроем приложение, оно будет работать нормально. Мы запустили профилировщик и обнаружили, что в профилировщике появляется оператор SP batchcompleted после истечения времени ожидания на стороне asp.net. Если перезапустить сервер, все работает нормально

если удалить план из кеша, приложение будет работать нормально. Однако мы учли параметр нюхание в sp. в чем еще может быть причина

Answer 1

Запустите следующий скрипт для создания этого хранимого процесса:

CREATE PROC [dbo].[dba_SearchCachedPlans]
    @StringToSearchFor VARCHAR(255)
AS
/*---------------------------------------------------------------------- 
Purpose: Inspects cached plans for a given string. 
------------------------------------------------------------------------ 
Parameters: @StringToSearchFor - string to search for e.g. '%<MissingIndexes>%'. 
Revision History: 
         03/06/2008  Ian_Stirk@yahoo.com Initial version 
Example Usage: 
1. exec dba_SearchCachedPlans '%<MissingIndexes>%'
2. exec dba_SearchCachedPlans '%<ColumnsWithNoStatistics>%'
3. exec dba_SearchCachedPlans '%<TableScan%'
4. exec dba_SearchCachedPlans '%CREATE PROC%MessageWrite%'    
-----------------------------------------------------------------------*/ 
BEGIN 
    -- Do not lock anything, and do not get held up by any locks. 
    SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED 

    SELECT TOP 100
            st.TEXT AS [SQL],
            cp.cacheobjtype,
            cp.objtype,
            DB_NAME(st.dbid) AS [DatabaseName],
            cp.usecounts AS [Plan usage],
            qp.query_plan
    FROM    sys.dm_exec_cached_plans cp
            CROSS APPLY sys.dm_exec_sql_text(cp.plan_handle) st
            CROSS APPLY sys.dm_exec_query_plan(cp.plan_handle) qp
    WHERE   CAST(qp.query_plan AS NVARCHAR(MAX)) LIKE @StringToSearchFor
    ORDER BY cp.usecounts DESC 
END 

Затем выполните:

exec dba_SearchCachedPlans '%<MissingIndexes>%'

И посмотрите, нет ли у вас рекомендуемых индексов.

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

Answer 2

Если бы я сделал предположение, я бы предположил, что фоновая загрузка базы данных с веб-сервера повышает блокировку и вызывает замедление всего процесса. Затем вы берете запрос большого размера и запускаете его, что приводит к конфликту блокировок (и ресурсов).

Я вижу это ВСЕ ВРЕМЯ , когда компании жалуются на проблемы с производительностью своих клиент-серверных приложений при переходе с одного SQL-сервера на кластер. В веб-мире мы сталкиваемся с этими проблемами гораздо раньше.

Решение (чаще всего) для блокировки проблем с одним из следующих: * Рефакторинг ваших запросов, чтобы они работали лучше (например, сохраняя SCOPE_IDENTITY вместо 5-кратного вызова) * Используйте оператор NO LOCK везде, где это имеет смысл.

EDIT:

Также попробуйте просмотреть сервер с новой SQL Management Studio 2008 'Activity Monitor' . Вы можете найти его, щелкнув правой кнопкой мыши на своем сервере и выбрав «Монитор активности».

• Перейдите в раздел «Процессы» и посмотрите, сколько процессов «ожидают». Ваше время ожидания должно быть около-0. Если вы видите много материала в разделе «Тип ожидания», опубликуйте снимок экрана, и я могу дать вам представление о том, каков будет следующий шаг.
• Перейдите в раздел Resource Waits и посмотрите, как там выглядят цифры. Ваши официанты всегда должны быть около -0.
• И «Недавние дорогие запросы» - это круто, чтобы узнать, что вы можете сделать, чтобы улучшить свою общую производительность.

Редактировать # 2:

Насколько медленнее это? Кажется, ваша SAN занимает около 10 секунд, но если вы говорите 20 секунд против 360 секунд, то это не будет подходящим, и не будет никаких ожиданий блокировок, поэтому я предполагаю, что я рисую пробел. Если разница между 1 и 10 секундами, значит, это связано с сетью.

Answer 3

Взгляните на раздел обсуждения в следующей статье: http://www.sqlservercentral.com/articles/Performance/63638/

Спасибо Ian

Answer 4

У меня были похожие проблемы, и в моем случае это было связано с перекомпиляцией SP. В частности, я использовал временные таблицы против табличных переменных.

Answer 5

У меня была точно такая же проблема пару раз раньше. Мне показалось, что это произошло, когда конкретный пользователь был на сайте, когда он был развернут. Когда этот пользователь запускает определенные хранимые процедуры со своим идентификатором, он истекает. Когда другие запускали его, или я запускал его из БД, он запускался мгновенно. У нас были наши DBA, которые смотрели все, что могли, и у них никогда не было ответа. В конце концов, все было исправлено всякий раз, когда я повторно развертывал сайт, а пользователь еще не вошел в систему.

Answer 6

У меня нет ответа для вас, потому что я не гуру. Но я помню, что недавно читал в некоторых блогах по SQL, что в SQL 2008 есть некоторые дополнительные вещи, которые вы можете добавить в запрос / хранимую процедуру, чтобы он вычислял вещи по-другому. Я думаю, что одну вещь, которую вы могли бы попытаться найти, называется «подсказки». Кроме того, то, как SQL использует текущую «статистику», также имеет значение. Посмотри на это. И то, как план выполнения генерируется только для первого запуска - если этот план не работает с другими значениями параметров, потому что было бы огромное различие в том, что нужно искать / возвращать, он может представить такое поведение, я думаю.

Извините, я не могу быть более полезным. Я просто не могу справиться с производительностью SQL Server на этом уровне. Бьюсь об заклад, если бы вы спросили кого-то вроде Брент Озар , он мог бы указать вам правильное направление.