Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
 SQL Sentry Plan Explorer FREE - размер результата  [new]
Mike_za
Member

Откуда: Москва
Сообщений: 1176
Добрый день!
Подскажите. откуда берется Actual Data Size = 2ГГБ
реально там возвращается около 110 МБ. (Client Statistics в MS SQL MS)

ПС. Полно varchar полей

К сообщению приложен файл. Размер - 65Kb
25 фев 15, 13:16    [17309849]     Ответить | Цитировать Сообщить модератору
 Re: SQL Sentry Plan Explorer FREE - размер результата  [new]
SomewhereSomehow
Member

Откуда: Moscow
Сообщений: 2480
Блог
Mike_za,

Видимо,
(Actual Rows)*(Estimated Row Size in B) / (1024*1024*1024) = (188763 * 11619)/(1024*1024*1024) = 2.04 (GB)
Это чтобы немного облегчить анализ, такую метрику как Actual Row Size сервер не собирает, вот Plan Explorer и изворачивается.
25 фев 15, 13:34    [17309987]     Ответить | Цитировать Сообщить модератору
 Re: SQL Sentry Plan Explorer FREE - размер результата  [new]
Владислав Колосов
Member

Откуда:
Сообщений: 7868
Как определяется ожидаемый размер, по данным статистики?
25 фев 15, 13:39    [17310035]     Ответить | Цитировать Сообщить модератору
 Re: SQL Sentry Plan Explorer FREE - размер результата  [new]
SomewhereSomehow
Member

Откуда: Moscow
Сообщений: 2480
Блог
Владислав Колосов,

Estimated Row Size - определяет сервер, клиент это свойство сам не определяет, ему это возвращается в виде свойства оператора плана "AvgRowSize". AvgRowSize определяется исходя из типов данных участвующих в проекции.
25 фев 15, 14:10    [17310269]     Ответить | Цитировать Сообщить модератору
 Re: SQL Sentry Plan Explorer FREE - размер результата  [new]
Mike_za
Member

Откуда: Москва
Сообщений: 1176
SomewhereSomehow
Видимо,
(Actual Rows)*(Estimated Row Size in B) / (1024*1024*1024) = (188763 * 11619)/(1024*1024*1024) = 2.04 (GB)

Спасибо.
Отсюда следует, что мегабайты над всеми стрелочками на плане весьма условны?

и еще вопросик
я правильно понимаю, что (количество чтения для запроса) *8кб - это количество данных, которые сервер реально прокачивает в процессе выполнения запроса?
25 фев 15, 16:07    [17311037]     Ответить | Цитировать Сообщить модератору
 Re: SQL Sentry Plan Explorer FREE - размер результата  [new]
SomewhereSomehow
Member

Откуда: Moscow
Сообщений: 2480
Блог
Mike_za
Спасибо.
Отсюда следует, что мегабайты над всеми стрелочками на плане весьма условны?

Да, больше для ориентира, хотя, конечно, иногда может и совпадать с реальностью довольно точно.

Mike_za
я правильно понимаю, что (количество чтения для запроса) *8кб - это количество данных, которые сервер реально прокачивает в процессе выполнения запроса?

Лучше не связывать это напрямую. logical reads - если вы говорите о них, это метрика Storage Engine, то что вы видите в планах - это Query Processor.

Например, таблица t1(a,b,c), индекс ix t1(b,c), вы спрашиваете select b from t1. Пусть вся таблица 100 КБ, более узкий индекс ix, 50 КБ - оптимизатор выберет его, т.к. меньше сканировать и он подходит для запроса. Т.е. будут прочитаны эти самые 50 КБ, но реально в запросе вы попросили одну колонку из этого индекса и благодаря тому что сервер умеет проталкивать проекции вниз, из оператора сканирования вы получите не 50 КБ данных, а столько, сколько весит одна строка, умноженное на количество строк, это и будет "прокачено" далее по запросу, например, в ту же сортировку, если бы она там была. Кроме того, есть еще операторы которые могут сохранять промежуточные данные, типа а-ля Spool и т.д., они могут наоборот увеличить объем обработанных данных, по сравнению с изначально прочитанным. И еще всякие нюансы.

