AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX: Администрирование
All
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны Забыли пароль?

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 10.03.2017, 15:43   #1  
gkochkin is offline
gkochkin
Участник
 
16 / 10 (1) +
Регистрация: 10.03.2017
Thumbs up Поле DataAreaID в индексах SQL Server
Dynamics AX 2009
SQL Server 2008 R2
Возникли разногласия при оптимизации запроса на SQL Server по поводу того можно ли (в качестве исключения для особо критичных задач) перемещать поле DataAreaID на другие позиции в индексе средствами SQL Server, как неселективное?
Тестирование в рамках SQL показывает значительный прирост производительности.
Проблема в том, что при обновлении Аксапты, она вернет все на круги своя.
Как лучше поступить в этом случае?
Буду признателен за помощь.
Старый 10.03.2017, 16:06   #2  
Alexius is offline
Alexius
Участник
Аватар для Alexius
 
406 / 174 (6) ++++++
Регистрация: 13.12.2001
В АХ АОТ в описание индекса вставляете вручную (не перетаскиванием) поле DataAreaId и позиционируете его как вам нравится. Ну и синхронизация соответственно.
За это сообщение автора поблагодарили: VORP (2).
Старый 10.03.2017, 16:11   #3  
gkochkin is offline
gkochkin
Участник
 
16 / 10 (1) +
Регистрация: 10.03.2017
по поводу его позиции есть какие-то противопоказания?
Старый 10.03.2017, 16:13   #4  
gkochkin is offline
gkochkin
Участник
 
16 / 10 (1) +
Регистрация: 10.03.2017
Цитата:
Сообщение от gkochkin Посмотреть сообщение
по поводу его позиции есть какие-то противопоказания?
Я занимаюсь администрированием SQL, в Аксапту имею, но минимальный доступ. И возник этот спор.
Аксаптовики мне говорят, чтобы я забыл про это поле
Старый 10.03.2017, 16:27   #5  
Vadik is offline
Vadik
Модератор
Аватар для Vadik
 
3,198 / 1210 (47) ++++++++
Регистрация: 18.11.2002
Адрес: гражданин Москвы
Цитата:
Сообщение от gkochkin Посмотреть сообщение
Аксаптовики мне говорят, чтобы я забыл про это поле
Скажите им, что фикс для parameter sniffing для AX 2009 тоже есть
__________________
-ТСЯ или -ТЬСЯ ?
Старый 10.03.2017, 16:29   #6  
SRF is offline
SRF
Участник
MCBMSS
Axapta Retail User
 
245 / 297 (10) ++++++
Регистрация: 08.08.2007
Есть стандартные таблицы, у которых поле dataAreaId в индексе идет не первым, например SpecTrans, поэтому особых противопоказаний нет, есть индивидуальная не переносимость

Если вы меняете какой-либо из существующих индексов, то лучше пообщаться с людьми, которые могут посмотреть в приложении, не будет ли печальных последствий в других местах.
__________________
Sergey Nefedov,
IT Magnet
Старый 10.03.2017, 16:52   #7  
Alexius is offline
Alexius
Участник
Аватар для Alexius
 
406 / 174 (6) ++++++
Регистрация: 13.12.2001
Основное противопоказание, на мой взгляд, это кластерные индексы, т.к. многие грид-формы в АХ выдают информацию без каких-либо фильтров, кроме скрытого фильтра по компании (DataAreaId) и если это поле утащить с первой позиции, то в них могут начаться тормоза.
Старый 10.03.2017, 19:54   #8  
ALES is offline
ALES
Участник
Злыдни
 
202 / 41 (2) +++
Регистрация: 11.08.2004
"Вот так и рождаются не здоровые сенсации" (с)
Ни числа используемых компаний в AX, ни оптимизируемого запроса, ни объема данных в соотв. табличках.. в этом случае действительно лучше ничего не трогать
За это сообщение автора поблагодарили: Vadik (1).
Старый 12.03.2017, 16:23   #9  
AlexeyS is offline
AlexeyS
Участник
 
