Synchronisation Oracle RDB

Konfiguration

Um die Synchronisation der Oracle RDB verwenden zu können, müssen folgende Konfigurationen vorgenommen werden:

Nachfolgende Pfade und Dateien beziehen sich auf das Verzeichnis < wincc_oa_path >\ 3.14 \data\RDBSetup\ora\

1. Es muss sowohl auf der PSS-DB als auch auf der SSS-DB ein Datenbank Schema angelegt werden (siehe RDB-Datenbankschema anlegen)

2. RDB_config.sql für Historische Synchronisation konfigurieren und in den Ordner /sync/ kopieren *

3. Installieren Sie die Historische Synchronisation für beide Datenbank Schemata (siehe Installation Historische Synchronisation)

4. Den Config-Eintrag Db="host1,host2" setzen **

5. forward-Option für die Archivgruppen EVENT und ALERT setzen (optional) ***

6. Weitere RDBArchivGruppen anlegen ****

7. Konfigurieren der Backup-Zyklen sowie Online-Tablespace-Anzahl ***

8. RDB-Verdichtung konfigurieren (optional)

Folgende Anpassungen sind für diesen Schritt innerhalb des RDB_config.sql files vorzunehmen:

• sync_intval_len= 3 bedeutet, dass alle 3 Minuten die gespeicherten Werte an die 'connect_second'-DB übertragen werden.>connect_second gibt den Redundanz Partner der Datenbank an.

• ** = Der zweite Hostname für den Config-Eintrag Db = "host1,host2" wird benötigt, damit der RDBManager im Falle eines Fehlers der PSS DB auf die SSS DB umschalten kann. Wird im Bereich [ValueArchiveRDB] gesetzt.

• *** = Entsprechende Einstellungen finden sich innerhalb von WinCC OA unter: System Management > Datenbank > Datenbank Konfiguration > Parametrierung

• **** = Entsprechende Einstellungen finden sich innerhalb von WinCC OA unter: System Management > Datenbank > Datenbank Konfiguration

Automatisierte Übertragung

Folgende Konfigurationen werden automatisch sowohl auf DB Host 1 als auch auf DB Host 2 durchgeführt:

• Anlegen von Archivgruppen

• Setzen des forward Flags (on/off)

• Löschen von Archivgruppen

• RDB Verdichtung

• Änderungen der Archivgruppen-Konfiguration mit Ausnahme der Pfad-Änderungen

• Anlegen neuer Archivgruppen-Templates

Nicht automatisierte Übertragung

Folgende manuelle/automatische Aktionen werden NICHT automatisch übertragen:

• Backup/Restore

HINWEISE

• Mittels der Combobox kann innerhalb der RDB-Archivgruppen Übersicht zwischen den DBHosts gewechselt werden, um so die einzelnen Konfigurationen, welche nicht automatisiert übernommen werden, vorzunehmen. Ist eines der RDB-Parametrierpanel geöffnet und es wird eine historische Abfrage bspw. im AES gestartet, so wird nur der aktuell in der Combobox ausgewählte DBHost für die Abfrage verwendet. Grund dafür ist, dass es pro UI nur 1 DB Verbindung gibt.

• Eine vergleichbare Combobox findet sich auch im Konfigurationspanel der RDB Verdichtung.

Mehrere Feldsysteme

Sollte es mehrere Feldsysteme geben, welche die Funktionalität der Historischen Synchronisation nutzen wollen, empfiehlt es sich, diese innerhalb eines DB Schemas zusammenzufassen und die weitere Unterscheidung mittels Archivgruppen durchzuführen, z.B.:

Einschränkungen RDB Verdichtung

Wenn für die einzelnen FeldSysteme im selben DBSchema auch die RDB Verdichtung verwendet werden soll, ist Folgendes zu beachten:

Die Verdichtungs-Intervalle werden nicht pro System sondern pro DBSchema angelegt. D.h. wenn ein Verdichtungs-Intervall deaktiviert wird, ist es nicht nur für das aktuelle System sondern für alle Systeme im DBSchema deaktiviert.

Vorteil: es ist nicht notwendig, alle Verdichtungs-Intervalle für jedes System zu konfigurieren und die Anzahl der benötigten Datenbank-Jobs wird dadurch auf ein Minimum reduziert.

Verhalten bei Verbindungsverlust

Im Falle von Verbindungsproblemen (Netzwerkunterbrechung, DB nicht verfügbar,..) versucht der RDB Manager noch 5 mal (mittels _RDBArchive.dbConfig.writeMisses zu konfigurieren) den aktuell anstehenden Bufferblock zu schreiben. Schlagen alle diese Versuche fehl, werden die Verbindungen zu DB Host 1 geschlossen und es wird versucht, eine Verbindung mit DB Host 2 zu öffnen. Bevor der RDBManager mit dem Schreibvorgang beginnt, wartet er noch das konfigurierte Synchronisationsintervall (= syncjob_inval in RDB_Config.sql; Default = 3 Minuten) ab, um möglicherweise laufende Abgleiche innerhalb der DB noch fertig durchführen zu lassen.

Während der RDBManager mit dem DB Host 2 verbunden ist, versucht er alle 20 Sekunden (mittels _RDBArchive.dbConfig.dbWriteDelayError zu konfigurieren) sich erneut mit DB Host 1 zu verbinden.

Mittels des Internen Datenpunktes _RDBArchive.dbConnection.usedHost kann gelesen werden, mit welchem DB Host der RDBManager verbunden ist bzw. sich gerade verbindet.

