Synchronization Process

Archive synchronization as part of the disaster recovery system makes it possible to synchronize all archived values between a primary working database and a secondary redundant database via a special database connection. In this process, the (RDB-compressed) values and alerts are synchronized between two databases.

The goal is to ensure that both databases contain up-to-date data. If for some reason (hardware failure, network malfunction, etc.) data is missing from one database, it is preserved in the other. Therefore, synchronization is performed in both directions, and the data in both databases is identical after each synchronization.

Note: The PROJ_PATH/db/buffer/ directory is not synchronized, as each RDB Manager (redu host) has its own buffered files.

In contrast to the synchronization of historical values in the database, the online data synchronization and the parameter data synchronization are always done in one direction only: from PSS to SSS.

The synchronization is started exclusively by the user. Once started, the synchronization period is assigned to the system. An Oracle® process then takes over the execution of the synchronization at the specified interval (see alsoDatabase Synchronization).

The connection to the two databases is built via an Oracle® database connection. The status of the synchronization is saved in a database table.

CAUTION: The first synchronization after performing the synchronization setup may cause errors because Oracle® packages need to be recompiled, a process that is performed automatically. This will block the synchronization process. After the automatic compilation is complete, the synchronizations work successfully.

Configuration

Since WinCC OA cannot guarantee that the element IDs are the same on both systems, a so-called "mapping" is only required on the side of the local database.

Thereby the mapping table must be updated, in which each element ID of the local database and the corresponding element ID of the remote database are entered.

The synchronization follows the same principle as for the WinCC OA RDB Manager. The data is entered into the last value tables, collected and then transferred block by block from there into the history tables.

Procedure of a synchronization

The synchronization runs in four steps:

The local archive data is written to the remote last value table. In the process, the element IDs are adjusted with the help of the mapping table.
The archive data of the remote database is written to the local last value table. Again, the element IDs are adjusted using the mapping table.
SyncValarch.InsertHistory is started in the remote database, fetches the archive data previously written to the last value table and writes it to the history table.
SyncValarch.InsertHistory is started in the local database, repeating the same process as before on the local DB side.

Note: After the synchronization is complete, remove the network shares required for engineering purposes.

Figure 1. Database synchronization process

Synchronization of compressions (RDB compression option)

Synchronization of compressions is performed in the same way as described above. It should be noted that compression tables do not have a last value table and must therefore first be created in order to perform synchronization. This must be done manually as the setup does not provide for this.

Synchronization of alert archives

Synchronization of alerts is done in a similar way. Alerts have columns with a user-defined type that displays a list (LANGSTRING column). With this type the Oracle® data transfer reaches its limits, so this type must be changed before synchronization.

Alert synchronization from the local to the remote database (L2D).

All LANGSTRING values are written to a local L2D table where they are converted to a comma-separated string (see figure below, step 1a) and then sent to the remote L2D table via the database connection. When transferred from the L2D table to the history table, the value is converted back to a LANGSTRING (see figure below, step 3).

Alert synchronization from remote to local database (D2L)

From the remote database, the values are simply copied to a local last value table, the ID is mapped, and then the entry is made to the history table. In this case there is no LANGSTRING transformation, because the transfer and ID assignment cannot be done in one step.