314 / 204 (7) ++++++
Регистрация: 15.06.2004
Адрес: москва
можно пойти немного другим путем - вместо изменения существующего индекса добавить еще один с тем-же набором, но другим порядком полей. И если оригинальный индекс перестал использоваться и планы исполнения стали использовать только новый, то можно смело менять исходный. Если нет - нужно искать, где он еще используется.
Старый 13.03.2017, 09:41   #10  
gkochkin is offline
gkochkin
Участник
 
16 / 10 (1) +
Регистрация: 10.03.2017
Цитата:
Сообщение от ALES Посмотреть сообщение
"Вот так и рождаются не здоровые сенсации" (с)
Ни числа используемых компаний в AX, ни оптимизируемого запроса, ни объема данных в соотв. табличках.. в этом случае действительно лучше ничего не трогать
Таблица inventdim- 80'000'000 строк.
На данный момент одна компания, но, возможно, будет еще одна.
Запрос следующего вида:
Код:
SELECT 
SUM(A.POSTEDQTY),SUM(A.POSTEDVALUE),SUM(A.PHYSICALVALUE),SUM(A.DEDUCTED),SUM(A.RECEIVED),SUM(A.RESERVPHYSICAL),SUM(A.RESERVORDERED),SUM(A.REGISTERED),SUM(A.PICKED),SUM(A.ONORDER),SUM(A.ORDERED),SUM(A.ARRIVED),SUM(A.QUOTATIONRECEIPT),SUM(A.QUOTATIONISSUE),SUM(A.AVAILPHYSICAL),SUM(A.AVAILORDERED),SUM(A.PHYSICALINVENT) 

FROM INVENTSUM A 

WHERE 
((A.DATAAREAID=@P1) AND 
-- поменять местами поля
((A.ITEMID =@P2) AND 
 (A.CLOSED=@P3))) AND 

-- Вопрос: почему не используется индекс ECC_FinDimIdx?
EXISTS (SELECT 'x' 
		FROM INVENTDIM B with(index(I_698ECC_FINDIMIDX))
		WHERE ((B.DATAAREAID=@P4) AND
			((((((B.INVENTDIMID=A.INVENTDIMID) AND 
				(B.INVENTSIZEID =@P5)) AND
				(B.INVENTCOLORID =@P6)) AND
				(B.INVENTLOCATIONID =@P7)) AND
				(B.INVENTBATCHID =@P8)) AND 
				(B.INVENTGTDID_RU =@P9))))
Старый 13.03.2017, 11:34   #11  
Владимир Максимов is offline
Владимир Максимов
Участник
КОРУС Консалтинг
 
1,315 / 793 (29) +++++++
Регистрация: 13.01.2004
Цитата:
-- Вопрос: почему не используется индекс ECC_FinDimIdx?
Почему не работает подсказка оптимизатору - не знаю. Может, физически нет такого индекса. Судя по префиксу - это какая-то кастомизация. Хотя для Axapta использование подсказок оптимизатору - порочная практика, которая не уменьшает, а увеличивает количество проблем.

Кроме того, при оптимизации запросов следует учитывать тот факт, что Axapta обращается к данным SQL не прямыми запросами, а через "обертку" в виде курсоров.

exec sp_cursoropen
exec sp_cursorfetch
exec sp_cursorclose

Как следствие, план выполнения запросов "внутри" курсоров и в "прямых" запросах может очень сильно отличаться, хотя, казалось бы, запрос один и тот же. Подробности можете посмотреть в этой теме

Проблемы с Exists Join

Вкратце, попробуйте заменить Exists на Inner Join. Поскольку у Вас связь InventSum и InventDim, то в данном случае - это будет корректная замена. И уберите подсказку оптимизатору для индекса
__________________
- Может, я как-то неправильно живу?!
- Отчего же? Правильно. Только зря...
Старый 13.03.2017, 12:25   #12  
gkochkin is offline
gkochkin
Участник
 
16 / 10 (1) +
Регистрация: 10.03.2017
Цитата:
Сообщение от Владимир Максимов Посмотреть сообщение
Почему не работает подсказка оптимизатору - не знаю. Может, физически нет такого индекса. Судя по префиксу - это какая-то кастомизация. Хотя для Axapta использование подсказок оптимизатору - порочная практика, которая не уменьшает, а увеличивает количество проблем.

