Understanding plan replication

Datapump is used for replication between Historical systems, and from AVEVA Enterprise SCADA databases onto non-AVEVA Enterprise SCADA databases. Currently, Microsoft SQL Server clustering is used to provide redundancy between the dual-hosted Historical databases.

Datapump configuration involves a mix of static, manually edited, and dynamically generated configuration files. The initial installation of Datapump provides some Datapump configuration files and configuration tools.

Datapump supports two types of replication: KeyTable and Replace.

• The KeyTable method of replication means each table has a corresponding table called a KeyTable. The KeyTable contains a list of rows that need to be transferred to the destinations. Table triggers or stored procedures are used to add KeyTable rows whenever the table is modified. The DPdirect process extracts the data from Historical database based on the data in the Key Table, and sends it to each destination specified in the Key Table. This method of replication is very efficient for large tables. By default, DPdirect checks the key tables for rows to replicate as often as every 30 seconds.

• The Replace method of replication loads the source and destination table contents, compares them, and performs the necessary inserts, updates, and deletes at the destination system. Because two complete copies of the data must be held in memory for this operation, it should be reserved for tables smaller than 1000 rows.

  Note: Unlike KeyTable replication, Replace replication is insensitive to changes in dataset ownership. For bi-directional replication of the table (changes originating on the source as well as the destination), do NOT use Replace. If changes occur on the source and the destination before the tables are in sync, one set of changes will be lost.

Before starting, consider the following:

• What tables need to be replicated?

• Do only select columns need replication?

• You can replicate a view rather than its table, provided that the table has a unique index. If a view is used, ensure that the name includes the keyword 'View' so that Datapump can distinguish between the view and the table.

• What are the replication destinations for each replication source system?

• Are there replication destination systems that are not AVEVA Enterprise SCADA systems?

• Do some tables need to be hopped from one destination to another destination as the final destination is not connected directly to the source system (e.g. data from the primary system gets replicated to the offsite system then hopped to a decision support system that is only connected to the offsite)?