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

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 02.08.2017, 17:18   #1  
Masel is offline
Masel
Участник
 
25 / 418 (14) +++++++
Регистрация: 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,436 / 2297 (83) +++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
А может быть проводки по сопоставлению вам создал пересчет себестоимости, который может запускаться автоматом после закрытия склада? Просто у них ваучеры совпали. (Номерные серии разные, по идее такое возможно при определенных настройках). Правда даты в Inventsettlement должны быть разными тогда. Вы их сравнивали ?
Старый 03.08.2017, 09:35   #3  
Masel is offline
Masel
Участник
 
25 / 418 (14) +++++++
Регистрация: 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,579 / 4964 (171) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
Я такое видел в DAX2009. Причем проблемы обработки constraints, почему-то случались только в случае Runtime Batch Job. В какой-то из своих доработок, я просто заменил RuntimeJob на стандартный. В общем - это не барабашка, это действительно иногда случается. Однако же закономерностей я не нашел...
Старый 03.08.2017, 10:06   #5  
Alexius is offline
Alexius
Участник
Аватар для Alexius
 
461 / 243 (9) ++++++
Регистрация: 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,436 / 2297 (83) +++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
Цитата:
Сообщение от Alexius Посмотреть сообщение
Времени на детальный разбор не предвиделось и была сделана затычка в виде блокировочной таблички, которая не дает обновлять Batch в классе BatchRun одновременно с нескольких AOSов.
Интересно.
На первый взгляд, примерно такую защиту предоставляет табличка batchGlobal и код по ее блокировке в методах
BatchRun::ServerGet*
BatchRun::ServerProcess*

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

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

PS. Изменение уровня изоляции транзакций не улучшает ситуацию.
PS2. Затыкания только в serverProcessDependencies недостаточно, надо лопатить во всех методах на изменение Batch.
Старый 03.08.2017, 10:46   #8  
Alexius is offline
Alexius
Участник
Аватар для Alexius
 
461 / 243 (9) ++++++
Регистрация: 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,436 / 2297 (83) +++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
А какая была версия SQL Server?
Старый 04.08.2017, 09:15   #10  
Alexius is offline
Alexius
Участник
Аватар для Alexius
 
461 / 243 (9) ++++++
Регистрация: 13.12.2001
Цитата:
Сообщение от Logger Посмотреть сообщение
А какая была версия SQL Server?
MS SQL 2012
Старый 04.08.2017, 09:31   #11  
macklakov is offline
macklakov
NavAx
Аватар для macklakov
 
