SQL - вызов «reader.NextResult» вызывает длительную задержку

Question

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

Я ставлю секундомер на выполнение и чтение данных, и каждый раз это занимает 6-7 секунд. Я рассчитал время выполнения хранимой процедуры, ожидая, что это займет все время. Это не было - это заняло 30 мс или около того.

Поэтому я установил таймеры вокруг каждого из ~ 20 наборов результатов. Каждый «блок» занимал очень мало времени (<10 мс), за исключением одного в середине обработки, что занимало 5-6 секунд. После дальнейших исследований я обнаружил, что это вызов «reader.NextResult ()», который занимал все время. Эта длительная задержка происходит каждый раз в одном и том же месте. </p>

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

Как мне это интерпретировать? Отправляет ли мне SQL наборы результатов по мере их получения, и может ли рассматриваемый набор быть проблемной областью в моем SQL-запросе? Или что-то еще может быть причиной задержки?

EDIT:

Спасибо за ответ и комментарии - я использую SQL Server и .NET

Что меня больше всего интересовало, так это то, ПОЧЕМУ моя задержка происходит при вызове NextResult (). Будучи новичком в разработке SQL, я предполагал, что задержка из-за длительного выполнения хранимой процедуры будет отображаться в моем приложении во время ожидания возврата вызова «ExecuteReader ()». Теперь кажется, что SQL начнет возвращать данные ДО того, как запрос будет завершен, и если будет задержка, он задержит вызов NextResult ().

Я начал думать, что моя задержка была в хранимой процедуре. Когда вызов ExecuteReader () вернулся быстро, я подумал, что моя задержка заключалась в обработке кода читателем. Когда задержка закончилась вызовом NextResult (), я был в замешательстве. Теперь я вернулся к рассмотрению хранимой процедуры.

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

Answer 1

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

Это означает, что вы можете начать видеть результаты в своем приложении .Net, прежде чем будет выполнен весь сохраненный процесс.

Возможно, узким местом является хранимая процедура, запустите трассировку сервера SQL и отследите все операторы, выполняемые внутри хранимой процедуры (определите длительности). Вы сможете отследить точное утверждение в процедуре, которое является медленным, и вы также сможете найти параметры, передаваемые в процедуру, чтобы вы могли проверить это в Query Analyzer и посмотреть на план.

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

Answer 2

Ответ будет зависеть от того, какую СУБД вы используете.

Если это SQL Server и .NET, то из моего опыта:

1. Проверьте другие открытые транзакции в том же соединении, которое используется для вызова sproc. У них могут быть блокировки строк в таблице, которую выполняет один из ваших избранных. Вы можете попробовать добавить «MultipleActiveResultSets = false» в строку подключения к SQL Server и посмотреть, получите ли вы улучшение или, скорее, исключение (и вы можете выследить проблему из исключения). Это также может быть следствием неустановленного соединения, возвращенного в пул соединений (с чем я столкнулся с тех пор, как начал использовать MARS ).

2. Вам может понадобиться указать табличную подсказку NOLOCK (или READUNCOMMITTED, то же самое) в вашем запросе SELECT, если грязные чтения приемлемы .

   ВЫБРАТЬ * ИЗ [таблицы] С НОЛКОМ