Кроме того, при оптимизации запросов следует учитывать тот факт, что Axapta обращается к данным SQL не прямыми запросами, а через "обертку" в виде курсоров.

exec sp_cursoropen
exec sp_cursorfetch
exec sp_cursorclose

Как следствие, план выполнения запросов "внутри" курсоров и в "прямых" запросах может очень сильно отличаться, хотя, казалось бы, запрос один и тот же. Подробности можете посмотреть в этой теме

Проблемы с Exists Join

Вкратце, попробуйте заменить Exists на Inner Join. Поскольку у Вас связь InventSum и InventDim, то в данном случае - это будет корректная замена. И уберите подсказку оптимизатору для индекса
Тестирование показало, что хинт работает, но запрос с хинтом работает хуже. Если индекс поменять - поле DataAreaID поставить не на первую позицию - оптимизатор самостоятельно подхватывает индекс (без хинта) и в этом случае статистика показывает меньшее кол-во логических чтений и процессорного времени.
На тестовой системе я все это сделал, но в продакшн это не хотят пускать, прикрываясь тем, что поле DataAreaID определяет рамки компании и всегда ставится аксаптой на первое место.
Старый 13.03.2017, 12:40   #13  
trud is offline
trud
Участник
 
309 / 196 (7) ++++++
Регистрация: 07.06.2003
а почему вы хотите его использовать? т.е. для условных значений B.INVENTBATCHID ="без партии и B.INVENTGTDID_RU ="пусто"(т.е. комбинации значений которых много в базе) использование любого индекса по INVENTDIM может привести к большим проблемам. Предположу что SQL рассуждает в таком же духе, раз автоматом не использует индекс
Старый 13.03.2017, 13:37   #14  
trud is offline
trud
Участник
 
309 / 196 (7) ++++++
Регистрация: 07.06.2003
Цитата:
Сообщение от gkochkin Посмотреть сообщение
в этом случае статистика показывает меньшее кол-во логических чтений и процессорного времени.
На тестовой системе я все это сделал, но в продакшн это не хотят пускать, прикрываясь тем, что поле DataAreaID определяет рамки компании и всегда ставится аксаптой на первое место.
если планы одинаковые, то порядок то тут не причем. просто ваш результирующий индекс по видимому имеет другой Fill factor(т.е. получается страницы расположены более плотно раз кол-во логических чтений меньше - тут я подразумеваю что дефрагментацию вы выполнили перед тестом).
Это все приведет к увеличению кол-ва расщеплений этих страниц при обновлении-вставке данных(а для InventSum это критично), что в конечном итоге потенциально замедлит всю систему. так что вполне аргументировано не дают переносить
Старый 13.03.2017, 13:42   #15  
gkochkin is offline
gkochkin
Участник
 
16 / 10 (1) +
Регистрация: 10.03.2017
Цитата:
Сообщение от trud Посмотреть сообщение
если планы одинаковые, то порядок то тут не причем. просто ваш результирующий индекс по видимому имеет другой Fill factor(т.е. получается страницы расположены более плотно раз кол-во логических чтений меньше - тут я подразумеваю что дефрагментацию вы выполнили перед тестом).
Это все приведет к увеличению кол-ва расщеплений этих страниц при обновлении-вставке данных(а для InventSum это критично), что в конечном итоге потенциально замедлит всю систему. так что вполне аргументировано не дают переносить
Планы не одинаковые. План просто при выполнении запроса не использует нами добавленный индексI_698ECC_FINDIMIDX.
С хинтом соответственно использует.
Если поле DataAreaID перенести в конец - оптимизатор хватает наш индекс I_698ECC_FINDIMIDX и количество чтений (и процессорное время) значительно меньше, чем без использования этого индекса (I_698ECC_FINDIMIDX).
Старый 13.03.2017, 13:54   #16  
trud is offline
trud
Участник
 
