SQL - Вызов "reader.NextResult" вызывает долгую задержку
Наше приложение выполняет длинную сложную хранимую процедуру с несколькими наборами результатов. Пользователи долго ждут этого запроса, поэтому я решил определить причину задержки.
Я ставлю секундомер на выполнение и чтение данных, и каждый раз это занимает 6-7 секунд. Я рассчитал время выполнения хранимой процедуры, ожидая, что это займет все время. Этого не было - потребовалось 30 мс или около того.
Поэтому я установил таймеры вокруг каждого из ~ 20 наборов результатов. Каждый «блок» занимал очень мало времени (<10 мс), за исключением одного в середине обработки, который занимал 5-6 секунд. При дальнейших исследованиях я обнаружил, что все время занимал вызов «reader.NextResult ()». Эта долгая задержка происходит каждый раз в одном и том же месте.
Если я просто выполняю хранимую процедуру, кажется, что она запускается очень быстро, так что это НЕ КАЖЕТСЯ проблемой с запросом, но я не знаю ...
Как я это интерпретирую? Предоставляет ли SQL мне наборы результатов по мере их получения, и может ли рассматриваемый набор результатов быть проблемной областью в моем запросе SQL? Или задержка может быть вызвана чем-то другим?
Обновлено:
Спасибо за ответ и комментарии - я использую SQL Server и .NET.
Что меня больше всего интересовало, так это ПОЧЕМУ моя задержка происходит при вызове «NextResult ()». Будучи новичком в разработке SQL, я предполагал, что в моем приложении возникнет задержка из-за длительного выполнения хранимой процедуры во время ожидания возврата вызова ExecuteReader (). Теперь кажется, что SQL начнет возвращать данные ДО того, как запрос будет завершен, и, если есть задержка, он задержит вызов NextResult ().
Я начал думать, что моя задержка связана с хранимой процедурой. Когда вызов ExecuteReader () вернулся быстро, я подумал, что моя задержка связана с обработкой моего кода считывателем. Когда задержка оказалась в вызове NextResult (), я был сбит с толку. Теперь я вернулся к просмотру хранимой процедуры.
Спасибо тем из вас, кто нашел время изучить мою проблему и предложил свою помощь.
@ScottB, вы предполагаете, что платформа rdbms не важна для этого вопроса, и это ложное предположение. Также важно точно знать, какие операторы SQL выполняются. Подробности, подробности, подробности.
Ответы 2
Ответ будет зависеть от того, какую СУБД вы используете.
Если это SQL Server и .NET, то из моего опыта:
- Проверьте другие открытые транзакции в том же соединении, которое используется для вызова sproc. У них могут быть блокировки строк в таблице, для которой выполняется один из выбранных вами элементов. Вы можете попробовать добавить «MultipleActiveResultSets = false» в строку подключения к SQL Server и посмотреть, получите ли вы улучшение или, что более вероятно, исключение (и вы можете выследить проблему из исключения). Это также может быть следствием того, что в пул соединений было возвращено неустановленное соединение (с чем я столкнулся с тех пор, как начал использовать МАРС).
Вам может потребоваться указать подсказку таблицы NOLOCK (или READUNCOMMITTED, то же самое) в вашем запросе SELECT, если грязное чтение приемлемо.
ВЫБРАТЬ * ИЗ [таблицы] БЕЗ НОЛОКА
Пожалуйста, позвольте не рекомендовать никакой замок как своего рода серебряную пулю
Понимание прочитанного? «Может ... грязное чтение приемлемо». Используйте его для устранения проблемы.
Когда вы выполняете сохраненную процедуру из команды .Net, результаты начнут передаваться, как только они будут готовы в SQL.
Это означает, что вы можете начать видеть результаты в своем приложении .Net до того, как будет выполнена вся сохраненная процедура.
Ваше узкое место, вероятно, находится в хранимой процедуре, запустите трассировку сервера sql и проследите все операторы, выполняемые внутри хранимой процедуры (получите продолжительность). Вы сможете отследить точный оператор в процессе, который работает медленно, а также сможете определить параметры, которые передаются в процесс, чтобы вы могли проверить это в Query Analyzer и посмотреть на план.
Другим моментом, который отсутствует в вопросе, по-видимому, является объем перемещаемых данных, хотя маловероятно, что у вас могут быть действительно большие блоки данных (например, капли), которые отправляются, и время тратится на провод. Вам действительно нужно немного расширить вопрос, чтобы помочь с диагностикой.
какой язык / платформу вы используете? можете ли вы предоставить пример исходного кода, чтобы проиллюстрировать эту проблему?