Sollte kein DB Host erreichbar sein, buffert der RDBManager die zu schreibenden Werte lokal (mittels BufferToDisk). Sobald eine Verbindung zu einer der DB hergestellt werden kann, werden sämtliche gebufferten Daten an diese DB übertragen.

Bei einem Verbindungsverlust zwischen DB Host 1 und DB Host 2 werden, sobald die Verbindung wiederhergestellt werden konnte, die Daten übertragen und synchronisiert (siehe Historische Synchronisation). Dadurch wird gewährleistet, dass es zu keinem Verlust an Daten kommt.

Lesender Zugriff

Prinzipiell erfolgt der Lesezugriff immer auf den DB Host 1. Sollte dieser jedoch nicht erreichbar sein, wird bei aktivem queryRDBDirect (=1) versucht, eine Verbindung auf DB Host 2 zu öffnen. Wird eine Abfrage mittels DB Host 2 durchgeführt, kann es zu fehlenden Werten kommen, da unter Umständen die Historische Synchronisation noch nicht durchgeführt wurde und die Werte nur bis zum letzten Abgleich vorhanden sind.

Sollte queryRDBDirect inaktiv (= 0) sein, erfolgt der Lesezugriff über den RDBManager. Dieser führt einen Wechsel von DB Host 1 auf DB Host 2 jedoch nur im Falle eines fehlgeschlagenen Schreibversuches aus, d.h. ein Lesezugriff liefert im Falle einer fehlenden Verbindung zu DB Host 1 keinen Wert zurück, solange kein Wechsel auf DB Host 2 aufgrund eines Schreibversuches ausgelöst wurde.

Will man für einen Manager (z.B. UI) die Verbindung zu einem bestimmten DB Host festlegen, dann ist dieses mittels der ctrl-Funktion setUseOnlyThisDbName möglich. Diese Einstellung gilt anschließend bis das UI beendet wird oder der DB Host erneut mittels setUseOnlyThisDbName geändert wird (Der Funktionsaufruf setUseOnlyThisDbName(""); stellt das Default-Verhalten des Lesezugriffs wieder her).

Wartung

Um die Verbindung zur Oracle Datenbank für Wartungsarbeiten in Oracle ordnungsgemäß zu beenden, sind folgende Schritte notwendig:

1. Den internen Datenpunkt _RDBArchive.dbConnection.closeDbConnection auf TRUE oder alternativ den internen Datenpunkt _RDBArchive.dbConnection.openDBConnection auf FALSE setzen. Damit wird die DB Verbindung zwischen RDBManager und Datenbank unterbrochen.

2. Nun können die Wartungsarbeiten durchgeführt werden.

3. zum Öffnen der DB Verbindung zwischen RDBManager und Oracle setzen Sie bitte den internen Datenpunkt _RDBArchive.dbConnection.closeDbConnection auf FALSE oder _RDBArchive.dbConnection.openDBConnection auf TRUE

RDB-Verdichtung

Die Konfiguration dedr RDB-Verdichtung wird auf beiden Systemen (PSS & SSS) durchgeführt. Es werden Archivgruppen und DBJobs angelegt. Da die DBJobs jeweils innerhalb der eigenen DB laufen, kommt es im Fall von DB Host 2 zu einem gewissen Verzug, da dieser die Daten für die Kompression erst verspätet erhält (aufgrund der Historischen Synchronisation). Es empfiehlt sich deshalb, ein entsprechendes Delay innerhalb des Kompressions-Interval vorzusehen (mindestens die Dauer des Abgleichintervalls).

Manuelle Historische Synchronisation

Innerhalb des RDB-Konfigurationspanels besteht die Möglichkeit ein eigenes "Historische Synchronisation" Panel zu öffnen, welches einen Überblick über offene oder fehlgeschlagene Synchronisationen gibt. Weiters besteht die Möglichkeit, einen Zeitbereich für einen manuellen Abgleich zu definieren und diesen zu starten.

Warnhinweise

Update von Datenpunkt Elementen

Anders als bei der Neuerstellung von Datenpunkt Elementen werden die Updates der Datenpunkt Elemente (= Änderungen von Alias, Comment & Unit) nicht gebuffert. Die Updates werden vom RDBManager zuerst am aktiv verbundenen DBHost und anschließend am passiven DBHost durchgeführt. Ist der passive Host jedoch nicht erreichbar, gehen die Updates der Datenpunkt Elemente verloren. Um diese verlorenen Updates wiederherzustellen, muss das Update erneut durchgeführt werden.

Alarm-Update

In folgendem Fall kann es zu einem Verlust von Alarm-Updates kommen:

1. Alarm X wird vom RDBManager in DBHost 1 geschrieben

2. Verbindung zwischen DBHost 1 und DBHost 2 bricht ab, ohne das ein Abgleich durchgeführt wurde (d.h. Alarm X ist nur DBHost 1 bekannt)

3. Verbindung zwischen RDBManager und DBHost 1 geht verloren, Verbindung zwischen RDBManager und DBHost 2 wird aufgebaut.

4. RDBManager schickt ein Update für Alarm X an DBHost 2

Das Update des Alarms X wird verworfen, da dieser Alarm dem DBHost 2 nicht bekannt ist. Bei einem später durchgeführten Abgleich wird Alarm X entsprechend an DBHost 2 gesendet, jedoch enthält dieser den Wert der DBHost 1 bekannt war, somit ist das Update des Alarms verloren gegangen. Im Normalfall beschränkt sich der Werteverlust auf das Zeitintervall eines Abgleichs (vgl. sync_intval_len innerhalb der RDB_config.sql Datei).