Historian Client Trend и процесс ReImport'а на Historian'e

[Roman_Surkov]

Здравствуйте!

На АРМах имеются Historian Client Trend, стучащиеся на сервер Historian. В процессе ReImport'а тэгов на сервере (добавление/изменение) связь клиентов с сервером отваливается, Historian Client Trend зависает. После завершения импорта (процесс не быстрый, используется Full Re-Import) связь возобновляется, все изменения тегов, писавшихся в Historian в момент отсутствия связи, начинают отображаться на трендах.
В чём может быть проблема отвала связи между клиентами с сервером? Сервер все свои ресурсы бросает на обновление своих баз и перестаёт отвечать клиентам?

[beachbear]

Какая версия Хисториана?

[Roman_Surkov]

От версии не зависит.
На АРМах имеются клиенты и 10.5 (2014 R2), и 10.6 (2014 R2 SP1), и даже один старый ActiveFactory 9.1.
На сервере сейчас стоит Historian 2014 R2, ранее использовали сервер IndustrialSQL, то же самое поведение.

[beachbear]

Могу предложить следующее возможное объяснение
Тренд вытаскивает данные из хисториана, посылая SQL запрос на таблицу History, что перехватывается OLE DB провайдером хисториана.
Если одновременно хисториан производит массивные изменения в базе Runtime, то это приводит к долгому блокированию OLE DB провайдера и клиент отваливается по таймауту. При наличии более свежей версии, например 2017, это объяснение можно было бы проверить, строя тренд в браузере через OData интерфейс, который не задействует SQL Server. При имеющейся - попробуйте достать данные, написав SQL запрос в SSMS из таблицы History базы Runtime в момент отвала тренда.

[Roman_Surkov]

Попробовал через Historian Client Query и аналогичный запрос в SSMS. Данные идут, у тегов Quality 192 Но Trend Client всё равно зависает, пока ReImport не завершился
Причём, зависает Trend Client тогда, когда начинается обновление Runtime базы.

[beachbear]

Можно запустить в SSMS SQL Profiler и установить фильтр на запросы от Historian Client с конкретной машины.
Потом начать ReImport и посмотреть на каком запросе Historian Client затыкается.
Может и откроется тайна сия

[Roman_Surkov]

Только сейчас выдалась возможность проверить запросы
Ситуация выглядит следующим образом: при уже запущенном Historian Client Trend во время начала обновления базы Runtime данные продолжают поступать и отображаться на графиках.
Если же попытаться, например, изменить текущий временной диапазон, на сервер с клиента уходит запрос

Код: Выделить всё

SELECT UtcDate=Getutcdate()

после чего Historian Client Trend зависает. Аналогичный запрос отправляется при попытке вновь открыть Historian Client Trend во время обновления Runtime базы.
Куда копать-то дальше? Сервер не отдаёт своё UTC?

[Roman_Surkov]

В общем, запрос UTC здесь не причём - проверил через SSMS.

Попробовал просто открыть новый Trend Client. Тоже самое. Выполняется некоторое количество разных запросов, после чего виснет на этом, каждые 120 секунд повторяется (попытки подключения к серверу) с разным тегом:

Код: Выделить всё

Select Tag.TagName, HierarchicalName, Tag.TagType, Tag.DateCreated, ISNULL(Tag.Description, ' ') as Description, Tag.StorageType, EU=isnull(EngineeringUnit.Unit,CASE Tag.TagType WHEN 2 THEN isnull(Message0,'OFF') + '|' + isnull(Message1,'ON') WHEN 7 THEN isnull(Message0,'0') + '|' + isnull(Message1,'1')ELSE '' END), _=isnull(_.MinRaw,0), _=isnull(_.MaxRaw,0), _=isnull(_.MinEU,CASE Tag.TagType WHEN 7 THEN isnull(_.MinEU,0) ELSE 0 END),_=isnull(_.MaxEU,CASE Tag.TagType WHEN 7 THEN isnull(_.MaxEU,0) ELSE 0 END),Address, Msg0=isnull(Message0,'OFF'), Msg1=isnull(Message1,'ON'), _=isnull(_.RawType,3), SourceTag, SourceServer FROM ( select  Tag.TagName,Tag.Description,Tag.TagType,Tag.DateCreated,Tag.StorageType,Tag.ItemName,Tag.IOServerKey,Tag.StorageNodeKey, Tag.TopicKey, Address = isnull(rtrim('\\' + IOServer.ComputerName + '\' + IOServer.ApplicationName + '|' + Topic.Name + '!' + Tag.ItemName),''),  ISNULL(dbo.aaAttributeData.HierarchicalAttributeName,Tag.TagName ) as HierarchicalName , ISNULL(SourceTag, '') AS SourceTag, ISNULL(SourceServer, '') AS SourceServer FROM Tag LEFT JOIN IOServer ON Tag.IOServerKey=IOServer.IOServerKey AND Tag.StorageNodeKey=IOServer.StorageNodeKey LEFT JOIN Topic ON Tag.TopicKey=Topic.TopicKey AND Tag.IOServerKey=Topic.IOServerKey AND Tag.StorageNodeKey=Topic.StorageNodeKey LEFT JOIN dbo.aaAttributeData on Tag.TagName = dbo.aaAttributeData.AttributeName  LEFT JOIN ReplicationTag ON Tag.TagName=ReplicationTag.TagName   WHERE Tag.TagName = 'LT_3050_A'  ) Tag  LEFT JOIN _ ON Tag.TagName=_.TagName LEFT JOIN _ ON Tag.TagName=_.TagName LEFT JOIN EngineeringUnit ON _.EUKey=EngineeringUnit.EUKey or _.EUKey=EngineeringUnit.EUKey LEFT JOIN DiscreteTag ON Tag.TagName=DiscreteTag.TagName LEFT JOIN Message ON DiscreteTag.MessageKey=Message.MessageKey 

[beachbear]

Этот запрос какой-то неполный. В нём налево и направо используется символ подчёркивания, как объект, который не определён. Нет ли в логе предыдущего запроса, где он определяется? Должно быть возможно выполнить этот запрос вручную над базой Runtime в SSMS. Но то, что подобный запрос может зависать - вполне ожидаемо, поскольку он как раз полагается на таблицу Tag и другие, которые в этот момент могут быть эксклюзивно залочены реимпортом

[Roman_Surkov]

Если выполнить этот запрос в SSMS в обычном режиме работы - то всё OK, возвращается инфа о тэге из запроса. В процессе реимпорта - запрос, конечно же, зависает
В логе все предыдущие запросы идентичны данному, только тэги разные.
Ну да ладно, раз оно всё лочится, придётся, наверное, с этим смириться

[NewOrdered]

Здравствуйте!

На АРМах имеются Historian Client Trend, стучащиеся на сервер Historian. В процессе ReImport'а тэгов на сервере (добавление/изменение) связь клиентов с сервером отваливается, Historian Client Trend зависает. После завершения импорта (процесс не быстрый, используется Full Re-Import) связь возобновляется, все изменения тегов, писавшихся в Historian в момент отсутствия связи, начинают отображаться на трендах.
В чём может быть проблема отвала связи между клиентами с сервером? Сервер все свои ресурсы бросает на обновление своих баз и перестаёт отвечать клиентам?

Подозреваю, что SQL-сервер используется версии Express. А это означает ограничения в использовании ресурсов CPU, RAM, диска и т.п. Отсюда и долгий процесс реимпорта, и отсутствие отклика на другие запросы в процессе реимпорта.