Details zur Datenpufferung

Schreibzugriff

In den Grundlagen zur Datenpufferung wurde bereits darauf hingewiesen, dass Daten gepuffert werden können (Schreibzugriff), jedoch bei einem Verbindungsverlust zur DB aus dem Puffer nicht ausgelesen werden können (Lesezugriff). Erst wenn die DB-Verbindung wieder hergestellt wird, können die gepufferten Daten in die DB geschrieben und somit auch ausgelesen werden.

Limit für Datenpufferung

Damit bei einem länger anhaltenden DB-Verbindungsverlust die Kapazitäten des Hauptspeichers und der lokalen Festplatte nicht komplett mit gepufferten Daten gefüllt werden und neue Daten dadurch verloren gehen, ist es erforderlich, ein Limit in der RDB Parametrierung in der Option "Blockanzahl auf HDD" festzulegen (MB-, GB-, oder Prozent-Angaben).

Aktivierung der Datenpufferung

Eine Datenpufferung kann über das interne Datenpunktelement stopWriteToDB vom Typ _RDBArchive aktiviert werden.

stopWriteToDB = 1

Die Datenblöcke werden nicht in die Datenbank geschrieben, sondern werden im Speicher bzw. auf der Festplatte gepuffert. Das heißt, dass das gleiche Verhalten simuliert wird, als ob die Verbindung zur Datenbank unterbrochen wäre. Auch nach einem Aufbau der Verbindung zur Datenbank im Falle einer Verbindungsunterbrechung werden die Datenblöcke weiterhin gepuffert und nicht wieder in die Datenbank geschrieben.

stopWriteToDB = 0

Defaultwert. Die Daten werden direkt in die Datenbank geschrieben, falls eine Verbindung vorhanden ist. Wenn der Wert von stopWriteToDB vorher 1 war und dieser jetzt auf 0 geändert wurde, werden die vorher gepufferten Daten vom RDB-Manager wieder in die Datenbank geschrieben.

Im redundanten Betrieb sollte das Datenpunktelement auf beiden Rechnern gleich gesetzt sein, damit diese bei einer Aktiv-/Passiv-Umschaltung das richtige Verhalten aufweisen. Das bedeutet, dass, wenn am aktiven Rechner der Wert auf 1 gesetzt wurde und am passiven auf 0, dann schreibt der passive Rechner nach einer Umschaltung automatisch die gepufferten Datenblöcke in die Datenbank.

Fehlermeldungen

Wenn beim Schreiben der Daten Fehler auftreten, werden diese auf den Datenpunkt error.errNum geschrieben. Wenn die RDB z.B. versucht das Bufferfile 99.RDB392 zu schreiben und die Datei nicht erstellt werden kann, wird die Fehlermeldung "Fehler beim Schreiben des Pufferblocks - Datei konnte nicht angelegt werden" auf den Datenpunkt geschrieben. Wenn die nächste Datei erfolgreich auf die Platte geschrieben werden kann, wird der obiger Fehler wieder gelöscht. Für detaillierte Informationen über die Fehlercodes, siehe RDBArchive.error.errNum.

Starten des RDB-Managers mit Pufferung ohne Verbindung zur Datenbank

In der folgenden Anleitung wird beschrieben, wie ein RDB-Manager mit automatischer Datenpufferung gestartet werden kann, wenn die Datenbank beim Start des WinCC OA Projektes noch nicht verfügbar ist, da der Oracle-Server noch nicht hochgefahren ist.

Setzen Sie vor dem Start des RDB-Managers beide interne Datenpunktelemente:

  • _RDBArchive.connection.closeDBConnection = 1

  • _RDBArchive.connection.openDBConnection = 0

Wenn die DB gestartet ist, darf nur noch einer der beiden internen Datenpunktelemente gesetzt werden. Der zweite zeigt dann den Status an.

Mit den folgenden Schritten wird erreicht, dass beim Projektstart immer der Wert 1 bzw. 0 auf diesen internen Datenpunktelementen gesetzt ist.

  1. Öffnen Sie den WinCC OA PARA.

  2. Haken Sie die Checkbox "Interne Datenpunkte" an.

  3. Wählen Sie das Datenpunktelement _RDBArchive.dbConnection.closeDBConnection aus.

  4. Setzen Sie den Wert auf "1".

  5. Klicken Sie auf "Übernehmen".

  6. Deaktivieren Sie das Bit "Letztwert".

  7. Klicken Sie erneut auf "Übernehmen".

  1. Wählen Sie das Datenpunktelement _RDBArchive.dbConnection.openDBConnection aus.

  2. Setzen Sie den Wert auf "0". Dadurch wird die Verbindung zur Datenbank nicht sofort wieder aufgebaut.

  3. Klicken Sie auf "Übernehmen".

  4. Deaktivieren Sie das Bit "Letztwert".

  5. Klicken Sie erneut auf "Übernehmen".

  6. Falls es sich um ein redundantes WinCC OA Projekt handelt, überprüfen Sie auf dem passiven Rechner, ob die gesetzten Werte übernommen wurden.

  1. Wählen Sie das Datenpunktelement _RDBArchive_2.dbConnection.closeDBConnection aus.

  2. Setzen Sie den Wert auf "1".

  3. Klicken Sie auf "Übernehmen".

  4. Deaktivieren Sie das Bit "Letztwert".

  5. Klicken Sie erneut auf "Übernehmen".

  1. Wählen Sie das Datenpunktelement _RDBArchive_2.dbConnection.openDBConnection aus.

  2. Setzen Sie den Wert auf "0". Dadurch wird die Verbindung zur Datenbank nicht sofort wieder aufgebaut.

  3. Klicken Sie auf "Übernehmen".

  4. Deaktivieren Sie das Bit "Letztwert".

  5. Klicken Sie erneut auf "Übernehmen".

  6. Falls es sich um ein redundantes WinCC OA Projekt handelt, überprüfen Sie auf dem passiven Rechner, ob die gesetzten Werte übernommen wurden.

Das Aktivieren der Datenbankverbindung kann nach einer eingestellten Verzögerungszeit erfolgen. Verwenden Sie den Befehl tnsping <connect_identifier>, um zu ermitteln, ob die Oracle-Datenbank vollständig hochgelaufen ist. Rufen Sie dazu den tnsping Befehl in einer system() Funktion in einem CTRL-Skript auf.

Beispiel

main()
{
  string out;
  out = system("tnsping EITST077_DB11g");
  DebugN(out);
}

Die Ausgabe erfolgt im WinCC OA Log-Viewer.

Wenn die Verbindung laut tnsping erfolgreich aufgebaut werden konnte, sollte dennoch ca. 3 Minuten gewartet werden, bis der Oracle-Server vollständig hochgefahren ist. Danach kann die Verbindung wieder geöffnet werden:

  • Setzen des Datenpunktelementes _RDBArchive.dbConnection.openDBConnection auf 1 für den Host1.

  • Setzen des Datenpunktelementes _RDBArchive_2.dbConnection.openDBConnection auf 1 für den Host2, falls das Projekt redundant ist.