Mögliche Config-Einträge bei der RDB-Archivierung

• 0 = RDB Archiv-Manager ist nicht funktionsfähig
• 1 = RDB Archiv-Manager wird aktiviert (Schreiben/Lesen zur RDB).

0 - 600

Wenn Alarme, bei denen der Voralarm in einem bereits ausgelagerten Archivsatz vorhanden ist, auftreten, versucht die Datenbank fünf Minuten lang den alten Alarm zu "erreichen". Dabei werden andere Alarme möglicherweise zurückgehalten und nicht in die Datenbank geschrieben. Um das zu verhindern und um die Zeit auf z.B. 30 Sekunden zu reduzieren, verwenden Sie [ValueArchiveRDB] "alertUpdateDelay = 30".

Auswahl des Speichermodus, in welchem die Datenblöcke gepuffert werden, bevor sie in die Datenbank geschrieben werden.

• bufferToDisk = 0

  Ohne BufferToDisk: Im Falle eines Ausfalls der Verbindung zur RDB, werden Blöcke im Hauptspeicher gepuffert und dann in die DB geschrieben.

  Anmerkung: Daten gehen verloren, wenn der Speicherplatz überschritten wird!

• bufferToDisk = 1

  BufferToDiskMin (Default)

• bufferToDisk = 2

  BufferToDiskMax

Absoluter Pfad zum Verzeichnis, in welchem die Daten bei bufferToDisk = 1|2 auf der Festplatte gepuffert werden.

Bei Verwendung des Default-Speicherortes, wird das Verzeichnis buffer automatisch angelegt.

Bei Verwendung eines individuellen Speicherortes ist der absolute Pfad einzugeben, z.B.: "D:\BufferToDisk\Files"

Datenbankpasswort

Zeitliche Verzögerung der Initialisierung des RDB nach Datenbankstart in Sekunden.

Wenn die Datenbank gestoppt und wieder gestartet wird, kann es vorkommen, dass zwischen RDB und der Datenbank zwar eine gültige Verbindung hergestellt werden kann, jedoch ist die Datenbank zu diesem Zeitpunkt noch nicht vollständig hochgefahren. Mit dem Config-Eintrag "delayAfterDBRestart" wartet RDB die eingestellte Zeit ab, bevor er die Verbindungen initialisiert und somit aktiv die Werte in die Datenbank schreibt. Per Default ist dieser Eintrag auf 30 Sekunden eingestellt.

Bei jedem Verbindungsverlust zur Datenbank, und wenn eine Verbindung über die internen Datenpunktelemente "closeDBConnection" und "openDBConnection" geschlossen bzw. geöffnet wird, kommt diese Verzögerung zum Einsatz. Beim Starten des RDB-Managers wird diese Verzögerung jedoch nicht angewendet.

Gibt an, wie die lesenden Datenbankabfragen erfolgen:

• 0 = Datenpunktnamen oder DPE-Namen; diese Variante bringt zwar Performanceeinbußen, aber dadurch kann man aus einem anderen WinCC OA Projekt auf die Daten in der Oracle DB zugreifen.
• 1 = Id's (schneller)

Gibt an, dass ein Flag gesetzt wird, wenn die RDB die Verbindung zu der Datenbank verliert und versucht diese wieder aufzubauen. Dadurch (das gesetzte Flag) weiß der Benutzer, dass die Verbindung verloren ist. Das Flag wird nach lostConnectionReportInterval (Sekunden) gesetzt.

Definiert, nach wie vielen Sekunden der Benutzer informiert wird, wenn der RDB-Manager die Verbindung zur Datenbank verliert und versucht diese wieder aufzubauen.

Anzahl von Threads und auch Verbindungen zu der Datenbank, die der RDB-Manager verwendet um parallel Operationen in der Datenbank durchzuführen (Abfragen).

Wenn queryRDBdirect = 1 verwendet wird, wird die Lese-Verbindung für den direkten

Datenbank-Zugriff nicht durch diese Einstellung beeinflusst.

(maxRequestThreads kann in diesem Fall auf 0 gesetzt werden).

Der Config-Eintrag openConnOnDemand reduziert die Anzahl der RDB-Manager-Connections zu der relationalen Datenbank. Es werden die Read-, Info- und Delete-Connections nur bei Bedarf geöffnet und nach Abschluss der jeweiligen Operation wieder geschlossen.

Die Performance ist schlechter als wenn alle Verbindungen die ganze Zeit offen wären (openConnOnDemand=0).

Die Anzahl von Lese-Verbindung wird durch diese Einstellung nicht beeinflusst (verwenden Sie stattdessen maxRequestThreads).

Der Eintrag openConnOnDemand ist für große verteilte Systeme notwendig, wenn viele RDB-Manager in dieselbe Datenbank schreiben. Andernfalls benötigt Oracle zu viel Speicher, weil zu viele Connections gleichzeitig offen sind.

Für Updates wird eine zusätzliche DB-Verbindung geöffnet. Sie wird nur dann verwendet wenn "openConnOnDemand" = 1 (siehe oberhalb) .

Die Update-Connection wird wieder nach updateConnCloseDelay-Sekunden nach ihrer letzten Verwendung geschlossen. Default = 180 (=3 Minuten).

