AX2009: Ошибка оптимистической модели обновления

[DSPIC]

AX2009 SP1 RU6, SQL2008 R2. Один физический сервер, 15 Gb RAM
Ну вот, мы уже съели последний зуб, но на протяжении нескольких месяцев, но так и не можем решить эту проблему. И рыть больше некуда. Караул!
В системе возникают конфликты обновления вида:

Цитата:

Object Server 01: Optimistic Concurrency: Обновить конфликт, выявленный при выполнении следующего (с параметрами): UPDATE SOBJECTBALANCE SET BALANCEDAYS=?,CALCDATE=?,RECVERSION=?,MODIFIEDDATETIME=?,MODIFIEDBY=? WHERE (((DATAAREAID=?) AND (PIN=?)) AND (RECVERSION=?)) ; -378 ; 2011-3 ; 4620762011-03-2 ; 'malki ; '5' ; '11358 ; 429295

Конфликты обновления возникают на любых таблицах - как системных, так и всех остальных - выше один из примеров.

Итак: AOS и SQL на одной физическом сервере. Физически перегружаем сервер, пускаем пользователей. Несколько часов (а иногда день, два, три, четыре) все идет хорошо. Журнал ошибок Windows чистенький. Затем изредка проскакивают сообщения (информационные) вида выше. Затем их становится больше. При этом, они всё ещё информационные, и на работе пользователей не отражаются (т.е. у пользователя не выскакивает инфолог с соотв. ошибкой). Но ещё позже таких ошибок становится просто шквал и тут уж среди этого шквала проявляются уже не информационные ошибки, а настоящие, вида:

Цитата:

Object Server 01: Dialog issued for client-less session 2: Cannot edit a record in Current client sessions (SysClientSessions).
An update conflict occurred due to another user process deleting the record or changing one or more fields in the record.

И вот такие ошибки уже отражаются и дублируются в пользовательском инфологе. Далее эта лавина продолжает наростать - конфликтов обновления становится всё больше и больше (доходит до периодичности в 15-20 секунд). Возникают они при любом телодвижении пользователся, например безобидное закрытие какой-нибудь формы или вход в систему; ну а если уж операцию какую запустить... . Всё заканчивается перезагрузкой АОСа (либо вручную, либо сам дохнет). Но перезагрузка АОСа помогает ненадолго, на пару часов. А вот если рестартануть весь сервак, то чуть по-дольше - день, два.
Эти конфликты обновления возникают совершенно на любых таблицах аксапты, даже на тех, которые гарантированно использует только один пользователь (эксперементировали). Ну вот, вкрадце все. Что делать, как диагностировать?
Пока я склонен грешить на железо. Планируем развернуть ещё один сервер и пробовать на другом железе, либо разнести АОС и SQL, либо ещё как-то...

[Logger]

Если в итоге все доходит до того что глюк так легко воспроизводится, то может попробовать воспроизвести ошибку руками, посмотрев при этом кто когда редактировал табличку и какие сессии её на текущий момент держат ?

Судя по симптомам - у вас как-то перепутались соединения к БД. Ну то есть работало соединение к базе, в нем осталась незакрытая транзакция. Потом его хватает из пула соединений аоса другая сессия и пытается работать. А транзакция не закрыта, блокировки вешаются и вешаются, в том числе и на системные объекты и в итоге это все принимает совсем некрасивый вид. Но почему такое могло случиться - ума не приложу.
Вы не кастомизировали работу с номерными сериями или другие места, где явно из кода используется отдельное соединение к базе ?

[DSPIC]

Цитата:

Сообщение от Logger

Если в итоге все доходит до того что глюк так легко воспроизводится, то может попробовать воспроизвести ошибку руками, посмотрев при этом кто когда редактировал табличку и какие сессии её на текущий момент держат ?

