Abgleichvorgang

Mithilfe des Archivabgleichs, im Rahmen des Disaster Recovery Systems, gibt es die Möglichkeit, einen Abgleich aller archivierten Werte zwischen einer primären Arbeitsdatenbank und einer redundanten, sekundären Datenbank über eine spezielle Datenbankverbindung durchzuführen. Hierbei werden die (RDB-verdichteten) Werte und Alarme zwischen zwei Datenbanken abgeglichen.

Das Ziel ist es, dass beide Datenbanken aktuelle Daten beinhalten. Falls aus irgendwelchen Gründen (Ausfälle von Hardware, Netzwerkstörungen, etc.) Daten in einer Datenbank fehlen, erhält diese die Daten von der anderen Datenbank. Somit erfolgt der Abgleich in beide Richtungen.

Anmerkung: Das Verzeichnis PROJ_PATH/db/buffer/ wird nicht abgeglichen, da jeder RDB-Manager (Redu Host) seine eigenen gepufferten Dateien besitzt.
Anmerkung: Der Onlinedatenabgleich und Parametrierdatenabgleich erfolgt im Gegensatz zum Abgleich historischer Werte in der Datenbank immer nur in eine Richtung: vom PSS zum SSS.

Gestartet wird der Abgleich ausschließlich vom Benutzer. Dieser übergibt dem System den Abgleichzeitraum. Ein Oracle®-Prozess kümmert sich dann um die Ausführung des Abgleichs im übergebenen Intervall (siehe auch Datenbank Abgleich).

Die Verbindung der beiden Datenbanken erfolgt über einen Oracle®-Datenbank-Link. Der Status das Abgleichs wird in einer Datenbanktabelle gespeichert.

VORSICHT: Während des ersten Abgleiches nach der Durchführung des Synchronisations Setups kann es zu einem Fehler kommen, da die Oracle® Packages automatisch neu kompiliert werden und dieser Vorgang den Abgleich blockiert. Nach Abschluss dieser automatischen Kompilierung werden die Abgleiche korrekt durchgeführt.

Konfiguration

WinCC OA kann nicht gewährleisten, dass die Element-IDs auf beiden Systemen gleich sind, deshalb benötigt man ein sogenanntes "Mapping" auf der lokalen Datenbankseite (und nur dort).

Die Mapping-Tabelle muss aktualisiert werden:

Jede Element-ID der lokalen Datenbank und die entsprechende Element-ID der entfernten Datenbank werden in diese Tabelle eingetragen.

Der Abgleich erfolgt nach dem gleichen Prinzip wie beim WinCC OA RDB-Manager:

Daten werden in die Letztwerttabellen eingetragen, gesammelt und von dort dann blockweise in die History-Tabellen verschoben.

Ablauf eines Abgleichs

Anmerkung: Entfernen Sie nach Abschluss der Synchronisierung die für Engineeringzwecke erforderlichen Netzwerkfreigaben.

Der Abgleich durchläuft vier Schritte:

  1. Lokale Archivdaten werden in die entfernte Letztwerttabelle geschrieben. Dabei werden die Element-IDs mithilfe der Mapping-Tabelle angepasst.
  2. Die Archivdaten der entfernten Datenbank werden in die lokale Letztwerttabelle geschrieben, dabei werden die Element-IDs mithilfe der Mapping-Tabelle angepasst.
  3. Auf der entfernten Datenbank wird die Prozedur SyncValarch.InsertHistory gestartet, wodurch die Archivdaten innerhalb der entfernten Datenbank von der Letztwerttabelle in die History-Tabelle übertragen werden.
  4. Auf der lokalen Datenbank wird die Prozedur SyncValarch.InsertHistory gestartet, wodurch die Archivdaten innerhalb der lokalen Datenbank von der Letztwerttabelle in die History-Tabelle übertragen werden.

Abgleich von Verdichtungen (Option RDB-Verdichtung)

Der Abgleich von Verdichtungen erfolgt in der gleichen Weise, wie es oben beschrieben wurde. Dabei ist aber Folgendes zu beachten:

Verdichtungstabellen haben keine Letztwerttabellen, deswegen müssen die jeweiligen CS…LASTVAL-Tabellen angelegt werden, um einen Abgleich durchführen zu können. Das Setup sieht dies zurzeit noch nicht vor, deswegen hat das händisch zu erfolgen.

Abgleich der Alarmarchive

Der Abgleich für Alarme erfolgt ähnlich.

Alarme haben Spalten mit einem benutzerdefinierten Typ, der eine Liste darstellt (Spalte LANGSTRING). Mit diesem Typ stoßt der Oracle®-Datentransfer an seine Grenzen, weswegen vor dem Abgleich dieser Typ umgewandelt werden muss.

Alarm-Abgleich von der lokalen zur entfernten Datenbank (L2D)

Alle LANGSTRING-Werte werden in eine lokale L2D-Tabelle geschrieben und dabei in einen durch Komma getrennten String umgewandelt (siehe Abbildung unten Schritt 1a), dann über den Datenbank-Link in die entfernte L2D-Tabellen geschickt. Beim Übertrag von der L2D- Tabelle in die History-Tabelle wird der Wert wieder in einen LANGSTRING zurückkonvertiert (siehe Abbildung unten Schritt 3).

Alarm-Abgleich von der entfernten zur lokalen Datenbank (D2L)

Von der entfernten Datenbank werden die Werte einfach in eine lokale Letztwerttabelle kopiert, die ID wird gemappt und dann erfolgt der Eintrag in die History-Tabelle. In diesem Fall gibt keine es keine LANGSTRING-Umwandlung, weil Übertrag und ID-Mapping nicht in einem Schritt erfolgen können.