www.InTouch.su

Исторический сервер буквально заваливается одним и тем же сообщением по 8 раз в секунду:
Metadata Server failed to create tag 'CM_EVENT' (The INSERT statement conflicted with the FOREIGN KEY constraint "FK_StructureTag_StructureType". The conflict occurred in database "Runtime", table "dbo.StructureType", column 'StructureId'.). Operation will be retried later [SQL; TagMetadataServer.cpp; 1489]

Думал, что дело в неисправноcти одного из engine, но после перевода всех движков в offscan сообщения не прекратились. В чём может быть дело?

версия какая ?

Совсем из головы вылетело. Версия 2012R2. Полная переустановка хисториана с удалением всех баз не помогла.

все патчи установлены? помоему p03 последний

а может быть так, что версия аппсервера выше, чем хисториана, которую вы используете (2012R2 aka 11.0)?
и этот самый аппсервер пытается пропихнуть свои алармы и евенты на хисториан, который их не поддерживает в этой версии? вместо аппсервера могут быть другие генераторы алармов которым нужна соответсвующая версия хисториана. если мне мой склероз не изменяет, то поддержка алармов и евентов в хисториане началась с 11.5.

Сервиспаков никаких установленно не было, просто голая 2012R2, но на других объектах с такой же системой проблемы данной не было. Но всё равно постараюсь сегодня накатить сервиспаки. А касательно разницы версий - исключено, так как всё с одного дистрибутива устанавливалось.

с одного дистрибутива системной платформы 2012R2 на все компьютеры сети?
судя по всему где-то затесался компонент из системной платформы 2014 или 2014R2, который пытается синхронизировать метаданные с более старым хисторианом. отсоедините компьютер хисториана от сети и посмотрите, продолжаются ли попытки синхронизации этого тэга.

beachbear писал(а):с одного дистрибутива системной платформы 2012R2 на все компьютеры сети?
судя по всему где-то затесался компонент из системной платформы 2014 или 2014R2, который пытается синхронизировать метаданные с более старым хисторианом. отсоедините компьютер хисториана от сети и посмотрите, продолжаются ли попытки синхронизации этого тэга.

Да, все компьютеры с одного дистрибутива: основной и резервный AppServers, Historian и 5 интачей. К сожалению отключить от сети невозможно, ввиду того, что я к нему подключаюсь удалённо, но я пробовал переводить все движки в offScan, а событие продолжало писаться. Причём пишется оно исключительно в лог хисториана, логи серверов пусты, но тем не менее папка StoreForward продолжает методично разрастаться, причём по всем движкам.
А по поводу старого компонента. Какой компонент ещё может писать данные в хистори, кроме сервера приложений? InTouch точно не пишет, IO сервер тоже.

вместо отключения компьютера хисториана от сети можно временно полностью закрыть на нём TCP порт 32568 во встроенном файерволле или остановить сервис Historian Access Point через панель управления хисториана. это должно заблокировать посылку данных чеpез HCAL c удалённых машин. алармы и евенты можно посылать из приложений, написанных с использованием Historian SDK или даже из скриптов аппсервера. разумеется для этого надо иметь установленные компоненты HCAL от 2014 или 2014 R2.

Завтра будет очередной сеанс связи, попробую установить сервиспаки и стопнуть Historian Access Point.

Проблема так и не решилась. Как оказалось, версия аппсервера там 2014. После установки сервиспака событие "Metadata Server failed to create tag 'CM_EVENT'..." больше не появлялось. Но папки S&F на основном и резервном сервере продолжают забиваться (уже по 15 Гб), плюс к этому забивается папка на сервере истории: в папках типа "C:\ProgramData\ArchestrA\GPA1Engine\SQL\Event\A000000_001" файлы original.dat разъелись до 8 Гб, в общей сумме на 40 Гб. При этом тренды исправно пишутся.

