Странные ошибки в логах ArchestrA

[BorisS]

Многоуважаемый all!
С некоторого момента времени в логах стали появляться ошибки следующего содержания:
"SetAttribute for Attribute ID 279 failed" для компонента ScanGroupRuntime2 для процесса aaengine.exe.
Сталкивался кто-нибудь? Что это вообще может означать?
http://keep4u.ru/full/953403b6f634c642aa145c90f7dc6c05.html

[Klinkmann_Msk]

To BorisS:

Это не ошибка, а информационное сообщение. О том, что не может записать какой то аттрибут в каком то объекте.
Больше интересуют Warning-и жёлтого цвета. Можете привести их полностью?

[BorisS]

Спасибо за оперативный ответ.
Дело в том, что желтые сообщения на скриншоте к проблеме не относятся. Они связаны с тем, что был остановлен InTouch на одном из клиентов.

[Klinkmann_Msk]

To BorisS:

Тогда "отмотайте" логи к тому моменту когда эти сообщения появились ("SetAttribute for Attribute ID 279 failed") и проверьте, были ли какие-либо варнинги/ошибки перед этим. "Просто так" даже прыщ не вскочит Правда с WW я бы не был так уверен

[Klinkmann_Msk]

To BorisS:

Есть ещё такой вариант.
Откройте на GR-узле MSSQL, найдите в списке БД свою Галактику, в ней таблицу dbo.attribute_reference. Откройте её и найдите по номеру (279) что за аттрибут и какому объекту принадлежит. А там - по обстоятельствам.

[BorisS]

Пока вот момент появления сообщений об ошибках. Нас на объекте небыло. Но, возможно, эксплуатация что-то делала.
http://s11.radikal.ru/i183/1005/6c/f7d5a921a47c.png

[Klinkmann_Msk]

To BorisS:

Я не ошибаюсь, Вы используете GRAccess?
Или ф-ция SetAttribute вызывается через обычные IAS-скрипты?
В любом случае, Вам необходимо найти сбойные объекты. Либо копаясь в БД GR-а, либо андеплоя по очереди объекты с Engine-на. Найдёте объекты, убейте их и перевоссоздайте из шаблонов.
Иногда помогает Undeploy-Deploy всей платформы, но не думаю, что это поможет.

[BorisS]

Большое спасибо за Ваши советы. Я передал их нашему сотруднику на объекте, он разбирается.

[BorisS]

В таблице dbo.attribute_reference есть много столбцов, но ни одного с именем attribute_id. Нужно искать в столбце goobject_id, package_id или в каком-то другом? По окончании поиска значение из какого столбца представляет интерес? Это значение затем нужно искать в какой таблице: dbo.attribute_definition или какой-то другой?

[Klinkmann_Msk]

To BorisS:

К сожалению, WW не раскрывает структуру БД Галактики, поэтому остаётся только гадать. Я думаю, что Ваш ID=279 надо найти в столбце goobject_id и узнать что за ContextString относится к этому ID. А там - по обстоятельствам
Может проще найти сбойные объекты методом последовательного андеплоя?

[Klinkmann_Msk]

To BorisS:

Извините, совсем забыл
Существует набор утилит от WW, помогающий протестировать Runtime-объекты; GR-базу, ArchestrA-графику на предмет "закосов". Но нужно знать точные версии IAS+InTouch, включая патчи и сервиспаки. Увы, не всегда эти утилиты помогают.

[BorisS]

Спасибо за помощь!
Наш сотрудник, похоже, устранил появление сообщений (их небыло уже половину суток). Рассказал следующее:
Historian получает информацию с DAS-серверов через сконфигурированные на каждом контроллере топики. При конфигурации архивирования данных с каждого топика в свойствах на главной вкладке указывается параметр Timeout. Historian следит за изменениями Item-ов, которые считываются через этот топик. Если ни один из Item-ов за время, установленное в параметре Timeout не шевельнулся, то Historian считает, что произошел обрыв связи с контроллером, на который топик сконфигурирован. В логах появляется сообщение об обрыве связи с топиком, выделяемое желтым цветом. После этого Historian восстанавливает связь с топиком. Для борьбы с этим надо в конфигурации дэйта аквисижен на главной вкладке топика поставить галку о бесконечном времени Timeout-а.
Самое интересное, после простановки указанных галок сообщения про проблему с установкой аттрибута пропали (по крайней мере пока). Взаимосвязь нам неочевидна. Тем не менее, тему можно считать закрытой. Еще раз спасибо.

[Klinkmann_Msk]

To BorisS:

"поставить галку о бесконечном времени Timeout-а."
Теперь Вы потеряли (частично) диагностику канала подключения Но если это некритично...