Дык не держит никто, и не модифицирует никто кроме меня единственного. В период таких ахтунгов, я создаю новую таблицу Table1, вставляю в ней пару тройку записей и пишу цикл в джобе на 500 обновлений - и возникает конфликт обновления, мол другой пользователь её уже промодифицировал. Скадывается впечатление, что предыдущая транзакция цикла не упевает закончиться, как уже работает новая - и вот новая валится.

Цитата:

Сообщение от Logger

...Вы не кастомизировали работу с номерными сериями или другие места, где явно из кода используется отдельное соединение к базе ?

С номерными сериями - нет, а вот прямой вызов SQL используется часто, правда, натравлен на другие БД. Т.е. БД аксапты напрямую не используется. Но на самом деле - хз, я не могу это на 100% исключить, т.к. систему насиловали долго и упорно. Как проверить эту версию?

[Logger]

Цитата:

Сообщение от DSPIC

пишу цикл в джобе на 500 обновлений - и возникает конфликт обновления, мол другой пользователь её уже промодифицировал

Очень странно.
Прямо барабашка.
А не может быть так что эта табличка уже открыта в обозревателе таблиц или в формочке из под вас же и в силу каких-то причин запись на форме сохраняется (бред конечно, но все же)

Еще вариант - попробовать на этой табличке отключить оптимистическую конкуренцию. Если реально идет обновление кем-то, то скорее всего ваш джоб зависнет. Можно тогда посмотреть на ком и кто его держит.

Еще вариант - может сиквел глючит в режиме Snapshot isolation - вы посмотрите там все порядке - места в темпах достаточно ? Не переполнились ?

[Logger]

Кстати, недавно ковырялся по системным табличкам Аксапты и где-то попадался параметр, судя по названию, отвечающий за значение параметра OCC enabled по умолчанию. Может попробовать выключить. По крайней мере если заблокируется система, то увидите кто кого и когда и почему.

[DSPIC]

Цитата:

Сообщение от Logger

Очень странно.
Прямо барабашка.
А не может быть так что эта табличка уже открыта в обозревателе таблиц или в формочке из под вас же и в силу каких-то причин запись на форме сохраняется (бред конечно, но все же)...

Неее, никто таблицу не юзает, никто

Цитата:

Сообщение от Logger

Кстати, недавно ковырялся по системным табличкам Аксапты и где-то попадался параметр, судя по названию, отвечающий за значение параметра OCC enabled по умолчанию. Может попробовать выключить. По крайней мере если заблокируется система, то увидите кто кого и когда и почему.

Да, если отключить OCC для этой таблички, то конфликтов не возникает. Можно, конечно, отключить и глобально, но это это не наш метод.
В общем глючит именно OCC, а вот почему - предстоит разобраться, что-то ей мешает. Места достаточно на всех дисках.

Цитата:

Еще вариант - может сиквел глючит в режиме Snapshot isolation - вы посмотрите там все порядке - места в темпах достаточно ? Не переполнились ?

Может, а как проверить?

[fed]

Насколько я понимаю, оптимистическое обновление не имеет отношения к snapshot isolation. RCSI просто позволяет читать обновленные кем-то в незавершенных транзакциях записи. А оптимистическое обновление работает так: В оператор update/delete подставляется дополнительное условие RecVersion=429295 (в общем - с тем recversion, который был прочитан во время последнего чтения записи). Если после выполнения запроса из SQL Native Client приходит число обновленных записей, не равное единице, AOS понимает что запись вытащили из под носа и ругается.

Так что я бы в такой ситуации начал бы борьбу с обновления SQL Native Client на всех AOS-серверах. Для этого надо скачать последний Service Pack для SQL Server 2005, )(sp4) потом скачать последний cummulative update (cu3 на данный момент), а потом запустить установку всего этого хозяйства на ваших AOSах.
Хочу специально заметить, что даже если вы везде используете только SQL 2008, то аксапта все равно работает со старым Native Client (2005), так что пытаться поставить native client от SQL 2008 на серверы с AOS - бесполезно.

