System 800xA upgrade - Basic History service logs
We performed a system upgrade which involved an architecture change, basically we splitted the old AS/CS servers and now we have redundant AS/DC and redundant CS. The history source aspect still points to the AS/DC, because of the system restore. The basic history logs now have data stored for a week, my question is, if I change the history source to points the connectivity servers in order to get the basic history service properly configured, which steps should I follow in order to be able to restore the data that will be lost when the history source will be modified? What could happen with the IM history logs?
The IM history logs have been storing data for a month.
As far as I understand, running basic history on the AS could create a lot of network traffic, one thing we are facing is a low response on the trend aspects, when the operator opens two or more trend aspects, the workplace crashes and it has to be restarted.
This topic has been discussed many many times on AKS (search for my inputs)!
Be careful when changing History Source; Basic History data will go lost unless backed out with backup tool or plain file copy (I use ZIP to shrink files to be transferred).
A theoretic Basic History transfer involves: stop "donor"; zip logs; stop receiver; unzip logs; change History Source; start recipient; check data is available in recipient.
The name of the folder below \OperateITData\History\ is the GUID of the Basic History service provider running on that node. Folders are often never removed by a departing service provider, hence manual cleanup is often a necessity.
The advhtarchive.exe tool can "inject" content from a backup into a *running* log if IDs or names are retained. Study online upgrade manual for intended use.
Hint: do not copy objects or aspects. New creation time of object or log configuration aspect almost always mean old logged data has gone lost.
An IM log does not readily accept these manipulations possible with Basic History; be careful with logs running in IM.
I realize that I left half of the questions unanswered.
Moving a log residing in BH from one server to another is just to change the History Source governing the log. Log files must be moved manually to retain their content.
An IM "above" that primary log won't mind this move; the IM will be able to continue reading the primary log and perform its secondary storage. IM does not like (read accept) changes to its own parts of a Log Template, if the "Storage Period" was set to 3 months at start, it will remain until the log is deleted. Contrary to IM, Basic History accept almost any manipulation (Min Time, Max Time, Log Period, etc.).
Slow response in trend display may have many reasons. Since you mention crashes, I would start with measuring the afwworkplaceapplication.exe use of "Virtual Bytes" with Windows Performance Monitor or PowerShell (get-process afwwork*).
A workplace running on a 32-bit client shall not exceed 1500 MB. A workplace on a 64-bit client can use roughly the double amount of virtual bytes before becoming unstable. Restart workplaces that are large. More recent versions and rollups have memory leakages corrected.
The next upcoming rollups on 5.1RevE/FP4RevE has a thread leakage corrected which could result in considerable amounts of memory bleeding away if workplace is heavily used for longer durations without restart.
Contact your regional ABB support center for assistance.