Synchronization Oracle RDB

Configuration

To use Oracle Streaming following configurations must be applied:

All paths and files are relative to the path <wincc_oa_path>\3.19\data\RDBSetup\ora\

1. On the PSS DB and on the SSS DB a database schema must be configured (see Configuration of the RDB Database Schema)

2. Configure RDB_config.sql for Historical Synchronization and copy to folder /sync/ *

3. Install the Historical Synchronization for both database schemes (see Installation of Historical Synchronization)

4. Set config entry Db="host1,host2" **

5. Set forward option for ArchiveGroups EVENT and ALERT (optional) ***

6. Create further RDBArchiveGroups ****

7. Configure the backup settings and Online-Tablespace count ***

8. Configure RDBCompression (optional)

* = Following changes must be made in the RDB_config.sql file:

sync_intval_len = 3 means that every 3 minutes the saved values from the local database are sent to the "connect_second" database.

connect_second represents the redundancy partner for the database.

** = The second host name for the config entry Db = "host1,host2" is necessary for the RDBManager. In case of an error of the PSS database the RDBManager connects to the host 2 (SSS) database. The entry has to be set in the [ValueArchiveRDB] section.

*** = The settings can be found in WinCC OA under: System Management > Database > Database Configuration > Parametrize

**** = The settings can be found in WinCC OA under: System Management > Database > Database Configuration

CAUTION

• When a new archive group was created, the "DB server path" on the second dbhost for this group was set to the default path. It can be changed if necessary.
• When using Linux, the switching between two Oracle databases can take a relatively long time. To increase the performance, the sysctl.conf must be changed. The file is located in /etc/sysctl.conf . The value for the entry net.ipv4.tcp_retries2 must be changed to the value 2. Afterwards the command "sysctl -p" must be called.

Automatic Transfer

Following configurations will be transferred automatically from dbhost1 to dbhost2:

• creating of archive groups

• setting for the forward flag (on/off)

• deletion of archive groups

• RDB Compression

• changes for the archive group configuration except path changes

• creation of archive group templates

Non Automatic Transfer

Following configuration will not be transferred automatically and must be done manual:

• Backup/Restore

With the Combobox at the RDB archive group Panel the dbhost can be changed to set configurations which are not transferred automatically. If one of the RDB configuration panels is opened and a historical query e.g. in the AES is started, only the actually selected dbhost (with the Combobox) is used for the query. This is due to the fact that a UI can only have one database connection at a time. A similar ComboBox can be found in the configuration panel of the RDB compression.

When using "Forwarding", the values that are stored inside the archive group are automatically sent from dbhost1 to dbhost2

Multiple Field Systems

If multiple field systems exist and use the historical synchronization it is recommended to group them in one database scheme and differ them using different archive groups, e.g.:

FieldSystem1: DbScheme ‚FS’, Archivgroup ‚RegionA’

FieldSystem2: DbScheme ,FS’, Archivgroup ‚RegionB’

….

FieldSystem 10: DBScheme ‚FX’, Archivgroup ,RegionY’

FieldSystem 11: DBScheme ‚FX’, Archivgroup ,RegionZ’

Restriction of RDB Compression

If the RDB Compression should be used for the single field systems in the same DB schema the following terms have to be considered:

The compression intervals are not set per System but per DB schema. I.e. if one compression interval is deactivated not only the actual system is affected but all systems in the DB schema.

Advantage: It is not necessary to configure compression intervals for each system and the number of necessary database jobs is therefore reduced to a minimum.

Behavior at Connection Loss

In case of a lost connection (Interrupt of the network, DB not available,..), the RDBManager tries to write values to the buffer block for 5 times (can be set using _RDBArchive.dbConfig.writeMisses). If retries fail the connection to dbhost1 is closed and a connection to dbhost2 will be opened. Before starting the write process for dbhost2, the RDBManager waits for the configured synchronization interval (= syncjob_intval in the RDB_Config.sql; Default = 3 minutes) to allow perhaps currently running merging processes to finish.

While the RDBManager is connected with the dbhost2, a reconnect to dbhost1 is tried every 20 seconds (can be set using _RDBArchive.dbConfig.dbWriteDelayError).

With the internal data point _RDBArchive.dbConnection.usedHost it can be read which DB host the RDB manager is currently connected to or trying to connect to.

If no dbhost is available, the RDBManager buffers the values locally (using BufferToDisk). As soon as a connection to a database is established, all buffered values are written to that database.

If a connection loss between dbhost 1 and dbhost 2 occurs, the data is synchronised (see Historical Synchronization) at the moment the connection is reestablished. This grants that no loss of data takes place.

Reading Access

Per default a reading access is always sent to dbhost1. If dbhost1 is not accessible and queryRDBDirect is active (=1), a connection to dbhost2 is opened. If a query is done using dbhost2, data can be missing due to a perhaps not finished historical synchronization between PSS and SSS. So only the data up to the last synchronization process is available.

If queryRDBdirect is inactive (=0) the data access is performed using the RDBManager. When using the RDBManager a change between dbhost1 and dbhost2 is only performed in case of an incorrect writing access, i.e. a reading access returns no value in case of connection failure to dbhost1 as long as no change to dbhost2took place, due to an incorrect writing access.

To establish a connection to a specific dbhost, e.g. for a UI, the ctrl function setUseOnlyThisDbName can be used. This setting is valid until the UI is closed or the setting is changed again using setUseOnlyThisDbName).

Maintenance

To properly close the connection to the Oracle database for maintenance tasks in Oracle following steps are necessary:

1. Set the internal data point _RDBArchive.dbConnection.closeDbConnection TRUE or alternatively set the internal data point _RDBArchive.dbConnection.openDBConnection to FALSE to close the connection between RDB Manager and database.

2. Do maintenance work.

3. To open the database connection between RDBManager and Oracle again set the internal data point _RDBArchive.dbConnection.closeDbConnection FALSE or alternatively set the internal data point _RDBArchive.dbConnection.openDBConnection to TRUE.

RDB Compression

The RDB Compression configuration will be done on both systems (PSS and SSS). Archive groups and DBJobs will be applied. The data for the calculation will be delayed because of the synchronization interval. It is recommended to define a delay for the compression interval.

Manual Historical Synchronization

The "Historical Synchronization" Panel can be opened at the RDB configuration panel. The "Historical Synchronization" Panel gives an overview for open or failed synchronization processes. Additionally a time range can be defined for the synchronization or a manual synchronization can be started.

Warnings

Update of DPE

Different from creating DP elements, updates of DPE (= changes of Alias, Comment & Unit) are not buffered. The RDB Manager is sending the updates to the active and connected dbhost and afterwards to the passive dbhost. If the passive host is not available, the updates are lost. To apply the updates, the changes have to be done again.

Alert Update

Following sequence leads to a loss of alert update values:

1. Alert X is written by the RDB manager to dbhost1

2. Connection between dbhost1 and dbhost2 is lost before a synchronization can be performed (i.e. Alert X is only known to dbhost1)

3. Connection between RDB manager and dbhost1 is lost and the RDB manager connects to dbhost2.

4. RDBManager sends an update of alert X to dbhost2

The update for alert X will be dropped due to dbhost2 not knowing the alert. If a synchronization is performed afterwards the synchronization will send alert X to dbhost2 with the value known to dbhost1, which leads to the loss of the update information sent only to dbhost2. Usually loss of data is restricted to the time interval of the synchronization (see. sync_intval_len at the RDB_config.sql file).