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

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 07.11.2012, 16:23   #1  
fed is offline
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,890 / 5647 (194) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
Проблемы с кэшированием inventSum в DAX2012
Коллега показал интересную граблю. Я пока не уверен на 100% что это системная бага, но очень похоже что это так, так что я решил поделиться. Итак: DAX2012 CU3 (без feature pack). Коллега написал маленький дисплейный метод, который тупо выводит для строки заказа незарезервированный остаток. (Не самый лучший способ с точки зрения производительности, но клиент хочет, да и по большому счету проблема не в этом). Демонстрировал мне несколько раз такую картину: По строке заказа ноль. Он запускает развертывание, система создает плановую закупку, он его утверждает и разносит накладную. Возвращается в заказ и рефрешит строку - там по прежнему ноль. Далее коллега идет и синхронизирует inventSum. Заказ показывает правильный остаток. Дальше по заказу разносится отоброчная накладная. Опять - в строке заказа показывает доступное количество (ненулевое). Если опять отсинхронизировать inventSum, количество меняется на правильное - нулевое.
К своему глубокому изумлению, обнаружил что в inventSum стоит кэширование в режиме notInTTS. Причем стоит давно - по крайней мере с версии 2009. Моя гипотеза, почему вся эта ситуация происходит:
1. Как известно, в большинстве случаев, inventSum обновляется через directSQL. (Исключение - ситуации когда транзакция должна обновить всего одну строку в inventSum).
2. Система кэширования AOS не отслеживает обновлений через directSQL, и продолжает хранить в кэше старые данные. Соответственно - чтения данных через inventOnHand или большая часть прямых запросов через inventSum обрабатываются из кэша и возвращают старые данные.
3. В старых версиях аксапты, эта грабля не порождала такого множества проблем, поскольку в старых версиях из кэша обрабатывались только простейшие запросы с запросом из одной таблицы с всеми полями уникального индекса с выражении where. Поскольку 99% процентов запросов по inventSum идут с джойном по inventDim, механизм кэширования не срабатывал, и данные вытаскивались каждый раз из сиквела. В 2012ой поддержали кэширование для джойнов (возможно не для всех случаев, но для части - точно поддержали) и грабля сработала.

В общем - мы до уточнения тупо отключили кэширование inventSum. Похоже что шансы неправильной работы inventOnHand за пределами транзакции - достаточно высоки, а дополнительная нагрузка от показа количеств на складе во всяких отчетах и дисплейных формах - незапредельная.
Кроме того - я вообще не вижу большого смысла включать какое-либо кэширование у такой волатильной таблицы как inventSum. Я еще могу понять режим NotInTTS для заказов и закупок (обычно их только один человек правит и вероятность конфликта невысока), но понять кто и зачем включил этот режим для inventSum (даже если забыть грабли с directSQL) - я не могу...
За это сообщение автора поблагодарили: macklakov (5), Владимир Максимов (5), Pustik (5), sukhanchik (7), Logger (5), Greggy (1), lev (5), MikeR (5), gl00mie (3), Stitch_MS (2), shogel (1), S.Kuskov (5).
Старый 07.11.2012, 17:02   #2  
Stitch_MS is offline
Stitch_MS
Участник
Аватар для Stitch_MS
Соотечественники
 
396 / 478 (16) +++++++
Регистрация: 27.02.2006
Адрес: Дания
Цитата:
Сообщение от fed Посмотреть сообщение
...но понять кто и зачем включил этот режим для inventSum (даже если забыть грабли с directSQL) - я не могу...
Возможно, если изменение не очень старое, то коллеги из MS могли бы дать ответ, проверив историю таблицы.
Старый 07.11.2012, 18:14   #3  
Владимир Максимов is offline
Владимир Максимов
Участник
КОРУС Консалтинг
 
1,649 / 1146 (42) ++++++++
Регистрация: 13.01.2004
Записей в блоге: 3
Цитата:
Сообщение от Stitch_MS Посмотреть сообщение
Возможно, если изменение не очень старое, то коллеги из MS могли бы дать ответ, проверив историю таблицы.
Изменение ОЧЕНЬ старое. Еще в Ax2.5 стояло NotInTTS. Скорее всего, этот режим не то, чтобы включили, а просто не меняли, при переходе на новые версии.
__________________
- Может, я как-то неправильно живу?!
- Отчего же? Правильно. Только зря...
За это сообщение автора поблагодарили: macklakov (5).
Старый 13.11.2012, 17:05   #4  
kashperuk is offline
kashperuk
Участник
Аватар для kashperuk
MCBMSS
Соотечественники
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,361 / 2084 (78) +++++++++
Регистрация: 30.05.2004
Адрес: Atlanta, GA, USA
А можете выложить проектик, чтобы удобно было воспроизвести?

