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

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 02.04.2011, 23:45   #1  
DSPIC is offline
DSPIC
Боец
 
1,077 / 1234 (44) ++++++++
Регистрация: 11.04.2008
AX2009: Ошибка оптимистической модели обновления
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, либо ещё как-то...
Старый 03.04.2011, 11:10   #2  
online
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,867 / 3123 (112) ++++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
Если в итоге все доходит до того что глюк так легко воспроизводится, то может попробовать воспроизвести ошибку руками, посмотрев при этом кто когда редактировал табличку и какие сессии её на текущий момент держат ?

Судя по симптомам - у вас как-то перепутались соединения к БД. Ну то есть работало соединение к базе, в нем осталась незакрытая транзакция. Потом его хватает из пула соединений аоса другая сессия и пытается работать. А транзакция не закрыта, блокировки вешаются и вешаются, в том числе и на системные объекты и в итоге это все принимает совсем некрасивый вид. Но почему такое могло случиться - ума не приложу.
Вы не кастомизировали работу с номерными сериями или другие места, где явно из кода используется отдельное соединение к базе ?
Старый 03.04.2011, 12:53   #3  
DSPIC is offline
DSPIC
Боец
 
1,077 / 1234 (44) ++++++++
Регистрация: 11.04.2008
Цитата:
Сообщение от Logger Посмотреть сообщение
Если в итоге все доходит до того что глюк так легко воспроизводится, то может попробовать воспроизвести ошибку руками, посмотрев при этом кто когда редактировал табличку и какие сессии её на текущий момент держат ?
Дык не держит никто, и не модифицирует никто кроме меня единственного. В период таких ахтунгов, я создаю новую таблицу Table1, вставляю в ней пару тройку записей и пишу цикл в джобе на 500 обновлений - и возникает конфликт обновления, мол другой пользователь её уже промодифицировал. Скадывается впечатление, что предыдущая транзакция цикла не упевает закончиться, как уже работает новая - и вот новая валится.
Цитата:
Сообщение от Logger Посмотреть сообщение
...Вы не кастомизировали работу с номерными сериями или другие места, где явно из кода используется отдельное соединение к базе ?
С номерными сериями - нет, а вот прямой вызов SQL используется часто, правда, натравлен на другие БД. Т.е. БД аксапты напрямую не используется. Но на самом деле - хз, я не могу это на 100% исключить, т.к. систему насиловали долго и упорно. Как проверить эту версию?
Старый 03.04.2011, 13:23   #4  
online
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,867 / 3123 (112) ++++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
Цитата:
Сообщение от DSPIC Посмотреть сообщение
пишу цикл в джобе на 500 обновлений - и возникает конфликт обновления, мол другой пользователь её уже промодифицировал
Очень странно.
Прямо барабашка.
А не может быть так что эта табличка уже открыта в обозревателе таблиц или в формочке из под вас же и в силу каких-то причин запись на форме сохраняется (бред конечно, но все же)

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

Еще вариант - может сиквел глючит в режиме Snapshot isolation - вы посмотрите там все порядке - места в темпах достаточно ? Не переполнились ?
Старый 03.04.2011, 13:25   #5  
online
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,867 / 3123 (112) ++++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
Кстати, недавно ковырялся по системным табличкам Аксапты и где-то попадался параметр, судя по названию, отвечающий за значение параметра OCC enabled по умолчанию. Может попробовать выключить. По крайней мере если заблокируется система, то увидите кто кого и когда и почему.
Старый 03.04.2011, 13:38   #6  
DSPIC is offline
DSPIC
Боец
 
1,077 / 1234 (44) ++++++++
Регистрация: 11.04.2008
Цитата:
Сообщение от Logger Посмотреть сообщение
Очень странно.
Прямо барабашка.
А не может быть так что эта табличка уже открыта в обозревателе таблиц или в формочке из под вас же и в силу каких-то причин запись на форме сохраняется (бред конечно, но все же)...
Неее, никто таблицу не юзает, никто

