Support for a redundant Historian server

A Historian may be configured to have a symmetrical "partner" Historian that can be used as a backup if the primary, or main, historian is not available. This is known as a "redundant historian" setup. No control configuration is required to take advantage of a redundant historian.

When the primary historian is unavailable, the Alarm Control automatically switches over to the configured partner historian. The control remains connected to the partner historian, even when the primary historian becomes available again. The Alarm Control switches back to an available primary historian if it fails to connect to the partner or during a new attempt to connect to the primary historian. One example of this would be restarting the Trend Control, which initiates a new connection to the primary historian. For a redundant historian setup, both historians must be configured to store events to the same location, either to history blocks or the A2ALMDB database.

When the Alarm Control successfully connects to either the primary historian or its partner, the following columns are updated with the connected historian server name in the tags list of the selected tags:

• Server

• I/O Address

The historian name shown in the Tag Picker is always the name of the primary historian, even when the control is connected to the partner.

There is no automatic synchronization built in to the redundant historian setup; it is up to the historian server administrator to make sure that the two historians in the pair are symmetrical and synchronized.

If the SQL Server Service is running while Historian Service is not running, this is not recognized by the Alarm Control as a scenario in which the Historian Server is unavailable.