Теоретически, да, такое может быть. Но непотяно, насколько это реально актуально
Старый 13.11.2012, 17:20   #5  
kashperuk is offline
kashperuk
Участник
Аватар для kashperuk
MCBMSS
Соотечественники
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,361 / 2084 (78) +++++++++
Регистрация: 30.05.2004
Адрес: Atlanta, GA, USA
А он дисплей метод случаем не кэшировал на форме?
Старый 13.11.2012, 17:21   #6  
fed is offline
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,890 / 5647 (194) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
Цитата:
Сообщение от kashperuk Посмотреть сообщение
А он дисплей метод случаем не кэшировал на форме?
Не дисплей метод. Он для проверки вообще тупой джобик написал с запросом по inventSum. Проектик постараюсь выпросить у него чуть позже...
Старый 13.11.2012, 18:26   #7  
kashperuk is offline
kashperuk
Участник
Аватар для kashperuk
MCBMSS
Соотечественники
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,361 / 2084 (78) +++++++++
Регистрация: 30.05.2004
Адрес: Atlanta, GA, USA
Только что зарепродьюсил с горем пополам.
Узнаю, что можно сделать на данный момент с этим.
За это сообщение автора поблагодарили: fed (5), EVGL (5).
Старый 13.11.2012, 18:42   #8  
fed is offline
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,890 / 5647 (194) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
Цитата:
Сообщение от kashperuk Посмотреть сообщение
Только что зарепродьюсил с горем пополам.
Узнаю, что можно сделать на данный момент с этим.
А что за горе то, если не секрет ? Я уверен, что это точно репродьюситься если ты запрашиваешь строку inventSum по itemId и inventDimId, и подозреваю что иногда это случается и на штатных запросах с джойном...
Старый 13.11.2012, 19:12   #9  
kashperuk is offline
kashperuk
Участник
Аватар для kashperuk
MCBMSS
Соотечественники
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,361 / 2084 (78) +++++++++
Регистрация: 30.05.2004
Адрес: Atlanta, GA, USA
Ну, горе было не с репродьюсингом, а с понятием, из-за чего именно проблема.
Это случается только в двух случаях:

1. Если InventSum обновляется через DirectSQL (как в случае выше), из другого connection
2. Если InventSum обновляется через другой UserConnection, но почему-то только если это происходит из другого клиента (неважно на сервере или клиенте).

Помогает flush таблицы, но в первом случае он обязательно должен выполняться на сервере
Старый 14.11.2012, 18:45   #10  
kashperuk is offline
kashperuk
Участник
Аватар для kashperuk
MCBMSS
Соотечественники
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,361 / 2084 (78) +++++++++
Регистрация: 30.05.2004
Адрес: Atlanta, GA, USA
Итого, в 6.2 его не пофиксили, потому что уже слишком поздно.
Но я настоял на том, чтобы попробовать его пофиксить через SE канал, как hotfix.
Как заинвестигейтим хороший фикс, дам знать.
Старый 14.11.2012, 19:33   #11  
fed is offline
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,890 / 5647 (194) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
Мне кажется, что лучший фикс - это запрет кэширования inventSum. Просто не могу ни одной практической ситуации придумать, где это кэширование было бы полезно.
За это сообщение автора поблагодарили: Logger (3).
Старый 14.11.2012, 19:58   #12  
Pustik is offline
Pustik
Участник
 
807 / 372 (14) ++++++
Регистрация: 04.06.2004
а если 2 раза подряд нажимать кнопку в наличии (для всех номенклатур)?
__________________
-Ты в гномиков веришь?
-Нет.
-А они в тебя верят, смотри, не подведи их.
Старый 14.11.2012, 20:51   #13  
Pustik is offline
Pustik
Участник
 
807 / 372 (14) ++++++
Регистрация: 04.06.2004
ох ты, сейчас внимательно рассмотрел - конкретная бага
__________________
-Ты в гномиков веришь?
-Нет.
-А они в тебя верят, смотри, не подведи их.
Старый 15.11.2012, 09:34   #14  
BAx is offline
BAx
Участник
Аватар для BAx
 