Цитата:
Сообщение от Logger Посмотреть сообщение
Кстати, недавно ковырялся по системным табличкам Аксапты и где-то попадался параметр, судя по названию, отвечающий за значение параметра OCC enabled по умолчанию. Может попробовать выключить. По крайней мере если заблокируется система, то увидите кто кого и когда и почему.
Да, если отключить OCC для этой таблички, то конфликтов не возникает. Можно, конечно, отключить и глобально, но это это не наш метод.
В общем глючит именно OCC, а вот почему - предстоит разобраться, что-то ей мешает. Места достаточно на всех дисках.
Цитата:
Еще вариант - может сиквел глючит в режиме Snapshot isolation - вы посмотрите там все порядке - места в темпах достаточно ? Не переполнились ?
Может, а как проверить?
Старый 03.04.2011, 15:06   #7  
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
Насколько я понимаю, оптимистическое обновление не имеет отношения к 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 - бесполезно.
Старый 03.04.2011, 19:00   #8  
Mykola Galak is offline
Mykola Galak
Участник
 
40 / 39 (2) +++
Регистрация: 24.01.2008
Адрес: Copenhagen
Цитата:
Сообщение от DSPIC Посмотреть сообщение
Но перезагрузка АОСа помогает ненадолго, на пару часов. А вот если рестартануть весь сервак, то чуть по-дольше - день, два.
Перезагрузка только сервиса SQL сервера помогает полечить на день-два?
Старый 03.04.2011, 20:00   #9  
Artoodeetoo is offline
Artoodeetoo
Участник
Аватар для Artoodeetoo
 
22 / 10 (1) +
Регистрация: 01.11.2010
В микрософт запрос не отправляли?
Старый 03.04.2011, 21:23   #10  
DSPIC is offline
DSPIC
Боец
 
1,077 / 1234 (44) ++++++++
Регистрация: 11.04.2008
Цитата:
Сообщение от fed Посмотреть сообщение
...Так что я бы в такой ситуации начал бы борьбу с обновления SQL Native Client на всех AOS-серверах...
Ок, попробуем.

Цитата:
Сообщение от Mykola Galak Посмотреть сообщение
Перезагрузка только сервиса SQL сервера помогает полечить на день-два?
Блыло уже столько эксперементов, что уже не помню. Проверю.

Цитата:
Сообщение от Artoodeetoo Посмотреть сообщение
В микрософт запрос не отправляли?
Ещё нет.
Старый 04.04.2011, 15:13   #11  
jkspb is offline
jkspb
Участник
 
18 / 20 (1) +++
Регистрация: 03.03.2009
А у вас случаем не sql 2005?.. может ОСС на уровне бд поможет...
За это сообщение автора поблагодарили: DSPIC (0).
Старый 17.09.2012, 10:30   #12  
zelibobis is offline
zelibobis
Участник
 
71 / 24 (1) +++
Регистрация: 15.10.2007
Адрес: Kiev
Хотелось бы узнать - как решили проблему? У меня пока вылазит такое сообщение в логах АОС и иногда при пересчете склада на стороне клиента.
Старый 17.04.2013, 03:54   #13  
Romb is offline
Romb
Участник
Аватар для Romb
 
79 / 22 (1) +++
Регистрация: 06.01.2004
Включенный RCSI на БД должен помочь.
За это сообщение автора поблагодарили: Logger (1).
Старый 17.04.2013, 11:29   #14  
Vadik is offline
Vadik
Модератор
Аватар для Vadik
Лучший по профессии 2017
Лучший по профессии 2015
 
3,631 / 1849 (69) ++++++++
Регистрация: 18.11.2002
Адрес: гражданин Москвы
Цитата:
Сообщение от Romb Посмотреть сообщение
Включенный RCSI на БД должен помочь.
Ну, колеги, это уже шаманство какое-то.. Мы считали запись в буфер, держим ее там какое-то время, пытаемся ее обновить и выясняем в процессе что кто-то ее уже обновил до нас (значение RecVersion поменялось). Это чистой воды конфликт, вариантов его разрешения два, оба - на уровне приложения, а не БД:
- честно сказать "не могу" и сразу откатить транзакцию
- откатить транзакцию, и попытаться перезапустить обработку в фоне (незаметно для пользователя), при повторных ошибках - см. п.1
RCSI здесь абсолютно не при чем
__________________
-ТСЯ или -ТЬСЯ ?
Старый 17.04.2013, 11:34   #15  
Vadik is offline
Vadik
Модератор
Аватар для Vadik
Лучший по профессии 2017
Лучший по профессии 2015
 