309 / 196 (7) ++++++
Регистрация: 07.06.2003
Цитата:
Сообщение от gkochkin Посмотреть сообщение
С хинтом соответственно использует.
А в индексе что за поля? все 5 полей запроса из InventDim?
просто на практике я видел ситуации когда создание подобных индексов приводило к остановкам системы, из за того, что собственно для ряда значений поиск остатков через InventDim приводил к полному скану этой таблицы.
т.е. надо проверить что не используются всякие обобщенные партии и гтд
Старый 13.03.2017, 14:13   #17  
gkochkin is offline
gkochkin
Участник
 
16 / 10 (1) +
Регистрация: 10.03.2017
Цитата:
Сообщение от trud Посмотреть сообщение
А в индексе что за поля? все 5 полей запроса из InventDim?
просто на практике я видел ситуации когда создание подобных индексов приводило к остановкам системы, из за того, что собственно для ряда значений поиск остатков через InventDim приводил к полному скану этой таблицы.
т.е. надо проверить что не используются всякие обобщенные партии и гтд
dataareaid
inventdimid
inventsizeid
inventcolorid
inventlocationid
inventbatchid
inventgtdid_ru
Старый 13.03.2017, 14:24   #18  
trud is offline
trud
Участник
 
309 / 196 (7) ++++++
Регистрация: 07.06.2003
О..
этот индекс и не должен использоваться. т.е. какой у вас план то - найти сначала номенклатуру(из InventSum) и InventDimId, а потом проверить все комбинации аналитик? для проверки комбинаций SQL считает что лучше использовать кластерный индекс по InventDimId.
тут можно попробовать создать вот такой(ниже) - искать сразу InventDim и потом по нему уже InventSum, но опять же надо смотреть на ваши данные, т.е. это будет работать если нет обобщенных партий-гтд и нет других аналитик
dataareaid
inventsizeid
inventcolorid
inventlocationid
inventbatchid
inventgtdid_ru
Старый 13.03.2017, 14:48   #19  
gkochkin is offline
gkochkin
Участник
 
16 / 10 (1) +
Регистрация: 10.03.2017
Цитата:
Сообщение от trud Посмотреть сообщение
О..
этот индекс и не должен использоваться. т.е. какой у вас план то - найти сначала номенклатуру(из InventSum) и InventDimId, а потом проверить все комбинации аналитик? для проверки комбинаций SQL считает что лучше использовать кластерный индекс по InventDimId.
тут можно попробовать создать вот такой(ниже) - искать сразу InventDim и потом по нему уже InventSum, но опять же надо смотреть на ваши данные, т.е. это будет работать если нет обобщенных партий-гтд и нет других аналитик
dataareaid
inventsizeid
inventcolorid
inventlocationid
inventbatchid
inventgtdid_ru
SQL использует поиск по некластерному, а потом добирает данные в кластерном.
Если поставить DataAreaID в вышеуказанном мной индексе на 4 место, то статистические данные запроса становятся лучше.
Такой индекс sql использует без подсказок.
Согласны?
Миниатюры
Нажмите на изображение для увеличения
Название: Screenshot_1.jpg
Просмотров: 5
Размер:	34.5 Кб
ID:	11256  
Старый 13.03.2017, 15:02   #20  
trud is offline
trud
Участник
 
309 / 196 (7) ++++++
Регистрация: 07.06.2003
ну т.е. у вас сначала ищутся все InventDimId с заданной партией, потом уже выбираются остатки.
т.е. индекс который я предложил однозначно ускорит этот процесс(за счет доп фильтрации по тому же складу)
а с вашим индексом какой план?
Теги
axapta, dynamics ax, sql server, tuning

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
emeadaxsupport: AX Performance - Analyzing key SQL Server configuration and database settings Blog bot DAX Blogs 0 28.09.2015 14:11
emeadaxsupport: AX Performance Troubleshooting Checklist Part 1A [Introduction and SQL Configuration] Blog bot DAX Blogs 0 05.09.2014 21:11
emeadaxsupport: How to perform a data center change (change of the physical location) where a SQL server 2008 R 2 cluster installation and MS Dynamics AX 4.0 is involved? Blog bot DAX Blogs 0 21.06.2014 19:19
dynamicsaxbi: Better together: Microsoft Dynamics AX 2012 R2 and SQL Server Power View Blog bot DAX Blogs 0 12.12.2012 13:11
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход


Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 22:55.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.