800xA 5.1.4-2 Trends disappearing from workstation. Stopping basic history on one conn server restores.
After periods of time the trends from a customers workstations will not call up.
If we stop the basic history service on one connectivity server they return.
Later restarting the service things are good for what appears to be about a month in time.
Prior to stopping the history service a sequential reboot of the connect servers would restore trend functionality.
Systm 800xA 5.1.4-2RU2.
Has anyone seen the same?
And if so what is/was the reasoning behind it?
Assuming that you are working with 800xA History 2.0 RU2, this appears to be an issue that has been recently discovered, and there have been two TC's to address this issue, TC10 (for the History Server(s)), and TC11 (for the DCN(s)). You should open a Support case with your local RAC, and send information about your actual issue so that it can be determined if these TC's are appropriate for your system.
You wrote "Basic History" but have also tagged "800xA History"?
If you are using the Basic History feature embedded with the core system (ie no RTDB nor DCN nodes) I recommend the following:
1) Keep a watch on the AdvHtHistorySrv.exe process' Virtual Bytes Counter using Windows Performance Monitor; eg deploy a Counter Log and record the counter every minute. It shall not steadily increase, crasch/malfunction is likely near 2048 MB (limit for a 32-bit process, even if MS Windows run 64-bit version).
2) Keep a watch on Service Provider Statistics (there is a statistics object below each service provider in the service structure). There are numerous of counters, but eg ActiveAdviseRequests will tell number of subscribing trends. Other, self explanatory ones will tell eg bytes read, trends read, max time of read, etc.
3) Monitor the [Workplace Structure]Web System Workplace:System Event List for events related to Basic History
4) Monitor general computer health of the server computers (CPU, Virtual Memory, Windows Event Log, etc)
Maybe you have a rogue client consuming too much power from Basic History, eg some report making request for immense amounts of trend data causing some internal resource to slowly bleed?
If you find a suspect client, try moving it to the other redundant server by changing affinity. If the problem follow the client you have made a finding...
My estimate is that some of the above listed items will give more information.
Ultimately, have a support case logged with your regional ABB support center.