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 are persisted as follows: If you are running the alerts in a Data Server that is configured for High Availability, you must 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: You cannot run the standby server in hot standby mode when using alert persistence as in that case both Data Servers will generate alerts and persist them to the database. Also, with High Availability if your persistence database is slow, or you expect a large number of alerts to change each update period, you can use the persistInitDelayTime command line option to increase the delay time for when a backup server reads the primary server alert persistence database. Otherwise, there might not be enough time for the failing Data Server to write all the alerts to the database before the backup server reads them.

NOTE: Even with high availability configurations, there are cases in which some alerts might not be persisted. For example:

• The persistence database fails. In this case, alerts cannot be written to, or read from, the database. If a failover occurs while the database is down, the backup server will not be able to read persisted alerts from the database. This will also happen if persistence is configured to use a Persistence Data Server to access the database, and the Persistence Data Server is down during failover.
• The Alert Server is terminated in a non-orderly shutdown. Alerts are written out once per update period and once during orderly termination. If there is a non-orderly shutdown, some alerts might not be written to the database.

In cases where alerts are not persisted, the new primary Data Server generates new alerts if the data is still in an alert state. The new primary Data Server might also re-use ID's that were used by the failed Data Server.

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
Row 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.