1,969 / 878 (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,605 / 5325 (185) ++++++++++
Регистрация: 28.11.2005
Адрес: Москва
Записей в блоге: 2
Для истории: есть KB 3216955 KB 3216955, Bug Id 3804879 "Continuous dead locks in batch" для AX 2012 R2, где реализован целый ряд исправлений в классе BatchRun. Они сводятся к тому, чтобы при обновлении таблиц пакетной инфраструктуры вместо оптимистичной конкуренции использовать mutex на уровне СУБД, управляемый с помощью класса ReqReaderWriterLock. Такой подход позволяет надежно синхронизировать различные потоки пакетных обработчиков, в том числе выполняющиеся на разных пакетных серверах. См. также соотв. изменения в коде.
Старый 10.02.2021, 17:11   #13  
kgksoft is offline
kgksoft
Участник
 
36 / 107 (4) +++++
Регистрация: 24.12.2003
Post Заметки о BatchRun
2012 R3. Внесены все изменения по мьютексам в BatchRun и даже больше (ускоряющие хинты), но неожиданно всплыла очень медленная вставка в таблицу BatchConstraintsHistory. Из-за этого другие пакетники нарываются на блокировку мьютекса и ничего не стартует и не двигается десятками минут. Переиндексации и обновление статистик тут особо не работают, так как таблички часто меняются, а структура запроса не позволяла применить стандартные мантры хинтов из 2012 (forceSelectOrder forceNestedLoop). Но удалось переписать и этот запрос. Может кому-то пригодится.

BatchRun.serverProcessFinishedJobs


Оригинальный код:
X++:
        insert_recordset batchConstraintsHistory
            (BatchId, ExpectedStatus, DependsOnBatchId)
        select RecId from batchHistory
            join ExpectedStatus from batchConstraints
                where batchHistory.BatchId == batchConstraints.BatchId
            join RecId from batchHistoryDepends
                where batchHistoryDepends.BatchId == batchConstraints.DependsOnBatchId
            exists join batchJobHistory
                where batchJobHistory.Finishing == 1 && batchJobHistory.RecId == batchHistory.BatchJobHistoryId
                && batchJobHistory.RecId == batchHistoryDepends.BatchJobHistoryId;
Заменил на:
X++:
        insert_recordset batchConstraintsHistory
            (DependsOnBatchId, ExpectedStatus, BatchId)
        select forcePlaceholders forceSelectOrder forceNestedLoop batchJobHistory
            where batchJobHistory.Finishing == 1
        join RecId
        from batchHistoryDepends
            where batchHistoryDepends.BatchJobHistoryId == batchJobHistory.RecId
        join ExpectedStatus
        from batchConstraints
            where batchConstraints.DependsOnBatchId == batchHistoryDepends.BatchId
        join RecId
        from batchHistory
            where batchHistory.BatchJobHistoryId == batchJobHistory.RecId
                && batchHistory.BatchId == batchConstraints.BatchId;
За это сообщение автора поблагодарили: A_BAS (2), Logger (3).
Старый 11.02.2021, 05:51   #14  
trud is offline
trud
Участник
Лучший по профессии 2017
 
947 / 1297 (45) ++++++++
Регистрация: 07.06.2003
Записей в блоге: 1
Цитата:
Сообщение от gl00mie Посмотреть сообщение
Для истории: есть KB 3216955 KB 3216955, Bug Id 3804879 "Continuous dead locks in batch" для AX 2012 R2, где реализован целый ряд исправлений в классе BatchRun. Они сводятся к тому, чтобы при обновлении таблиц пакетной инфраструктуры вместо оптимистичной конкуренции использовать mutex на уровне СУБД, управляемый с помощью класса ReqReaderWriterLock. Такой подход позволяет надежно синхронизировать различные потоки пакетных обработчиков, в том числе выполняющиеся на разных пакетных серверах. См. также соотв. изменения в коде.
А кстати кто-нибудь включал это обновление?
Просто установить недостаточно, необходимо еще включить, вставив запись в sysGlobalConfig
Мы пробовали сделать на одном из клиентов(у них очень много пакетных заданий), в итоге это работало где-то день, потом все зависло. Т.е. какая-то сессия взяла этот мутекс и при этом ничего не делала.
Попробовали еще раз, такая же история через день.
В итоге решили что постоянные деадлоки это меньшее зло, чем полностью зависающая система
Вопрос - кто нибудь побеждал эти деадлоки(они встречаются практически на всех клиентах, где несколько пакетных АОСов) и если да, то как?
X++:
#define.ConfigName_EnableBatchRunServerTaskLock('EnableBatchRunServerTaskLock')

    select Value from sysGlobalConfig
        where sysGlobalConfig.Name == #ConfigName_EnableBatchRunServerTaskLock;
Старый 11.02.2021, 08:36   #15  
kgksoft is offline
kgksoft
Участник
 
36 / 107 (4) +++++
Регистрация: 24.12.2003
У меня используются эти мьютексы. Но я точечно изменения из CU13 перенес. Там все прозрачно и не проверяется ничего из sysGlobalConfig. Подвисания были как раз из-за batchConstraintsHistory, но моя правка свежая и утверждать, что проблема ушла окончательно еще не могу.
Старый 11.02.2021, 08:51   #16  
trud is offline
trud
Участник
Лучший по профессии 2017
 
947 / 1297 (45) ++++++++
Регистрация: 07.06.2003
Записей в блоге: 1
В стандарте это точно надо включать. А можете запустить sp_BlitzLock для базы? она покажет как раз все деадлоки с момента последнего рестарта сервера, интерестно, будут ли там таблицы с Batch..
За это сообщение автора поблагодарили: Logger (1), AlGol (3).
Старый 11.02.2021, 14:31   #17  
kgksoft is offline
kgksoft
Участник
 
36 / 107 (4) +++++
Регистрация: 24.12.2003
Цитата:
Сообщение от trud Посмотреть сообщение
В стандарте это точно надо включать. А можете запустить sp_BlitzLock для базы? она покажет как раз все деадлоки с момента последнего рестарта сервера, интерестно, будут ли там таблицы с Batch..
Запустил. Интересная процедура. 42 минуты работала. Дедлоки есть по Batch, но это не про то и их мало

X++:
(@P1 int,@P2 datetime2,@P3 datetime2,@P4 int,@P5 int,@P6 int,@P7 int)
UPDATE BATCH SET STATUS=@P1,ENDDATETIME=@P2,MODIFIEDDATETIME=@P3,RECVERSION=@P4,ENDDATETIMETZID=@P5 
WHERE (STATUS=@P6) AND NOT (EXISTS (SELECT 'x' FROM SYSCLIENTSESSIONS T2 WITH ( READCOMMITTEDLOCK) 
WHERE (((BATCH.SESSIONIDX=T2.SESSIONID) AND (BATCH.SESSIONLOGINDATETIME=T2.LOGINDATETIME)) AND (T2.STATUS!=@P7))))
и

X++:
(@P1 int,@P2 datetime2,@P3 int,@P4 datetime2,@P5 bigint,@P6 int)
UPDATE BATCH SET STATUS=@P1,ENDDATETIME=@P2,RECVERSION=@P3,MODIFIEDDATETIME=@P4 
WHERE ((RECID=@P5) AND (RECVERSION=@P6))
скорее всего это коды из serverCleanUpDeadTasks и serverFinishTask. Т.е. задание завершилось и клиентской сессии уже нет и тут раз в 5 минут неудачно запустилась serverCleanUpDeadTasks .

Еще нашел дедлок по BATCHHISTORY. Но это тогда когда вставка еще долго могла выполнятся и пересечение с удалением из этой же таблицы. Удаления в BatchRun нет. Это удаление скорее всего из модуля WHS прилетело.
Старый 11.02.2021, 14:56   #18  
trud is offline
trud
Участник
Лучший по профессии 2017
 
947 / 1297 (45) ++++++++
Регистрация: 07.06.2003
Записей в блоге: 1
Цитата:
Сообщение от kgksoft Посмотреть сообщение
Запустил. Интересная процедура. 42 минуты работала. Дедлоки есть по Batch, но это не про то и их мало
Ну если 42 минуты работала, там наверняка много чего другого ну т.е. этот фикс как я понимаю все же полностью проблему не решает
Старый 11.02.2021, 15:09   #19  
kgksoft is offline
kgksoft
Участник
 
36 / 107 (4) +++++
Регистрация: 24.12.2003
Да, нашло много интересного. Да и SQL-сервер идет на рекорд 106 дней без перезагрузки.

Думаю что Batch проблема решается. Когда пакетных аосов много, то дедлоков тоже много. Проблемы глобальной как бы и нет, но когда смотришь на логи винды на аосах, то видишь сообщения о дедлоках. Раньше их было много. Теперь можно сказать, что нет совсем.
Расположение кода с блокировкой мьютексов в стандарте вызывает вопросы. Почему они написаны после обновления GLOBAL-таблицы. Если бы стояли до, то меньше бы раз вызывались операции.
Теги
ax2012, 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, время: 22:21.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.