Changing the Storage location of an Alarm Historian

Changing the storage location of an active Historian is a coordinated effort. During the process you want to avoid spontaneous workstation restarts, changes to server lists and alarm lists or alarm configurations. Plan for a slow period and inform your team to keep their hands off until the process has completed and all workstations have syncronized.

While VTScada is rebuilding the alarm state after the storage location has changed, application performance will be poor. The rebuilding process may take a long time depending on the size of your application (primarily, the size of the alarm data).

In VTScada you can change the Storage Location of a Historian that has been storing alarm and events data and transfer all existing data to the new location, but proceed with caution. A misstep risks the permanent loss of data or may result in synchronization discrepancies. The best time to select a storage location other than the default is during the development and commissioning phase of an application.

There are three options for moving the storage location of an Alarm Historian. The recommended process depends on whether or not you must preserve existing records and whether or not you can shut down your application during the move. If the new storage location does not contain the previous historian records, the alarm lists will be rebuilt without that historical information.

Option 1: Existing Alarm History is Not Required.

If the existing alarm history is no longer needed you can change the Storage Location directly in the DataStore (Advanced) tab of the Historian tag.

Once the change has been applied, VTScada will begin using the new location. The new location will not contain any previous history. All alarm history will be lost, but alarm lists will automatically be re-evaluated to reflect the current state of the application.

Check that new records are being stored to the new storage location.

Option 2: Existing Alarm History is Required and No Records can be Lost.

If all existing history must be retained, you will have to create the conditions in which no new records are being made during the move and you will have to move the existing history to the new location before you begin using it as a new Storage Location.

Prepare the new storage location, create a directory on all servers.
Shut down all workstations. All workstation are off, no new records are being made.
From the primary server, copy the existing Historian data to the new storage location. If the Storage Location of the Historian was never configured, the default location is in a Data folder within your application folders (For example, C:\VTScada\YourApplication\Data..)
Confirm the existing history now exists in the new storage location before updating the Historian tag.
Open the Application Configuration dialog of your application from the VAM on your primary server. Export your tags. Update the Historian tag's StorageLocation in Excel and import your tag changes on the primary server.
Start the application on the primary server.
Wait and monitor. After the application has fully started, VTScada will complete an alarm-list reset and rebuild process. This may take awhile.
Once the historian records and alarm state have been rebuilt, start all the other workstations and give them time to synchronize.
Confirm the outcome. Check the state of Alarm Lists on the affected workstations:
- Do Alarm Lists appear consistent across servers?
- Do Active Alarms reflect the current state of alarming tags?
- Can you find the Historical alarm records from the new storage location?

Option 3: Existing Alarm History is Required and Applications Cannot be Shut Down.

If the existing Alarm History is Required we very strongly discourage attempting to change the location of your Alarm Historian while your application is running. The risk of disruption and the loss of records created during the process is significant. There is no guarantee that the entire Alarm History will be preserved. This option only exists for the uncommon scenario where there really is no other alternative.
Before attempting this final resort, we strongly encourage you to reach out to support or your local rep to seek alternatives.

If you cannot shut down your applications and workstations, manage risk by ensuring all servers are online, communication between workstations is stable and quiet, and no server failover is in progress.

Prepare the new storage location, creating the directory on all servers.
From the primary server, copy the existing Historian data to the new storage location. If the Storage Location of the Historian was never configured, the default location is in a Data folder within your application folders (For example, C:\VTScada\YourApplication\Data..)
Confirm the existing history now exists in the new storage location before updating the Historian tag.
Change the Storage Location directly in the DataStore (Advanced) tab of the Historian tag and hit apply.

When the storage location is changed in the Historian tag, all linked Alarm Database tags are automatically notified. They respond by performing an alarm-list reset and rebuild process. Only the active server performs this process. If a backup server becomes active during the operation, it will perform the process after failover.

After the change is complete, all alarm lists should reflect the records available in the new location and the current state of the configured alarming tags. Confirm that new records are being stored in the new storage location.

Expected Alarm-State changes after changing storage locations

The rebuilt alarm state is based on the history present in the new storage location and the current state of configured alarming tags.

The following information is not guaranteed to be preserved:

The inactive but unacknowledged alarms
Ad-hoc alarms

For example, an inactive but unacknowledged alarm may disappear after the storage location is changed and the alarm lists are rebuilt. This is expected behavior and does not indicate that the rebuild failed.