Приветствую,

не выполняется следующий запрос на серваке:


во время выполнения System Cache достигает 14 Гб, PageFile тоже порядка 14 Гб, средняя загрузка по 16 процам 30%, но запрос таки не возвращает результатов, просто висит.

в то же время такой же запрос, но без TOP 18 выполняется за доли секунды, и возвращает ~1600 строк

На локальной же машине, на тестовой БД(которая кончено в разы меньше), запрос тоже выполняется доли секунды, что с TOP, что без него..

В чем может быть причина столь странного поведения SQL сервака?

1. Какой смысл в TOP без order by?
2. При каком раскладе может не выполниться условие  q.row > 0. Т.е. при каком раскладе ROW_NUMBER() может дать не положительные числа?

А вообще ответ на Ваш вопрос кроется в плане запроса, его отличии от плана запроса без top, который Вы не привели.

PurchasePlans содержит порядка 5 млн записей,
если смотреть Execution Plan то Clustered Index Scan занимает 100%

очень информативно.  
При данном стечении обстоятельств, однозначно можно утверждать что ошибка в 17й строке  

а разве "OVER(ORDER BY Id)" не сортирует по id?

планы запросов с TOP и без TOP значительно отличаются по количеству "ходов", но время-затраты не сильно отличаются:

у запроса без TOP Clustered Index Scan для PurchasePlans  - 96%(против 100% с TOP), Hash Match и Parallelism по 1%, куда делись еще 2 процента непонятно.

Добавлено через 1 минуту и 39 секунд
я пишу информацию которую могу получить, я слабо знаком со средствами для анализа запросов, поэтому буду рад если вы подскажите как мне провести анализ, или на что обратить внимание

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

это все и объясняет!
это и есть ответ на Ваш вопрос.


Это сообщение отредактировал(а) Zloxa - 26.7.2010, 09:34