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

[snirk]

Доброго времени суток!

AX3.0 SP2 без Kernel Rollup
СУБД - MS SQL Server2000 SP4
2 AOS в кластере, один из них крутится на той же машине, где лежит приложение, другой - на отдельном сервере.
Везде MS Windows Server 2003

Суть проблемы:
Достаточно давно (несколько лет) такая конфигурация нормально, стабильно работала, но вот вот пару месяцев назад начались регулярные, практически ежедневные падания AOS-ов.

Внешние проявления: сначала отваливается один AOS (в разном порядке), затем другой. Отваливается, значит не дает пользователям входить в Axapta пишет что-то вроде "...Kernel mismatch...". Это происходит практически ежедневно в районе 7:30 - 9:00 утра. По выходным бывает и не отваливается.

Прочая информация:
На том же приложении крутятся AOS-ы для других баз данных - они не падают.
Полностью аналогичное приложение + другая БД + другие АОСЫ - не падало вообще ни разу.

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

Event Type: Error
Event Source: Axapta Object Server
Event Category: None
Event ID: 117
Date: 11.05.2011
Time: 8:21:13
User: N/A
Computer: -----
Description:
Object Server -------: The database reported (session 131 (------)): [Navision Axapta] Unable to retrieve message for retval -1, ODBC call reason code 100,
SQLSTATE =
[њ';%WЊH]
Error message []. The SQL statement was: "SELECT A.ID,A.NAME, __тут список всех полей таблицы USERINFO____,A.COMPILERWARNINGLEVEL,A.RECID FROM USERINFO A(INDEX(I_65531ID) NOLOCK) WHERE ((ID IN (?,?,?,?,?, ___тут ну очень много вопросиков___,?,?,?,?,?) ) AND (ID=?)) OPTION(FAST 2)"

Совершенно не понятно, является ли это причиной падения AOS или следствием. Что это за ошибка, можно почитать тут Проблема с ODBC?, но почему она возникает? Если посмотреть профайл, то при нормальном входе в систему запрос выглядит так:
SELECT A.ID,A.NAME,………..A.COMPILERWARNINGLEVEL,A.RECID FROM USERINFO A(INDEX(I_65531ID) NOLOCK) WHERE (ID=?) OPTION(FAST 2)
ни о каком (ID IN (?,?,?,?,?, ___тут ну очень много вопросиков___,?,?,?,?,?) нету и речи.

Также для некоторых процессов SQL в момент (или до, или после) падения выделяются SPID с номером 65535, причем это не один и тот же процесс или пользователь, да и видно их не всегда (но может успевают завершиться).

пинговали сервер БД с сервера АОСа (который вместе с приложением) - обрыва связи в мамент падения не было.

Пробовали:
- Утреннее время, а также (иногда) отсутствие проблемы по выходным навело на мысль, что это дело рук пользователей (явно неумышленное) - внесли ip-шники всех серверов имеющих отношение к Axapta или БД в список исключений (хотя сисадмины ручались, что и так никто их не перехватывал) - помогло(!) но на пару дней (может просто выходные), потом ситуация повторилась.
- Полная перекомпиляция приложения
- Рестарт всех серверов
Не помогло. Сегодня АОСЫ упали опять.

Собственно вопрос, основной:
1. Почему падают АОСы и как сделать так, чтобы они не падали?

Дополнительный:
2. Почему при входе в систему генерируется такой запрос (с IN и много параметров)? В этом месте явно никто ничего руками не ковырял.

Почему падают АОСы и как сделать так, чтобы они не падали? Это даже не вопрос, а просто крик о помощи!!! Еще немного, и в обязанности программистов внесут ежедневный рестарт АОСов и это войдет в нормальную практику. А очень не хочется.

Заранее спасибо всем, кто откликнется.

[EfimV]

2 АОСа. А папка приложения у них общая?
Если папки разные возможно приложения стали отличатся.
И нужно одно из них скопировать вместо другого.

[snirk]

Приложение у них одно. АОСы работают в кластере.

[lev]

на серверах где крутятся АОСы стоят антивирусы?
У нас была похожая ситуация, каждый день в одно и тоже время падал АОС. после штудирования логов выявил, что за секунду до падения АОСа запускался сканер антивируса, который отрубал сеть, в итоге аос падал.
отключили сканирование антивирусом по расписанию, все нормально работает

[Wamr]

Какой режим работы в системе (5х8 или 7х24)?
Используется ли COM коннектор?
Сколько пользователей по лицензии и сколько обычно работают?
Сеансы пользователей закрываются корректно или болтаются зависшие сессии?

[snirk]

Работа в режиме 7х24. COM коннектор не используется.

Пользователей по лицензии больше 100, в рабочую нагрузку сидит около сотни (лицензий хватает).
В момент падения было порядка 30 пользователей.

У большинства пользователей установлен автовыход через 2 часа неактивности. Проблем с большим количеством зависших сессий нет - пользователям позволено по 2 максимум и никто не обращается, что не может войти в систему.


Насчет антивируса - есть зараза, но вероятность мала - падают АОСЫ не точно в одно время, а по выходным - так и вообще не падают.
*Но уже выключили нафиг - завтра проверим.

[EfimV]

На DAX2009 подобная ситуация (падение АОСа) наблюдалась, если вдруг находится пользователь, у которого версия клиента отличается от "актуальной".

[snirk]

Явно не наш случай. Уже много лет все инсталляции клиентов происходят ровно из одной и той же папочки на сетевом диске, абсолютно одинаково (ибо по инструкции) для всех пользователей.
*. на всякий случай напрягу сисадминов, чтобы это проверили. Может есть идея как это сделать по-быстрому?

[EfimV]

Попробуйте посмотреть по таблице SysUserLog. Поле BuildNum.

[snirk]

Полностью идентичные данные от начала времен...

[gl00mie]

Цитата:

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

Цитата:

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

Попробуйте посмотреть по таблице SysUserLog. Поле BuildNum.

Полностью идентичные данные от начала времен...

Если вы специально не модифицировали SysUserLog, то от начала времен видите там номера сборки АОСов, а не клиентов. Более подробно это описано вот тут; вкратце метод SysUserLog.insert() выполняется на сервере, поэтому и xInfo::buildNo(), который дергается для заполнения поля BuildNum, выполняется на сервере. Как это исправить, описано, к примеру, вот тут.

[fed]

Мне в симптоматике кажутся странным две вещи:
1. Очень странный запрос по UserInfo с большим количеством userId. Никогда не приходилось видеть подобных запросов ни на одной версии Аксапты. Посмотрите - нету ли у вас запросов по UserInfo,написанных местными программистами ? Просто тупо пробегитесь по всему AOD и поищите tablenum(userInfo).
2. Приходилось видеть странности в исполнении запросов в определенное время, потому что админы поставили на утро автоматический шринк базы данных Возможно у вас там сисадмины нечаянно вместо шринк datafile поставили шринк всей базы данных и userInfo блокируется на какое-то время от всех операций, потому что у нее странички в конце файла и ее система пытается переместить в начало tablespace...

[Pustik]

Цитата:

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

Возможно у вас там сисадмины нечаянно вместо шринк datafile поставили шринк всей базы данных и userInfo блокируется на какое-то время от всех операций, потому что у нее странички в конце файла и ее система пытается переместить в начало tablespace...

И не только шринк, а вообще проверить все задачи, поставленные администраторами на шедулер. У нас была примерно, такая же хрень, когда бэкап админы в шедулере ставили в самый разгар рабочего дня(мы хотели иметь и ночной и дневной ), аос не падал но тормозило жутко.В общем надо откровенно поговорить с админом, мне так кажется.

[snirk]

fed, pustik

все это давно проделано:
1. Есть ряд заданий, которые выполняются примерно в это время, НО(!) они всегда выполняются в одно и то же время и на выходных (а падение АОСов в разное, но в интервале 7:30-9:00 утра). Кроме того, за последние месяцы - ни одного нового задания или модификации ранее запущенных.
Никаких backup или shrink в это время гарантировано не выполняется. Ни БД, ни приложения. (Кстати, shrink не используется вообще, мы жертвуем местом в пользу производительности)

2.Запрос странен не только количеством, но и формой. Включал трассировку всех запросов в момент запуска приложения - от момента запуска, до открытия одной из форм... Обращения к UserInfo есть, но ни в одном из них нет оператора IN с перечислением констант, только WHERE (ID=?).
Программист я, последние пару лет ничего связанного с UserInfo не писалось. StartupPost чист в этом отношении. По всему коду конечно поищу, но если что и писалось, то в формулировке WHERE id=id, а это так и передается в SQL, а не IN.

P.S. Есть подозрение, что такой запрос не причина падения, а его следствие

P.P.S. Более откровенно говорить с админом смысла нет - он (админ БД и Axapta) самая пострадавшая сторона - именно ему приходится постояноо перезапускать АОСы, пакетники и прочее, а также выслушивать недовольство пользователей.

[S.Kuskov]

Цитата:

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

Запрос странен не только количеством, но и формой. Включал трассировку всех запросов в момент запуска приложения - от момента запуска, до открытия одной из форм... Обращения к UserInfo есть, но ни в одном из них нет оператора IN с перечислением констант, только WHERE (ID=?).
Программист я, последние пару лет ничего связанного с UserInfo не писалось. StartupPost чист в этом отношении. По всему коду конечно поищу, но если что и писалось, то в формулировке WHERE id=id, а это так и передается в SQL, а не IN.

Извините если не в тему, тут просто в соседней ветке как раз запостили пример такого запроса к UserInfo Настройка прав доступа на просмотр всех Пользователей. Ax 2009 может это никак и не поможет, но всё же

[Vadik]

Цитата:

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

Мне в симптоматике кажутся странным две вещи:
1. Очень странный запрос по UserInfo с большим количеством userId. Никогда не приходилось видеть подобных запросов ни на одной версии Аксапты

Ровно то же самое наблюдал в 4.0. Даже не поленился переправить запрос kashperuk

[fed]

Цитата:

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

Ровно то же самое наблюдал в 4.0. Даже не поленился переправить запрос kashperuk

Кстати, для 4ки выложили на Microsoft Symbol Server отладочные символы. Так что теперь можно самому крашдамп в WinDbg засунуть и посмотреть где оно там поломалось
Может и для трешки выложили ?

[db]

сессии с номерами подобными 65535 это рабочие потоки (WorkerThread). В стандартной 3.0. есть вроде только одно место где они используются - класс SysEventHandler. Главная задача этого класса - сбрасывать различные кеши если используется несколько аосов. Возможно в вашем случае это при большом количестве активных юзеров приводит к завалу аоса, а в выходные когда юзеров мало, то не приводит. Можно попробовать на пару дней отключить этот фунционал, подправив метод shouldRun и посмотреть что будет. Заливать модификации на ходу и править данные в сильно кешированных таблицах в это время не стоит

все вышесказанное на правах пространных размышлений

[snirk]

АОСы упали опять, на этот раз примерно в 8:20, оба...

Что делалось (соответственно не помогло):
Синхронизация DataDictionary по совету Poleax. Ошибку нашли, исправили, добились синхронизации без ошибок.
Повторная глобальная перекомпиляция

Исследования:
Был изменен SysUserLog по совету gl00mie, версия клиентов все равно одна и та же у всех.
Мониторинг пользователей (последние которые подключались до падения, первые которые подключались после падения) - отследить их можно в EventLog-ах на АОСах. Проверили каждый комп - в логах есть только пару warnings связанных с политиками безопасности.

Замечено:
Создали 3-й АОС, подключили его в кластер, но не пускали на него пользователей (только пакетные задания). Так вот, он не упал.

Догадки заканчиваются. Сегодня начисто пересоздадим первые 2 АОСа.

[titov]

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