The Alert Persistence feature stores the all fields and current state of all active alerts, as well as all cleared alerts that have not been removed from the system in a database using the Historian. Alerts are sent from the application running the alert engine to the Historian via the RTVAgent. More than one alert engine can persist its alerts to the same database table via the same Historian as long as each alert engine specifies a unique Agent Name (specified on the Alerts>Alerts Persistence tab in the Application Options dialog). The Historian must be configured to run the RTVAgent data source locally (not via Data Server) to receive alert table updates. Other data sources in the same Historian can still use the Data Server.

With this feature enabled, alerts will be persisted as follows:

• If you are running the alerts in a Data Server or in a locally client application (Display Builder, Display Server, Display Viewer), all active and cleared alerts that had not previously been removed from the system will be restored when the application is restarted and all new alerts will be generated using IDs that are unique from the previous session.
• If you are running the alerts in a Data Server that is configured for High Availability, you can run the backup server in warm standby mode. All active and cleared alerts that had not previously been removed from the system will be restored to the standby server when it becomes the active server. NOTE: It is not recommended that you run the standby server in hot standby mode when using alert persistence as in that case both Data Servers will persist the same alerts to the database.

When the alert engine starts up, it will query the database table containing the persisted alerts and will recreate them at startup in the new alert engine. The persisted alerts will show up in the alert engine after the Initial Delay time (specified on the Alerts>Alert Definitions tab in the Application Options dialog) has expired.  All alerts that are configured to renotify on a timer will immediately renotify, then continue to renotify on the specified renotification time.

To clear the alerts for an alert engine from the database on startup use the purgepersistedalerts command line option. This will clear all alerts for the alert engine from the database table on startup and no persisted alerts will be loaded. If you are persisting alerts for more than one alert engine in the same database table, alerts for other alert engines will not be removed.

For optimization, the alert engine does not store updates to the Last Update Time column of the AlertTable unless there has also been another change for that alert. In many cases this column is not used by RTView applications. However if you want to restore the alerts with accurate values in the Last Update Time column, you can use the lutupdatesnewdata command line option to enable this update.

There are three phases of configuration necessary to enable RTView to support the persistence of alerts: Database Configuration, Historian Configuration and Alert Engine Configuration.

Database Configuration

The Historian will store the alerts to a database table. You can either let the Historian create the database table or you can create the table. If you want to the Historian to create the table, there is nothing you need to do -- the table will be created the first time the Historian stores an alert.

If you want to create the table yourself, we have included table schemas for several databases in RTV\dbconfig\alert_persist. The README.txt file in that directory will assist you in using the schemas to create your table. If you want to create it manually, create a table with the following column names and types in the following order:

Column Name	Type
AgentName	String
Time	Timestamp
Alert Name	String
Alert Index	String
Severity	Integer
Alert Text	String
Cleared	Boolean
Acknowledged	Boolean
ID	Long
Last Update Time	Timestamp
Comments	String
Owner	String
<Custom Alert Definition Property and Custom Event Attribute Columns>	TBD
current	String
level	Integer

The AgentName and ID fields are primary keys. If you have defined Custom Alert Definition Properties and/or Custom Event Attributes, you will need to insert columns of the correct type in the order they appear in the AlertTable before the current column.

Historian Configuration

This section assumes a working knowledge of the Historian and that you have configured the Historian database.

Alerts are sent from the application running the alert engine to the Historian via the RTVAgent.
In the Application Options dialog in the Display Builder or Configuration Utility, go to RTVAgent->RTVAgent Options to specify the port number on which you would like to receive alerts. Copy the RTVAGENTOPTIONS.ini file to the directory where you will be running the Historian.

Configure Alert Persistence in the Historian.
From the directory where you will be running the Historian, run the Historian.. Select the Configuration tab and go the Alert Persistence section.

The Historian must be configured to run the RTVAgent data source locally (not via Data Server) to receive alert table updates.
If you are running the Historian against a Data Server you can run the RTVAgent data source locally with the following command line argument:

run_historian -dsenable:RTVAGENT

Alert Engine Configuration

In the Display Builder, select Tools>Options to open the Application Options dialog. To configure the alert engine, select Alerts>Alert Persistence.

Alert Persistence Requirements and Limitations

Requirements

1. Alert definitions and options must be the same before and after failover. For example, if you are running a primary and standby Data Server in two different locations, you must confirm that both are configured with the same alert definitions and option. If your alert options have changed, persisted alerts might be incorrect after failover.

2. If any of the following properties on your alerts are attached to data, those data attachments must be available after failover and you must specify an Initial Delay time. This will allow the alert engine restoring the persisted alerts to resolve those data attachments before finishing the processing of the persisted alerts. The Initial Delay only needs to be long enough for your data attachments to resolve. Any of these properties that use a ; (semicolon) delimited list or a tabular data attachment must include index values, such as:

• rowEnabledTable
• value*Alert (i.e. valueHighAlert, valueLowAlert, valueMediumAlert)
• value*Warning (i.e. valueHighWarning, valueLowWarning)
• value*Text (i.e. valueHighAlertText, valueHighAlertCommandText, valueMediumAlertText, valueMediumAlertCommandText, valueLowAlertText, valueLowAlertCommandText, valueHighWarningText, valueHighWarningCommandText, valueLowWarningText, valueLowWarningCommandText)
• alertState*AlertText
• alertState*AlertCommandText
• alertState*Comparison
• alertState*UpperRangeLimit
• alertState*LowerRangeLimit

3. The database table where the alerts are persisted must contain a column for each column in the AlertTable, along with a couple of additional columns. Therefore, if you add, edit or remove Custom Alert Definition Properties or Custom Alert Event Attributes, the database table will need to be modified.

4. If you have multiple alert engines persisting alerts to the same database table, they must have the same Custom Alert Definition Properties and Custom Alert Event Attributes.

Limitations

1. Alerts that attach directly or indirectly to a function that outputs a non-table value (Text or Number) may be incorrectly cleared after failover.

2. The nonRepititionTime for an alert restarts after failover.

3. Depending on the frequency of data that drives the alert, it is possible that an update to an alert might be missed during failover. The likelihood of missing an update increases the longer the time is between the exit of the first engine and the startup of the second.

4. After failover, the per-alert variables will only contain the alert indexes that were persisted in the AlertTable. The other indexes will be added after data has been received for them.