AXForum  
Вернуться   AXForum > Прочие обсуждения > Курилка
All
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 19.05.2023, 11:22   #32  
gl00mie is offline
gl00mie
Участник
MCBMSS
Most Valuable Professional
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,684 / 5788 (200) ++++++++++
Регистрация: 28.11.2005
Адрес: Москва
Записей в блоге: 3
Разбирался тут с "тяжелыми" запросами и в том числе обнаружил там такое:
PHP код:
UPDATE T1 SET ACCOUNTINGEVENT=5665953399,RECVERSION=4567933
FROM ACCOUNTINGDISTRIBUTION T1 WITH 
(INDEX(I_7452SOURCEDOCUMENTHEADERIDX))
CROSS JOIN SOURCEDOCUMENTLINE T2
WHERE 
(((T1.PARTITION=5637144576) AND (T1.ACCOUNTINGEVENT=0)
AND (
T1.ACCOUNTINGDATE={ d'2023-05-19'}))
AND (
T1.SOURCEDOCUMENTHEADER=5669290320))
AND ((
T2.RECID=T1.SOURCEDOCUMENTLINE)
AND (
T2.ACCOUNTINGSTATUS=OR T2.ACCOUNTINGSTATUS=6))
AND (
T2.PARTITION=5637144576
Казалось бы, что с ним не так? А то, что он не использует параметры и плодит, собака, сотни одинаковых планов запроса, которые вымывают из кэша другие более полезные планы запросов. С помощью "триангуляции" обнаружил, что такие запросы генерятся (в DAX2012 R3) из AccountingEventSourceDocumentProcessor::updateDistributionsForEvent(). Спрашивается, что мешало смастерить там прямой SQL-запрос с параметрами, чтобы он не плодил кучу одинаковых планов запросов?..
Теги
axapta, cil, d365fo, guid, rasset, uuid, uuidv7, баг

 


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

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

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