Короче говоря, не связывайте одно с другим напрямую. Но пропорциональная зависимость между числом прочитанных страниц и числом данных обработанных планом есть и обычно четко прослеживается.
25 фев 15, 16:34    [17311235]     Ответить | Цитировать Сообщить модератору
 Re: SQL Sentry Plan Explorer FREE - размер результата  [new]
Mike_za
Member

Откуда: Москва
Сообщений: 1176
Может я не точно выразился. Речь уже не про стрелки на плане


Я имел ввиду, что вот у меня в результате выполнения запроса 1000 логических чтений.
set statistics io on
logical reads 1000

я могу сделать вывод, что сервер в процессе выполнения... прочитал из ОП 1000 * 8 КБ =(~ 8мб) данных?
ну понятно, что в случае со спулом он прочитал одну и туже страницу 50 раз...
25 фев 15, 18:27    [17311942]     Ответить | Цитировать Сообщить модератору
 Re: SQL Sentry Plan Explorer FREE - размер результата  [new]
Mike_za
Member

Откуда: Москва
Сообщений: 1176
Или.
условно подряд идет 2 операции. физически сервер делает их обе (одновременно) прочитав данные один раз, но напишет мне число чтений * 2
25 фев 15, 18:30    [17311957]     Ответить | Цитировать Сообщить модератору
 Re: SQL Sentry Plan Explorer FREE - размер результата  [new]
SomewhereSomehow
Member

Откуда: Moscow
Сообщений: 2480
Блог
Mike_za,

Не очень понимаю вопрос:
что значит "у меня в результате выполнения запроса 1000 логических чтений" - у вас же статистика выдается не на весь запрос куммулятивно, а на каждую структуру к которой осуществляется доступ (SET STATISTICS IO)
что значит "условно подряд идет 2 операции" - какие две операции и как это подряд?

Вот, например:
+
create table t1(a int primary key identity, b char(8000) not null);
go
-- таблица, заполненных страниц данных 1000, индексы 4 и и IAM - 1 итого 1005.
insert t1(b)
select top(1000) 'b' from master..spt_values;
go
set statistics io, xml on;
select * from t1;
select * from t1 join t1 t2 on t1.a = t2.a;
select *,(select 1) from t1 where t1.a%2 = 0 option(querytraceon 8649);
set statistics io, xml off;
go
drop table t1;
go

Вот планы:
Картинка с другого сайта.
А вот статистика:
Table 't1'. Scan count 1, logical reads 1005, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

Table 't1'. Scan count 2, logical reads 2010, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

Table 't1'. Scan count 5, logical reads 1133, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

В первом случае, в плане одна таблица, сканируется один раз целиком - все ее заполненные страницы - итого 1005 чтений.

Во втором случае, в плане тоже одна таблица, но участвует два раза, в обоих случаях сканируется полностью - итого Scan count 2, а общее число страниц 1005*2 = 2010.

В третьем случае, в плане опять одна таблица, но план параллельный, работа идет при помощи 5 потоков (у меня на машине 4 ядра - 4 рабочих потока и 1 управляющий - всего 5), число сканирований 5, число чтений каждого - зависит от того, как распределит страницы Parallel Page Supplier - компонент, ответственный за поставление страниц Query Processor. Этот компонент также отвечает за то, чтобы каждый поток получил только определенный набор страниц, иначе, некоторые страницы могут быть просканированы дважды двумя или более потоками и будут получены дубли, т.е. некорректные результаты. Видимо, с этим связаны накладные расходы на дополнительные чтения для служебных нужд параллельного сканирования - итого 1133 чтения.

Не знаю, насколько это то, что вы спрашивали.
25 фев 15, 22:21    [17312744]     Ответить | Цитировать Сообщить модератору
 Re: SQL Sentry Plan Explorer FREE - размер результата  [new]