14 / 11 (1) +
Регистрация: 03.10.2006
Адрес: Екатеринбург
У нас подобная бага была ( Ax3 SP4 Oracle 11).
Проблема решилось при CasheLookup = None.
Плюсом заметно сократились касты в запросах к этой табл.
__________________
Axapta 3 SP4 KR3; Oracle 11.2.0.2.0
Старый 15.11.2012, 12:35   #15  
kashperuk is offline
kashperuk
Участник
Аватар для kashperuk
MCBMSS
Соотечественники
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,361 / 2084 (78) +++++++++
Регистрация: 30.05.2004
Адрес: Atlanta, GA, USA
Кстати, одной из причин не фиксить это прям сейчас было отсутствие SE багов про это.
Здесь уже упомянута 2 раза такая проблема - почему никто не зарепортил на MS Connect?
Старый 15.11.2012, 13:10   #16  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,860 / 3109 (111) ++++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
Цитата:
Сообщение от BAx Посмотреть сообщение
Плюсом заметно сократились касты в запросах к этой табл.
А это-то почему ?
Старый 15.11.2012, 13:15   #17  
kashperuk is offline
kashperuk
Участник
Аватар для kashperuk
MCBMSS
Соотечественники
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,361 / 2084 (78) +++++++++
Регистрация: 30.05.2004
Адрес: Atlanta, GA, USA
и что вообще такое касты?
Старый 19.11.2012, 13:01   #18  
BAx is offline
BAx
Участник
Аватар для BAx
 
14 / 11 (1) +
Регистрация: 03.10.2006
Адрес: Екатеринбург
Цитата:
Сообщение от Logger Посмотреть сообщение
А это-то почему ?
Извиняюсь, хотел написать не "касты", а costы.
Уточню: заметно сократилось время выполнения запросов при обращении к InventSum как на чтение, так и на update. Косты замерял в PL-SQL developer. Рассинхронизация данных до этого наблюдалась между АОСами.
Связано это с тем, что данная таблица у нас практически постоянно апдэйтится (одна и та же запись), причем с разных АОСов. К тому же она немного шире, чем в стандарте (свои доработки). Часто наблюдалась ситуация, когда транзакции выстраивались в очередь и нервно-курили в ожидании завершения какого-нибудь относительно долгого запроса на update.
__________________
Axapta 3 SP4 KR3; Oracle 11.2.0.2.0
Старый 19.11.2012, 13:27   #19  
Vadik is offline
Vadik
Модератор
Аватар для Vadik
Лучший по профессии 2017
Лучший по профессии 2015
 
3,631 / 1849 (69) ++++++++
Регистрация: 18.11.2002
Адрес: гражданин Москвы
Цитата:
Сообщение от BAx Посмотреть сообщение
Извиняюсь, хотел написать не "касты", а costы.
Уточню: заметно сократилось время выполнения запросов при обращении к InventSum как на чтение, так и на update. Косты замерял в PL-SQL developer
Меняем кэширование на сервере приложений - меняются косты на сервере БД ?
__________________
-ТСЯ или -ТЬСЯ ?
Старый 19.11.2012, 17:29   #20  
BAx is offline
BAx
Участник
Аватар для BAx
 
14 / 11 (1) +
Регистрация: 03.10.2006
Адрес: Екатеринбург
Цитата:
Сообщение от Vadik Посмотреть сообщение
Меняем кэширование на сервере приложений - меняются косты на сервере БД ?
и да и нет...
если взять отдельный запрос - то план исполнения и косты одинаковые естественно будут.
Но если смотреть в целом с учетом взаимных блокировок (а БД надо получить актуальные на данный момент времени данные, для чего синхронизировать инф из кэша), то суммарная разница в костах (не по запросам) в разы отличается. к таму же при сильной загузке видны блокировки и переполнение tmp tablespace При полном отключении кэширования таблицы на АОСе/клиенте данные сразу пишутся в БД (точнее в кэш БД, но это уже не важно. главное все клиенты видят синхронизированные данные).
__________________
Axapta 3 SP4 KR3; Oracle 11.2.0.2.0
 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
Запрос к InventSum с InventLocationId Rimantas DAX: Программирование 11 11.01.2012 22:30
Dynamics AX Sustained Engineering: Fields modifiedDateTime and modifiedBy on Table InventSum Blog bot DAX Blogs 0 30.12.2010 00:12
InventSum Alexanderrrr DAX: Функционал 18 12.01.2010 07:43
Ошибка при разноске складских движений Starling DAX: Администрирование 9 12.10.2007 14:21
Форма InventOnhandItem, Почему RecID у InventSum в этой форме всегда 0? Кирилл DAX: Программирование 2 25.05.2004 18:15
Опции темы Поиск в этой теме
Поиск в этой теме:

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

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

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

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