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

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 02.08.2017, 17:18   #1  
Masel is offline
Masel
Участник
 
17 / 17 (1) ++
Регистрация: 19.09.2007
Пакетные задания - batchConstraint (AX 2012 R2)
Тут недавно произошло неприятное событие - некорректно прошел пересчет склада. При разноске ГК система взяла не все сопоставления. Соответственно, ваучер сопоставления неполный и не во всех сопоставлениях (с заполненными счетами) проставлен признак Posted. Расследование показало, что задача Завершение уровня расчета стартанула еще до завершения связанных подзадач (из BatchConstraint), быстро завершилась и создала задачу разноски в ГК, а задачи по генерации сопоставлений продолжили выполняться и нагенерили необработанных сопоставлений.
Есть подозрение, что некорректно работает подсистема пакетных заданий, а именно метод BatchRun::serverProcessDependencies.
В этом методе у МС зачем то ставятся принудительно хинты readCommittedLock. Я вот грешным делом думал, что read commited и так используется в аксапте всегда, если точнее read commited snapshot. Но то ли МС об этом не знает, то ли этот метод особенный. Если метод особенный, то меня смущает, что для таблицы Batch в методе нету хинта:
X++:
batchJob.readCommittedLock(true);
constraintsOr.readCommittedLock(true);
batchDependsOr.readCommittedLock(true);
constraintsAnd.readCommittedLock(true);
batchDependsAnd.readCommittedLock(true);
Если предположить, что там по умолчанию грязное чтение, то может быть ситуация, что запись Batch видна, а ограничения (BatchConstraint) система не видит и спокойно обновляет статус.

Кто что думает по этому поводу? Либо можно все списать на барабашку.
Старый 03.08.2017, 09:07   #2  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,069 / 1795 (66) ++++++++
Регистрация: 12.10.2004
А может быть проводки по сопоставлению вам создал пересчет себестоимости, который может запускаться автоматом после закрытия склада? Просто у них ваучеры совпали. (Номерные серии разные, по идее такое возможно при определенных настройках). Правда даты в Inventsettlement должны быть разными тогда. Вы их сравнивали ?
Старый 03.08.2017, 09:35   #3  
Masel is offline
Masel
Участник
 
17 / 17 (1) ++
Регистрация: 19.09.2007
Цитата:
Сообщение от Logger Посмотреть сообщение
А может быть проводки по сопоставлению вам создал пересчет себестоимости, который может запускаться автоматом после закрытия склада? Просто у них ваучеры совпали. (Номерные серии разные, по идее такое возможно при определенных настройках). Правда даты в Inventsettlement должны быть разными тогда. Вы их сравнивали ?
Так закрытия не было. Был только пересчет.
Вообще в ваучер попал только первый InventSettlement. По времени формирование ваучера и формирование сопоставлений стартанули в одну секунду. И разноска в ГК естественно завершилась сильно раньше формирования InventSettlement.

Последний раз редактировалось Masel; 03.08.2017 в 09:38.
За это сообщение автора поблагодарили: Logger (1).
Старый 03.08.2017, 09:58   #4  
fed is offline
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,304 / 4328 (149) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
Я такое видел в DAX2009. Причем проблемы обработки constraints, почему-то случались только в случае Runtime Batch Job. В какой-то из своих доработок, я просто заменил RuntimeJob на стандартный. В общем - это не барабашка, это действительно иногда случается. Однако же закономерностей я не нашел...
Старый 03.08.2017, 10:06   #5  
Alexius is offline
Alexius
Участник
Аватар для Alexius
 
437 / 228 (8) ++++++
Регистрация: 13.12.2001
Было такое, расследование показало, что MS SQL некорректно выполняет сформированные в данном методе запросы с exists/notexists join когда они выполняются одновременно с другими запросами на обновление Batch. Времени на детальный разбор не предвиделось и была сделана затычка в виде блокировочной таблички, которая не дает обновлять Batch в классе BatchRun одновременно с нескольких AOSов.
За это сообщение автора поблагодарили: Logger (3).
Старый 03.08.2017, 10:17   #6  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,069 / 1795 (66) ++++++++
Регистрация: 12.10.2004
Цитата:
Сообщение от Alexius Посмотреть сообщение
Времени на детальный разбор не предвиделось и была сделана затычка в виде блокировочной таблички, которая не дает обновлять Batch в классе BatchRun одновременно с нескольких AOSов.
Интересно.
На первый взгляд, примерно такую защиту предоставляет табличка batchGlobal и код по ее блокировке в методах
BatchRun::ServerGet*
BatchRun::ServerProcess*

Вы не пробовали просто ее задействовать ?
Хотя возможно я ошибаюсь - глубоко не вникал.
Старый 03.08.2017, 10:31   #7  
Alexius is offline
Alexius
Участник
Аватар для Alexius
 
437 / 228 (8) ++++++
Регистрация: 13.12.2001
Цитата:
Сообщение от Logger Посмотреть сообщение
На первый взгляд, примерно такую защиту предоставляет табличка batchGlobal и код по ее блокировке в методах
BatchRun::ServerGet*
BatchRun::ServerProcess*