Mike_za
Member

Откуда: Москва
Сообщений: 1176
Мой вопрос: Мы можем умножить 1005 чтений на 8кб и сделать вывод, что сервер прокачал 8мб через оперативную память в первом запросе?

Ну И как следствие, в ситуациях при значительно больших количествах чтений делать выводы о минимальной длительности выполнения запроса, с учетом скорости работы оперативной памяти?
Условно суммарное количество чтений по запросу 1 млн.-> 8ггб -> пропускная скорость памяти "условно" 5ггбайт в секунду. Значит меньше 1.5 секунд этот запрос , в принципе отработать не сможет?
25 фев 15, 22:51    [17312855]     Ответить | Цитировать Сообщить модератору
 Re: SQL Sentry Plan Explorer FREE - размер результата  [new]
SomewhereSomehow
Member

Откуда: Moscow
Сообщений: 2480
Блог
Mike_za,

автор
пропускная скорость памяти "условно" 5ггбайт в секунду

Это что значит?
Скорость, с которой можно читать из оперативной памяти?
А куда?

Представьте, допустим, все страницы в оперативной памяти, ничего с дисков поднимать не надо. Произошел один logical read. Что значит logical read – то что, из buffer pool, из памяти (если не задействован Buffer Pool Extension на ssd) прочитана одна страница.

Но что значит «прочитана из памяти» - куда прочитана? А прочитана она в том смысле, что код осуществил доступ к области памяти, загрузил нужные данные во внутренние структуры, и начал выполнять над ними некоторые действия, которые определены логикой функций внутри сиквела. Что это значит в свою очередь - то что в регистры процессора были загружены данные и инструкции по их обработке.

У современных процессоров есть своя память, как минимум, кэши первого, второго и третьего уровней. Далее, в зависимости от характеристик процессора инструкции и данные могут обрабатываться с разной эффективностью.

Так что ответ на ваш вопрос:
автор
Условно суммарное количество чтений по запросу 1 млн.-> 8ггб -> пропускная скорость памяти "условно" 5ггбайт в секунду. Значит меньше 1.5 секунд этот запрос, в принципе отработать не сможет?

Зависит от:
  • Скорости обмена данными между CPU и RAM
  • Характеристик CPU
  • Возможности параллельной и эффективной обработки инструкций (в том числе с разной памятью, т.е. кода сиквел сервера, в части NUMA)
  • Количества инструкций процессора для конкретной операции (кода сиквел сервера)

    Для примера качества инструкций и внутренних структур данных - могу привести колоночные индексы. Там, например, работа организована так, чтобы максимально задействовать все кэши процессора и при этом с минимальным количеством отсутствия данных в кэше (cache miss) и некоторыми другими оптимизациями обработки. Это называется Batch Execution Mode - способен ускорять выполнение в 10 и более раз, при том, что объем поднимаемых данных их памяти - один и тот же.

    Так что нет, не все так просто. Не надо напрямую связывать объем данных со скоростью запроса. Ведь даже без всяких рассуждений может быть понятно, что обрабатывая один и тот же объем - время может очень сильно отличаться.
    Но при прочих равных, допустим один план для 1000 стро и для 1 000 000 строк - время конечно будет отличаться - то дело тут св общем-то не в том, как быстро оперативная память может обмениваться данными с CPU, а в том, сколько инструкций нужно выполнить, чтобы обработать 1000 и 1 000 000 строк.
  • 25 фев 15, 23:46    [17312988]     Ответить | Цитировать Сообщить модератору
     Re: SQL Sentry Plan Explorer FREE - размер результата  [new]
    Mike_za
    Member

    Откуда: Москва
    Сообщений: 1176
    SomewhereSomehow, понял. Спасибо
    26 фев 15, 00:47    [17313106]     Ответить | Цитировать Сообщить модератору
    Все форумы / Microsoft SQL Server Ответить