Что касается логов:
На основном сервере каждую минуту валятся нижеприведённые сообщения:
CEXEngine.SQL: Tag STU_DI1_20.PV failed to add to Historian after 3 attempts [HistTag.cpp, 2497]
CEXEngine.SQL: Tag STU_DI1_20.PV failed to add to Historian after 3 attempts [HistTag.cpp, 2497]

На резервном:
GPA3Engine.SQL: Tag GPA3AI063_dP_F203204.Val failed to add to Historian after 3 attempts [HistTag.cpp, 2497]
CHistStorage::GetSnapshots failed: error = 1 (Failure) [HistStorage.cpp, 2413]

В процессах висит масса процессов aahStorage.exe и просто беззастенчево жрут память, что в купе с раздутыми SF приводит к лютым тормозам всей системы.

Я могу лишь ещё раз повторить другими словами ту-же мысль (в последний раз).
Нельзя использовать аппсервер более высокой версии, чем хисториан!
Если аппсервер 2014, то и хисториан должен быть либо 2014, либо 2014R2.
Ваша конфигурация не поддерживается и всё закончится переполнением локального диска store/forward алармами и евентами. После этого начнётся потеря уже обыкновенных данных если вдруг временно потеряется связь аппсервера с хисторианом из-за отсутствия места на диске на удалённых машинах.

из readme:
IMPORTANT! If the Wonderware Historian will be used to collect data from Application Server, upgrade the Historian to 2014 before upgrading any Application Server Platforms to 2014.

"вас же предупреждали" (с)

beachbear писал(а):Я могу лишь ещё раз повторить другими словами ту-же мысль (в последний раз).
Нельзя использовать аппсервер более высокой версии, чем хисториан!
Если аппсервер 2014, то и хисториан должен быть либо 2014, либо 2014R2.

Я наверное как-то не совсем понятно выразился: аппсервер, хисториан, интачи - всё одной версии - 2014sp1. Так что несовместимость версий тут исключается

Не существует версии хисториана 2014sp1. Ecть 2014 P01, то есть патч 1, а не сервис пак.
В этом случае у вас по какой-то причине не прокачиваются алармы в хисториан и накапливаются на стороне аппсервера. Проверьте всё ли нормально с вашей базой данных алармов A2ALMDB в SQL сервере на машине хисториана. Пишутся ли новые алармы, нет ли каких нибудь подозрительных сообщений в логгере хисториана про обработку алармов. У тех тэгов, которые не могут синхронизовать метаданные, проверьте, что их единицы измерения не содержат нестандартные символы типа кубов или квадратов.

beachbear писал(а): Проверьте всё ли нормально с вашей базой данных алармов A2ALMDB в SQL сервере на машине хисториана

Каких либо ошибок нет, события приходят исправно. Но заметил один момент: ряд дискретных сигналов дребезжат и из за этого с начала месяца в базе накопилось уже 700 тысяч событий. Может ли проблема быть связана с чрезмерным объёмом событий?

Базу данных A2ALMDB надо периодически чистить специальной утилитой Purge & Archive, желательно до того, как она начнёт сильно тормозить от переполнения. Начало торможения зависит от производительности компьютера и особенно диска. Если видно, что SQL Server постоянно занят и store/forward с алармами и евентами не успевает прокачиваться, то, наверное, уже пора чистить. Может помочь наблюдение за следующими системными тэгами, мониторящими производительность базы событий:

SysStatusAverageEventCommitSize = Number of events written to the A2ALMDB database per minute.
SysStatusAverageEventCommitTime = Average time, in seconds, it takes to write events to the A2ALMDB database.
SysStatusEventCommitPending = Number of events that have not yet been written to the A2ALMDB database.
SysStatusRxEventsPerSec = Number of events received per second, calculated every 10 seconds.
SysStatusRxTotalDuplicateEvents = Total number of duplicate events received through different channels since startup (and discarded as duplicates).
SysStatusRxTotalEvents = Total number of events received since startup.