Однозначного ответа нет. Можно такой запрос написать, что IO будет мал, а CPU сожрет сотни секунд. А можно с IO в два раза большим, но выполняющийся за секунду.

Например, попробуйте создать native compiled процедуру в тот момент, когда используемые ей таблицы пустые. Если не рекомпилировать ее или принудительно запрос в ней, после заполнения таблиц обнаружите много приятных неожиданностей.

Затем, что SQL сервер, в общем случае, используется в многопользовательском режиме. И только в случае явного указания ТС об использовании сервера в монопольном режиме, подход оценки только времени выполнения запроса оправдан.


Сами себе противоречите. Пользователю еще можно простить отсутствие знаний по архитектуре SQL Server. А Вам? Если Вася своим запросом "сожрал все ресурсы", то запрос Пети будет ждать, пока закончится запрос Васи, например, ожидая освобождения немерянного объема запрошенного планировщиком памяти. И конечный пользователь Петя будет возмущаться и будет при этом прав.

Ядра CPU это ресурс? Если нет, можно считать Вас троллем и расслабиться.
Если да, то из Вашего утверждение вытекает, что запрос с MAXDOP 0, по сравнению с MAXDOP 1, потребует времени на "пожираение ресурсов" (дополнительных ядер), а значит будет выполняться дольше?

Память это ресурс? Опять, если нет, можно считать Вас троллем и расслабиться.
Если да, то из Вашего утверждения вытекает, что запрос планировщиком 90% памяти сервера выполняется дольше, чем запрос 10% памяти сервера? Фактическое потребление памяти будем считать в обеих случаях одинаковым.

"Не путайтесь в показаниях." (с)


Ваше ЧСВ, вроде бы, было задето именно этим сообщением:

Не правда ли?

К слову, параллелятся далеко не только ядра, но и запросы ввода-вывода (IO). Что-нибудь об СХД или хотя бы RAID слышали?

Для Вас, наверное, будет открытием, но на то, чтобы получить с СХД мегабайт данных десятью запросами из десяти потоков может уйти в несколько раз меньше времени, чем при получении того же мегабайта, но одним запросом или десятью последовательными запросами из одного потока.

"Вы написали фигню. И было объяснено почему именно.
Если не доходит - перечитывайте мой ответ до понимания." (С)


Потому что SQL сервер его не знает. Эту статистику даже система не знает, хотя и обладает возможностями ее узнать в частных случаях. Только СХД.
Косвенно эту статистику можно оценить через системные счетчики производительности. Но если СХД обслуживает несколько серверов эта информация Вам даст мало полезного.

Попробуйте все же погуглить и дать ответ на вопрос:
Различается ли нагрузка на СХД при чтении одного мегабайта одним запросом ввода-вывода от нагрузки при чтении этого же мегабайта десятью запросами ввода-вывода?

Элементарно, Ватсон. Косвенным путем глядя на scan count, logical reads и physical reads.

Попробую пояснить на примере.
Есть табличка:





Во-первых, сразу видим во сколько потоков выполнялся запрос (33-1=32).

Во-вторых, видим, что параллельный план запроса в данном случае потребовал 2246 дополнительных обращений к кешу данных. То есть, при недостатке памяти дважды с диска могло читаться 0.6% страниц. Таким процентом я готов пренебречь. А было бы 6% - это уже стало бы поводом для размышлений в случае многопользовательской системы.


Данный пример заодно показывает, насколько Вы заблуждаетесь. После того, как вся таблица оказалась в кеше, все значения статистик ввода-вывода стабилизировались. То есть, они совсем не "случайные". Нужно просто уметь их правильно интерпретировать )))

"Вы просто физику процесса не понимаете." (с)


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

В том то и дело, что для того, чтобы оценить нагрузку на СХД нам нужно проанализировать, количество страниц которые нужны запросу с одной стороны, и то, как часто наш сервер ходит на диск по sys.dm_io_virtual_file_stats.

На практике, мне еще приходилось порой гонять с завидной регулярностью fio, чтобы можно было аргументированно разбираться с администраторами СХД по поводу обещанных и фактических IOPS.

Впрочем мы начинали с того, как различается нагрузка на СХД при MAXDOP 0 и MAXDOP 1. И это я уже наглядно показал. Если все таблицы, используемые в запросе не могут поместиться в кеше - различается, так как читается разное количество страниц. А сколько реально прочиталось в процессе эксплуатации - смотрим уже в sys.dm_exec_query_stats и делаем выводы об этих запросах.

В DWH параллельное выполнение запросов - хорошо. В высоконагруженной многопользовательской системе - не факт. Потому что может быть важно не столько то, сколько ждет результата запроса конкретный Вася. А сколько в среднем времени ожидают выполнения своих запросов все пользователи включая тех, кто ждет завершения Васиного запроса.

"Учите матчасть." (С)

Владислав Колосов,

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

invm,

Может хватит клоунады? Об общем времени IO спич вели исключительно Вы, тогда как я изначально вел речь только об оценке нагрузки на СХД при помощи статистик IO, что Вы считали и считаете бессмысленным.

P.S. Мы же вроде бы договорились о прекращении дискуссий о размере пиписек как здесь, так и в будущем?

А где тут время IO?
Или если я скажу, что схожу за хлебом в зависимости "от времени в пути и настроения", Вы решите, что я говорю об измерении настроения временем?

22261187

invm,

ответы все был даны выше. Дополнительные консультации за отдельную плату. До свидания.