www.InTouch.su

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

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

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

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

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

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

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

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

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

SELECT UtcDate=Getutcdate()

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

В общем, запрос 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 

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

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

Roman_Surkov писал(а):Здравствуйте!

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

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