Сбой хранимой процедуры для конкретного пользователя - PullRequest
3 голосов
/ 07 ноября 2008

У меня есть хранимая процедура, которая постоянно завершается ошибкой с сообщением об ошибке «Истекло время ожидания» для конкретного пользователя.

Все остальные пользователи могут нормально вызывать sp, и даже я могу нормально вызывать sp, используя Query Analyzer - он завершается всего за 10 секунд. Однако в случае данного пользователя журналы показывают, что ASP всегда зависает в течение примерно 5 минут, а затем прерывается с истечением времени ожидания.

Я вызываю со страницы ASP примерно так: "EXEC SP_TV_GET_CLOSED_BANKS_BY_USERS '006111'"

Кто-нибудь знает, как диагностировать проблему? Я уже пробовал смотреть на тупики в БД, но не нашел.

Спасибо

Ответы [ 5 ]

5 голосов
/ 09 ноября 2008

Некоторые мысли ...

Чтение комментариев показывает, что причиной является проблема с прослушиванием параметров.

  • Для других пользователей кэшированный план достаточно хорош для параметра, который они отправляют
  • Для этого пользователя кэшированный план, вероятно, неверен

Это может произойти, если у этого пользователя гораздо больше строк, чем у других пользователей, или есть строки в другой таблице (поэтому лучше будет поиск / сканирование другой таблицы / индекса)

Чтобы проверить анализатор параметров:

  • использовать RECOMPILE (временно) при вызове или по умолчанию. Это может быть медленно для сложного запроса
  • Перестройте индексы (или просто статистику) по истечении времени ожидания и повторите попытку. Это делает недействительными все кэшированные планы

Исправить: Маска параметр

DECLARE @MaskedParam varchar(10)
SELECT @MaskedParam = @SignaureParam

SELECT...WHERE column = @MaskedParam

Просто гуглите "Обнаружение параметров" и "Маскирование параметров"

0 голосов
/ 08 ноября 2008

Хорошо, я мог бы предложить вам использовать SQL Server Profiler и открыть новый сеанс. Вызовите вашу хранимую процедуру со страницы ASP и посмотрите, что происходит. Хотя это может не решить вашу проблему, оно, безусловно, может послужить отправной точкой для вашего собственного «расследования».

0 голосов
/ 07 ноября 2008

Звучит как проблема с блокировкой ..

Также убедитесь, что у этого пользователя есть права на выполнение и права на чтение в SQL Server

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

Джефф сделал отличный пост о своем опыте с этим и stackoverflow. http://www.codinghorror.com/blog/archives/001166.html

0 голосов
/ 08 ноября 2008

Пара вещей для проверки:

  1. Это происходит только на компьютере конкретного пользователя? Может ли он попробовать это из другого машина? - это может быть проблема конфигурации клиента.
  2. Можете ли вы захватить фактическую строку, которую запускает этот конкретный пользователь, и запустить ее со страницы ASP? Возможно, пользователь выполняет SP так, что он генерирует либо цикл, либо массивную загрузку данных.
  3. Наконец, если вы используете внутриорганизационное приложение, возможно, что права вашего конкретного пользователя отличаются от прав других пользователей. Вы можете сравнить их на уровне Active Directory.

Теперь я могу порекомендовать коммерческое программное обеспечение, которое определенно решит вашу проблему. Он записывает сквозные транзакции и анализирует конкретные сбои. Но я не хочу размещать рекламу на этом форуме. Если хотите, напишите мне, и я объясню больше.

0 голосов
/ 07 ноября 2008

Я думаю, что для ответа на ваш вопрос нам может потребоваться немного больше информации.

Например, вы используете Active Directory для аутентификации ваших пользователей? Вы использовали SQL-профилировщик для расследования? Похоже, это может быть проблема с аутентификацией, когда у SQL Server возникают проблемы с аутентификацией этого конкретного пользователя.

...