Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 [2]      все
 Re: План запроса  [new]
Mind
Member

Откуда: Лучший город на Земле
Сообщений: 2322
SomewhereSomehow
сам оператор сортировки пытается соблюдать некий баланс между использованием памяти и tempdb
Мне любопытно, а где-нибудь описано такое поведение? Это происходит до или после выделения памяти? Например для данного запроса выделено 13 Гб памяти, предположим что на вход сортировки подается 9 ГБ данных (что кстати не факт, даже в актуальном плане), то почему оператор сортировки может решить не использовать часть уже зарезервированной конкретно под него памяти?
1 июл 14, 00:54    [16241372]     Ответить | Цитировать Сообщить модератору
 Re: План запроса  [new]
SomewhereSomehow
Member

Откуда: Moscow
Сообщений: 2480
Блог
+ Любопытный гость

Решения оптимизатора, в массе своей, основываются на стоимости. Соответственно, в этом случае, стоимость соединения вложенными циклами оказалась ниже, чем другие типы соединения. ТС, имея под рукой БД и запрос, может посмотреть какие будут стоимости плана, если форсировать другие типы соединений при помощи option(merge/hash join). Значит ли это, что план с наименьшей стоимостью всегда выполнится быстрее – в общем случае нет. Стоимость величина оценочная и кроме того основана на модели, и, даже если оценки более-менее точные, модель может отличаться от реальности.

В данном случае, если представить себе соединение, например, merge join, то необходим либо покрывающий индекс с сортировкой по полю соединения, либо делать дополнительную сортировку, либо брать индекс и делать лукап в кластерный. Если взять hash join, то необходима дополнительная память на построение build стороны. Все эти особенности отражает модель при помощи присвоения разным вариантом разной стоимости. В итоге, выбирается наиболее дешевый вариант, которым в данном случае оказался Nested Loops + Clustered Index Seek с последующей сортировкой.

+ Mind

К сожалению, официально не документировано, хотя они вообще мало такие вещи документируют. Могу процитировать Paul White-а в одной из его статей.
Paul White
It is a common misconception that SQL Server will try to perform a sort entirely in memory if it can. In fact the algorithms used are much more complex: they aim to achieve a balance between memory usage, average response time, while maintaining high levels of resource concurrency. Memory is a precious resource in the server, so SQL Server may spill a sort to tempdb, even if sufficient main memory is available.

Это похоже на правду. Наверняка, вы и сами обращали внимание, что иногда без явных видимых причин сортировка вдруг сливает данные на диск. Простой пример.
if object_id('t') is not null drop table t;
create table t(a char(5000));
insert t select 'a' from master..spt_values;
go
set statistics xml on;
select * from t order by a;
set statistics xml off;

Картинка с другого сайта.
Вроде бы и данные фиксированной длины и оценка совпадает с фактом, а spill происходит.

На всякий случай, возвращаясь к теме, чтобы не запутывать ТСа всякими нюансами, еще раз повторю свою мысль, что если можно оптимизировать логику, то лучше начать с этого. Никакой оптимизатор, не сможет посмотреть на процедуру и сказать: "о, этот кусок старый, теперь он вообще не нужен, убираем его" и тому подобное =)
1 июл 14, 10:02    [16241907]     Ответить | Цитировать Сообщить модератору
 Re: План запроса  [new]
gerogekochkin
Member

Откуда: Москва
Сообщений: 93
SomewhereSomehow,
а что, если создать для запроса plan_guide с явным указанием maxdop?
я протестировал для запроса с "top 1". В единичном случае выполнилось в два раза быстрее!
3 июл 14, 12:38    [16254183]     Ответить | Цитировать Сообщить модератору
 Re: План запроса  [new]
MSSQLBug
Guest
gerogekochkin,

> я протестировал для запроса с "top 1". В единичном случае выполнилось в два раза быстрее!
Причём здесь вообще TOP 1?

Вы бы лучше на мои комментарии ответили. ;)
3 июл 14, 12:41    [16254202]     Ответить | Цитировать Сообщить модератору
 Re: План запроса  [new]
gerogekochkin
Member

Откуда: Москва
Сообщений: 93
MSSQLBug,
запрос формирует аксапта. Каким образом я могу добавить условие a.closed=0, если запрос формируется в самой системе?
3 июл 14, 13:30    [16254557]     Ответить | Цитировать Сообщить модератору
 Re: План запроса  [new]
gerogekochkin
Member

Откуда: Москва
Сообщений: 93
MSSQLBug
gerogekochkin,

Ага, то есть Вам просто нужны текущие остатки.

Так вот, если нулевые Вас не интересуют, добавьте в условие запроса A.CLOSED=0.

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

Например, неясно, зачем Вам сортировка именно в таком порядке.

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

Кстати, например, у нас (но у нас Axapta 3.0, а не более старшая версия, как у Вас;
и Ваших расширенных аналитик нет, только стандартные):

Результаты такие (привожу только оценки стоимости планов, не хочется ждать 15 минут):
1. Ваш запрос: 7563.41
2. При добавлении к нему условия A.CLOSED=0 (но при этом "пустых" остатков не будет): 866.55


