Регулярное падение AOS-в в AX3.0

[snirk]

Толстых клиентов нет в принципе.
Локальные кэши чистятся при каждой перезагрузке компьютеров, или для тех кто работает через терминальный сервер - ежедневно.

Цитата:

"Хорошо бы "поймать" последнего пользователя"

Еще бы! Сейчас думаем, как это сделать...

[Poleax]

Цитата:

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

В системных логах после падения постоянно висят записи типа:

Event Type: Error
Event Source: Axapta Object Server
Event Category: None
Event ID: 117

Есть предложение открыть АОТ --> Data Dictionary --> правой кнопкой мыши "Синхронизация".
Результат сообщите.

http://www.eggheadcafe.com/software/...arameters.aspx

P.S. Типа надо Администрирование --> Периодические операции --> Администрирование SQL --> Все таблицы --> Проверка/Синхронизация.
Ax 3.0 нет под рукой, это путь из Ax 2009

[lev]

Цитата:

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

...

P.S. Типа надо Администрирование --> Периодические операции --> Администрирование SQL --> Все таблицы --> Проверка/Синхронизация.
Ax 3.0 нет под рукой, это путь из Ax 2009

в трешке путь почти такой же
Администрирование \ Периодические операции \ SQL Администрирование --> встаем на "Все таблицы" --> кнопка "Таблицы" --> из списка выбираем "Проверка/Синхронизация"

[snirk]

Снос всех антивирусов + разделение одного из АОСов и приложения на разные сервера не помогло. Сегодня АОСы легли опять...

gl00mie, лог доработал согласно совету, но это надо денек помониторить (до завтра). Посмотрим.

Poleax, синхронизацию провел. Действительно была одна ошибка, предлагало удалить одну из таблиц. Все сделал, теперь синхронизация проходит нормально. И хотя данная таблица ни разу в логах не присутствовала, возможно поможет - на других копиях приложения с этой же таблицей ошибок не было. Ждем завтра.

[gl00mie]

А в настройках соединения с БД (вкладка Database, группа Connection) что у вас прописано касаемо неактивных соединений? Они закрываются по таймауту или продолжают висеть? Был как-то косяк с АОСами 3.0, правда, на Оракле: в настройках был выставлен определенный таймаут, по истечении которого АОС пытался закрывать неактивные соединения с СУБД, правда, делал это как-то криво, и на СУБД сессии в результате оставались висеть. Это приводило к тому, что, во-первых, отжиралась лишняя память на СУБД, а во-вторых, в определенный момент при создании новых соединений тупо заканчивались TCP-порты, и АОС падал. Если у вас настроено завершение неактивных соединений с СУБД по таймауту, попробуйте перенастроить АОСы так, чтобы они их не завершали, а оставляли висеть.

[Perc]

"internal revision mismatch.." если вы про эту ошибку. В какой то момент новых пользователй не пускает.
Проблема эта у нас уже много лет.
AX3.0 SP4. СУБД - было и MS SQL Server2000 и сейчас 2005
версии приложений и клиентов у нас не меняются с 2006г.
На одну базу и приложение 1 аос. Пользователей активных редко бывает больше 80. Все работают через 1 аос.
Когда то админ наш давно пытался искать, спрашивать. Темы на этом форме были уже. Но успехом не увенчалось, смены параметров, серверов, АОСа.
В общем смиренно мучаемся.
В период особой активности пользователей (конец,начало месяца) перезапускаем по несколько раз на дню АОС. В другие периоды может неделю стоять АОС без перезапуска.
В последнее время стало особо досаждать тем что появилась необходимость к томуже перестартовать пакетный сервер.
В общем я решил для себя что это проблема АОСа по работе с памятью. Причем если АОС не перестартовать, забить на новых пользователей, мол пускай существующие работают, то всеравно очень скоро проявляется неадекватная работа, зависания.. ну и итог рестарт.

Было б очень клево если б вы нашли корень зла)

[gl00mie]

Не знаю, как AOS, а клиент AX 3.0 SP4 славился просто дикими утечками памяти. По-моему, если уж и работать на трешке, то лучше взять последнее официально выпущенное ядро - KR3.