Вы не пробовали просто ее задействовать ?
Хотя возможно я ошибаюсь - глубоко не вникал.
Возможно и так, я тоже глубоко не вникал, т.к. ятаганы очень близко и мерзко свистели. Поэтому был выбран "топорный" путь, который работает.

PS. Изменение уровня изоляции транзакций не улучшает ситуацию.
PS2. Затыкания только в serverProcessDependencies недостаточно, надо лопатить во всех методах на изменение Batch.
Старый 03.08.2017, 10:46   #8  
Alexius is offline
Alexius
Участник
Аватар для Alexius
 
437 / 228 (8) ++++++
Регистрация: 13.12.2001
Откопал из загашников запросик, кажется это тот, на котором я ловил ошибочное поведение MS SQL :
X++:
BEGIN TRAN

UPDATE BATCH 
SET STATUS=5
WHERE ((STATUS=1) AND (CONSTRAINTTYPE=0)) 
  AND EXISTS (
    SELECT 'x' 
    FROM BATCHJOB T2 WITH ( READCOMMITTEDLOCK) 
    WHERE ((T2.STATUS=2) AND (BATCH.BATCHJOBID=T2.RECID)) AND NOT (EXISTS (
      SELECT 'x' 
      FROM BATCHCONSTRAINTS T3 WITH ( READCOMMITTEDLOCK) 
      WHERE EXISTS (
        SELECT 'x' 
        FROM BATCH T4 WITH ( READCOMMITTEDLOCK) 
        WHERE (((T3.DEPENDSONBATCHID=T4.RECID) AND (T3.BATCHID=BATCH.RECID)) AND ((((T4.STATUS<>3) AND (T4.STATUS<>4)) OR ((T3.EXPECTEDSTATUS=4) AND (T4.STATUS=3))) OR ((T3.EXPECTEDSTATUS=4) AND (T4.STATUS=3))))))))

--COMMIT TRAN
--ROLLBACK TRAN
Желающие могут провести собственные изыскания на нем:
1. Создать тестовую среду
2. Открыть и запустить запросик в одном окне SSMS без завершения транзакции
3. Открыть и запустить запросик во втором окне SSMS без завершения транзакции
4. Завершить транзакции в первом и затем во втором окне (или наоборот)
5. Насладится результатами
За это сообщение автора поблагодарили: Logger (5), Raven Melancholic (10).
Старый 03.08.2017, 10:53   #9  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,069 / 1795 (66) ++++++++
Регистрация: 12.10.2004
А какая была версия SQL Server?
Старый 04.08.2017, 09:15   #10  
Alexius is offline
Alexius
Участник
Аватар для Alexius
 
437 / 228 (8) ++++++
Регистрация: 13.12.2001
Цитата:
Сообщение от Logger Посмотреть сообщение
А какая была версия SQL Server?
MS SQL 2012
Старый 04.08.2017, 09:31   #11  
macklakov is offline
macklakov
NavAx
Аватар для macklakov
 
1,970 / 877 (33) +++++++
Регистрация: 03.04.2002
Адрес: Australia
Цитата:
Сообщение от Masel Посмотреть сообщение
Кто что думает по этому поводу? Либо можно все списать на барабашку.
Поспрашайте в MS свежие хотфиксы. Мы им багов по поводу batchJobs в R2 насыпали изрядно и они почти все пофиксили.
__________________
Isn't it nice when things just work?
Старый 17.09.2018, 13:24   #12  
gl00mie is offline
gl00mie
Участник
MCBMSS
Most Valuable Professional
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,550 / 5050 (176) ++++++++++
Регистрация: 28.11.2005
Адрес: Москва
Для истории: есть KB 3216955 KB 3216955, Bug Id 3804879 "Continuous dead locks in batch" для AX 2012 R2, где реализован целый ряд исправлений в классе BatchRun. Они сводятся к тому, чтобы при обновлении таблиц пакетной инфраструктуры вместо оптимистичной конкуренции использовать mutex на уровне СУБД, управляемый с помощью класса ReqReaderWriterLock. Такой подход позволяет надежно синхронизировать различные потоки пакетных обработчиков, в том числе выполняющиеся на разных пакетных серверах. См. также соотв. изменения в коде.
Теги
batch, batchrun, баг, закрытие склада

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
emeadaxsupport: AX Performance - Analyzing key SQL Server configuration and database settings Blog bot DAX Blogs 0 28.09.2015 14:11
emeadaxsupport: AX for Retail 2012 R2: Run-down on Log Files Blog bot DAX Blogs 0 21.06.2013 08:11
emeadaxsupport: AX for Retail 2012 R2: Installing the Real-time Service Blog bot DAX Blogs 0 19.12.2012 11:11
dynamicsaxtraining: Purchase Blog bot DAX Blogs 0 11.03.2012 05:25
dynamics-ax: Interview with Microsoft's Lachlan Cash on his new role, AX 2012 and more Blog bot DAX Blogs 6 22.04.2011 14:55
Опции темы Поиск в этой теме
Поиск в этой теме:

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

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

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

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