[Mykola Galak]

Цитата:

Сообщение от DSPIC

Но перезагрузка АОСа помогает ненадолго, на пару часов. А вот если рестартануть весь сервак, то чуть по-дольше - день, два.

Перезагрузка только сервиса SQL сервера помогает полечить на день-два?

[Artoodeetoo]

В микрософт запрос не отправляли?

[DSPIC]

Цитата:

Сообщение от fed

...Так что я бы в такой ситуации начал бы борьбу с обновления SQL Native Client на всех AOS-серверах...

Ок, попробуем.

Цитата:

Сообщение от Mykola Galak

Перезагрузка только сервиса SQL сервера помогает полечить на день-два?

Блыло уже столько эксперементов, что уже не помню. Проверю.

Цитата:

Сообщение от Artoodeetoo

В микрософт запрос не отправляли?

Ещё нет.

[jkspb]

А у вас случаем не sql 2005?.. может ОСС на уровне бд поможет...

[zelibobis]

Хотелось бы узнать - как решили проблему? У меня пока вылазит такое сообщение в логах АОС и иногда при пересчете склада на стороне клиента.

[Romb]

Включенный RCSI на БД должен помочь.

[Vadik]

Цитата:

Сообщение от Romb

Включенный RCSI на БД должен помочь.

Ну, колеги, это уже шаманство какое-то.. Мы считали запись в буфер, держим ее там какое-то время, пытаемся ее обновить и выясняем в процессе что кто-то ее уже обновил до нас (значение RecVersion поменялось). Это чистой воды конфликт, вариантов его разрешения два, оба - на уровне приложения, а не БД:
- честно сказать "не могу" и сразу откатить транзакцию
- откатить транзакцию, и попытаться перезапустить обработку в фоне (незаметно для пользователя), при повторных ошибках - см. п.1
RCSI здесь абсолютно не при чем

[Vadik]

Цитата:

Сообщение от DSPIC

В общем глючит именно OCC, а вот почему - предстоит разобраться, что-то ей мешает

С триггерами \ хранимыми процедурами с SET NOCOUNT ON баловались ? Если забыли где-то его вернуть в нормальное (для AX - OFF) состояние, в этой сессии при попытке UPDATE .. WHERE RECID = %X and RECVERSION = %Y ядро не увидит искомого '1 record affected' и решит что это конфликт OCC

[DSPIC]

1. Это было 2 года тому
2. Не помню точно чем это закончилось, но проблема как-то ушла сама, возможно, после профилактики работ с дисками или чем-то в этой области. Проблема была не в том что изменялся RecVersion. Я помню, что мы экспериментировали, создавая новую таблицу и запускали в цикле update. 2 из 50 проваливались. У меня было ощущение, что АОС "не успевал" следить за изменением RecVersion:
1) RecVersion1 -> Update1 -> RecVersion2
2) RecVersion1 -> Update2 -> RecVersion3
Т.е. перед 2-ым update АОС брал RecVersion1, который был ещё ДО 1-го апдейта.
Это догадки, проверить это не удалось.

[Just_smile]

Всем, привет!
Подскажите есть ли у кого-нибудь решение этой проблемы.
Постоянно у всех пользователей сыпятся ошибки (см. вложение).
Ругается на разные таблицы, в зависимости от того какой функционал зайдествован.
Перезапуск АОС на какое-то время помогает.
MDAX 2009 (RU7), SQL Server 2008 EE (Build 10.0.5835)

[DSPIC]

В итоге мы отключили оптимистичечкую модель обновления, после чего все беды ушли. Разницы между оптимистической и пессимистической моделями на практике замечено не было, если не считать описанной выше проблемы.
Если в RU8 проблему не исправили, то рекомендую поступить так же.

[Just_smile]

А где бы посмотреть список багов, которые исправили в RU8?

[gl00mie]

В соответствующей статье базы знаний.