Gibt an, ob die Funktion dpGetPeriod() über die Grenzen des abgefragten Zeitbereichs (Parameter Count der dpGetPeriod-Funktion) abfragen soll oder nicht. Wenn der Count-Parameter der Funktion größer als 0 ist, werden auch Werte außerhalb (das heißt vor und nach) dem abgefragten Zeitbereich abgefragt. Das könnte mitunter eine längere Zeit in Anspruch nehmen. queryOverBounds = 1 bedeutet, dass Werte über die Grenzen abgefragt werden. Dies funktioniert in Verbindung mit queryRDBdirect = 1 nur für RDB-Abfragen auf ein einzelnes Datenpunktelement.

Bei queryOverBounds = 0 werden nur Werte im Intervall abgefragt. Das beschleunigt den Prozess.

Bricht Datenbank-Abfragen nach queryTimeout Sekunden ab.

0 bedeutet kein Timeout.

Mit dem Config-Eintrag queryFunction = 1 wird eine Datenbank-Funktion anstatt einer Abfrage für dpGetPeriod() verwendet. Damit fallen die Einschränkungen, wie Anzahl der Tabellen und Länge des SQL-Statements, weg. Mit queryFunction = 0 wird wie bisher eine Abfrage verwendet.

Der Eintrag kann in ValueArchiveRDB-, und UI-Sektionen verwendet werden.

Der Config Eintrag erlaubt es festzulegen, ob eine Archivgruppe auf eine andere Archivgruppe gemappt wird, um so das Anlegen zusätzlicher Archivgruppen zu verhindern und eine bessere Performance zu erzielen.

Beispiel

redirectArcGroup = VA10 :QPS

Die Archivgruppe VA10 wird hierbei auf die Archivgruppe QPS weiter geleitet.

redirectArcGroup = VA* :EVENT

Die Archivgruppen, welche mit "VA" beginnen werden auf die Archivgruppe Event weiter geleitet.

• sendMaxTS = 1

  Der RDB-Manager holt sich den größten Zeitstempel aus der Datenbank und führt mit dem Data-Manager einen Datenabgleich aus. D.h. der Data-Manager sendet dem RDB-Manager alle Wertänderungen, die neuer sind als der Zeitstempel aus der Datenbank.

• sendMaxTS = 0

  Der RDB holt den Zeitstempel nicht aus der Datenbank und es erfolgt kein Datenabgleich. Das verbessert die Hochlaufgeschwindigkeit, aber die letzte Wertänderung bis zum RDB-Start ist nicht in der Oracle-Datenbank.

• sendMaxTS = 2

  Der letzte (zuletzt gespeicherte) Zeitstempel pro System wird in der SYSTEMS-Tabelle gespeichert und mit jedem Block der in die Datenbank geschrieben wird, aktualisiert. Beim Start des RDB-Managers wird der Zeitstempel aus der Tabelle gelesen. Das ist eine schnelle Leseoperation mit der Sie den neuesten Zeitstempel des Systems abfragen können.

• 1 = Schreibt Daten in das RDB-Archiv über die OCI Oracle Call-Schnittstelle (OCCI). Um OCI Bulk-Writing zu aktivieren, setzen Sie diesen Eintrag auf 1. Dies verbessert die Performance.
• 0 = OCI wird nicht verwenden.

APM und die APM-Einträge werden verwendet um aus einer zweiten RDB Daten in ein WinCC OA Projekt abzufragen. Bei der Abfrage wird der Datenpunkt-Name und nicht die ID verwendet. Für die APM Abfrage-Funktionen siehe Kapitel Direkte Lesefunktionen

APMDbUser ist der Datenbank-Benutzer.

Gibt an, über welchen Weg die lesenden Datenbankabfragen erfolgen:

0 = Standard- CTRL- Lesefunktionen (dpGet...()) über den WinCC OA Event-Manager und den WinCC OA Data-Manager.

1 = Die Standard CTRL-Lesefunktionen (dpGet...()) werden umgeleitet auf die direkten RDB-Lesefunktionen in der Control-Erweiterung "CtrlRDBArchive.dll".

Beachten Sie, dass auch die beiden notwendigen CTRL DLLs geladen werden müssen, um die direkten RDB-Lesefunktionen zu verwenden:

CtrlDLL="CtrlRDBArchive"

CtrlDLL="CtrlRDBCompr"

Definiert (wenn RDB verwendet wird) wie lange nachdem ein Archiv abgeschlossen wurde, zurückliegende Wertänderungen von statischen Datenpunktelementen (erkennbar an: Zeitstempel msec = 0) noch an das Archiv gesendet werden, wenn das Archiv erneut gestartet wurde.

Wenn z.B. ein Archiv um 14:30, sendet normalerweise der Data-Manager alle Letztwerte

mit einem Zeitstempel nach 14:30 an ein neu startendes Archiv. Für statistische Datenpunkte

werden aber alle Letztwerte mit Zeitstempel nach 12:30 (7200) gesendet und dadurch

an das alte Archiv gesendet (da statistische Funktionen zeitversetzt berechnet werden

und ansonsten der zuletzt errechnete Wert verloren gehen könnte).

Maximalwert: Es werden höchstens 2 Stunden zurückliegende Werte an das abgeschlossene

Archiv gesendet.