The Alert Persistence feature stores 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. You can configure the alert engine to persist alerts directly to the database or via a data server. More than one alert engine can persist its alerts to the same database table as long as each alert engine specifies a unique Alert Engine Name (specified on the Alerts>Alerts Persistence tab in the Application Options dialog).

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 two phases of configuration necessary to enable RTView to support the persistence of alerts: Database Configuration and Alert Engine Configuration.

Database Configuration

You can either let the RTView create the database table or you can create the table. If you want to the RTView to create the table, select the Create Database Table If Not Found option (on the Alerts>Alerts Persistence tab in the Application Options dialog).

If you want to create the table yourself, table schemas for several databases are included 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
AlertEngineName	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 AlertEngineName 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.

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.