Datapump

About

Historical data is replicated between systems with the Datapump application. Any Historical data that is added or modified to the Hot Historical service is replicated to the other system(s).

Datapump replicates data by keeping a constant connection with the source and destination databases. It frequently performs small scans of key tables in the Historical database to extract modifications. A key table is a small table of keys that acts as a queue for data that needs to be transferred. Data transferred through the open connection imposes a small, constant load on the network.

Note: There may be one or more destination systems depending on the configuration of AVEVA Enterprise SCADA. For example, a system might have an emergency backup system and a decision support system.

In an arbitrated Historical configuration with a Hot and Standby Service, the applications that use Historical only add data to the Hot Historical service. If the data source system changes, for example, during a failover or mode switch, there may be outstanding data updates. In this situation, the updates continue to replicate even though the source system is no longer online.

Datapump is configured for each Historical table so subsets of tables can be transferred to a destination system if desired.

Note: Datapump is configured using AVEVA tools and predefined configurations. Under no circumstances should the commands to configure Datapump be used directly. If manual commands are issued to modify Datapump, these commands will be lost if the system is reinstalled or recovered after a failure. Issuing manual commands to modify Datapump could also result in inconsistencies and cause replication to fail. To modify Datapump configuration, contact your Service manager.

Key Concepts

• Datapump supports two types of replication: KeyTable and Replace.

• All generic Datapump tables and procedures are part of the xosapp database. All tables and procedures created to support datapumping a specific database (for example, accum) will be created in that specific database.

• DPdirect is the process that extracts data from the Historical database based on the data in the Key Table, and sends it to each destination specified in the Key Table.

• Every table must have a Trigger by Process, a DPFill stored procedure, or a Trigger by SysId to datapump the data.

Key Tasks

• Configuring Datapump

• Configuring Datapump in an untrusted domain

• Troubleshooting