Запрос ведь формирует сама система, как я могу добавять это условие A.CLOSED=0 в запрос, который формирует Аксапта?
3 июл 14, 13:42    [16254635]     Ответить | Цитировать Сообщить модератору
 Re: План запроса  [new]
gerogekochkin
Member

Откуда: Москва
Сообщений: 93
MSSQLBug,
а как я могу добавить условие A.CLOSED=0 в запрос, который формирует Аксапта???
3 июл 14, 13:44    [16254651]     Ответить | Цитировать Сообщить модератору
 Re: План запроса  [new]
MSSQLBug
Guest
gerogekochkin,

> а как я могу добавить условие A.CLOSED=0 в запрос, который формирует Аксапта???
Переписав его в Axapta, разумеется. ;) Где это он там формируется, кстати?

Вы так и не ответили, какова цель этого запроса, без этого много не посоветуешь.
3 июл 14, 13:51    [16254723]     Ответить | Цитировать Сообщить модератору
 Re: План запроса  [new]
SomewhereSomehow
Member

Откуда: Moscow
Сообщений: 2480
Блог
gerogekochkin
SomewhereSomehow,
а что, если создать для запроса plan_guide с явным указанием maxdop?
я протестировал для запроса с "top 1". В единичном случае выполнилось в два раза быстрее!


Не совсем понял, а может что-то пропустил, но при чем тут maxdop? У вас на сервере стоит ограничение в 1 поток? В таком случае да, локальный хинт переопределит это значение и параллельный план будет возможен, если это решит проблему - хорошо. Но я бы на вашем месте, постарался избавиться от сортировки. Кстати, вы не посмотрели, происходит все-таки spill или нет? А память долго ждет или нет? Все-таки запрос требует много памяти... Посмотрите ожидания при помощи Extended Events - очень классная штука, помогает сразу понять корень проблемы, а не гадать.
3 июл 14, 15:03    [16255326]     Ответить | Цитировать Сообщить модератору
 Re: План запроса  [new]
gerogekochkin
Member

Откуда: Москва
Сообщений: 93
MSSQLBug,
этот запрос отображает остатки в наличии.
Вот основное место, в котором отображаются все остатки: Управление запасами \ Запросы \ В наличии
3 июл 14, 15:25    [16255511]     Ответить | Цитировать Сообщить модератору
 Re: План запроса  [new]
MSSQLBug
Guest
gerogekochkin,

> Управление запасами \ Запросы \ В наличии
А зачем у Вас там в "отображение аналитики" установлена галка "закрытые операции"?
3 июл 14, 15:40    [16255637]     Ответить | Цитировать Сообщить модератору
 Re: План запроса  [new]
gerogekochkin
Member

Откуда: Москва
Сообщений: 93
MSSQLBug,
я лично не занимаюсь аксаптой, но вот что мне ответили:
"Предположим, что когда-то давно была закуплена номенклатура "А", запасы которой были впоследствии израсходованы.
Позднее встала задача: рассчитать остатки этой номенклатуры на определённую дату, которая находится где-то в середине периода её складской активности.
Для решения подобной задачи есть 2 подхода:
1. Рассчитать остатки вручную при помощи интерфейса
2. Рассчитать остатки программно.
Рассмотрим вариант 1:
Нужно выгрузить в Excel все операции по товару (складские проводки) и просуммировать их на требуемую дату.
Форма складских проводок может быть вызвана из 3-х мест системы, включая форму запасов в наличии.
Так вот, если форма запасов в наличии будет открыта с установленной галкой "закрытые операции", то нужная нам номенклатура в ней не будет отображаться.

Рассмотрим вариант 2 (и усложним его):
Нам нужно рассчитать запасы на дату для большого кол-ва номенклатуры, как и требуется в большинстве реальных запросов по отчётности.
В этом случае организуется цикл по строкам остатков, где для каждой из строк рассчитывается итог товародвижения на указанную дату с обратным знаком и суммируется с текущим значением остатка.
Такой подход расчёта является наиболее оптимальным, т.к. при этом на таблицу складских проводок удаётся наложить фильтр по номенклатуре и по складской аналитике.
Складская аналитика в каждой строке запасов в наличии уникальна (например: Склад, Цвет, Размер), поэтому если мы будем накладывать на запасы в наличии фильтр "закрытые операции" = "да", то также как и в первом варианте, мы пропустим ряд строк и не учтём какую-то часть складского движения, которая на текущий момент считается закрытой.
"
4 июл 14, 08:35    [16258153]     Ответить | Цитировать Сообщить модератору
 Re: План запроса  [new]
MSSQLBug
Guest
gerogekochkin,

> я лично не занимаюсь аксаптой, но вот что мне ответили
То, что Вам ответили --- это совершенно другая задача, а не то, что Вы тут описывали.
Кроме того, Вы пытаетесь сделать OLAP в OLTP-системе, естественно, получается плохо.

Лучше посоветуйте тем, кто у вас занимается Axapta,
обратиться с этой проблемой на профильный форум (http://www.axforum.info).
4 июл 14, 10:23    [16258504]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2]      все
Все форумы / Microsoft SQL Server Ответить