3,631 / 1849 (69) ++++++++
Регистрация: 18.11.2002
Адрес: гражданин Москвы
Цитата:
Сообщение от DSPIC Посмотреть сообщение
В общем глючит именно OCC, а вот почему - предстоит разобраться, что-то ей мешает
С триггерами \ хранимыми процедурами с SET NOCOUNT ON баловались ? Если забыли где-то его вернуть в нормальное (для AX - OFF) состояние, в этой сессии при попытке UPDATE .. WHERE RECID = %X and RECVERSION = %Y ядро не увидит искомого '1 record affected' и решит что это конфликт OCC
__________________
-ТСЯ или -ТЬСЯ ?
За это сообщение автора поблагодарили: Kabardian (5), dim-gin (1).
Старый 17.04.2013, 11:55   #16  
DSPIC is offline
DSPIC
Боец
 
1,077 / 1234 (44) ++++++++
Регистрация: 11.04.2008
1. Это было 2 года тому
2. Не помню точно чем это закончилось, но проблема как-то ушла сама, возможно, после профилактики работ с дисками или чем-то в этой области. Проблема была не в том что изменялся RecVersion. Я помню, что мы экспериментировали, создавая новую таблицу и запускали в цикле update. 2 из 50 проваливались. У меня было ощущение, что АОС "не успевал" следить за изменением RecVersion:
1) RecVersion1 -> Update1 -> RecVersion2
2) RecVersion1 -> Update2 -> RecVersion3
Т.е. перед 2-ым update АОС брал RecVersion1, который был ещё ДО 1-го апдейта.
Это догадки, проверить это не удалось.
Старый 29.11.2013, 15:19   #17  
Just_smile is offline
Just_smile
Участник
Axapta Retail User
 
41 / 29 (1) +++
Регистрация: 28.10.2008
Всем, привет!
Подскажите есть ли у кого-нибудь решение этой проблемы.
Постоянно у всех пользователей сыпятся ошибки (см. вложение).
Ругается на разные таблицы, в зависимости от того какой функционал зайдествован.
Перезапуск АОС на какое-то время помогает.
MDAX 2009 (RU7), SQL Server 2008 EE (Build 10.0.5835)
Миниатюры
Нажмите на изображение для увеличения
Название: 123.jpg
Просмотров: 560
Размер:	59.2 Кб
ID:	8631  

Последний раз редактировалось Just_smile; 29.11.2013 в 15:22.
Старый 30.11.2013, 08:57   #18  
DSPIC is offline
DSPIC
Боец
 
1,077 / 1234 (44) ++++++++
Регистрация: 11.04.2008
В итоге мы отключили оптимистичечкую модель обновления, после чего все беды ушли. Разницы между оптимистической и пессимистической моделями на практике замечено не было, если не считать описанной выше проблемы.
Если в RU8 проблему не исправили, то рекомендую поступить так же.

Последний раз редактировалось DSPIC; 30.11.2013 в 08:59.
За это сообщение автора поблагодарили: Just_smile (1).
Старый 03.12.2013, 21:19   #19  
Just_smile is offline
Just_smile
Участник
Axapta Retail User
 
41 / 29 (1) +++
Регистрация: 28.10.2008
А где бы посмотреть список багов, которые исправили в RU8?
Старый 04.12.2013, 00:42   #20  
gl00mie is offline
gl00mie
Участник
MCBMSS
Most Valuable Professional
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,684 / 5788 (200) ++++++++++
Регистрация: 28.11.2005
Адрес: Москва
Записей в блоге: 3
В соответствующей статье базы знаний.
Теги
ax2009, ax2012, ax2012r2, occ, sysclientsessions, ошибка, хранимые процедуры

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
Ошибка при работе с binary в Ax2009 someOne DAX: Программирование 2 08.11.2010 10:04
ax2009: кто юзал Startup command: CompileAll_+ для периодического обновления перекрестных ссылок? mazzy DAX: Администрирование 11 25.08.2010 08:50
Ошибка при установке корпоративного портала ax2009, ошибка доступа Antant DAX: Администрирование 0 11.09.2009 09:28
Ошибка при передаче курсора для обновления с клиента на сервер vallys DAX: Программирование 4 03.07.2007 13:32
Русская локализация Axapta 3 ? SlavaK DAX: Администрирование 59 01.07.2003 22:38
Опции темы Поиск в этой теме
Поиск в этой теме:

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

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

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

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