[data]

[data] alertDpList

Typ: bool
Default: 1
Wertebereich: 0|1

Dient der schnelleren Abfrage von historischen Alarmen bei Verwendung der RAIMA-Alarmdatenbank. Es wird eine interne Liste der in einem Alarmdateisatz vorhandenen DP-Elementen erstellt womit rasch erkannt werden kann, ob ein abgefragtes DP-Element überhaupt in diesem Alarmdateisatz vorkommt.

[data] archiveReqTimeout

Typ: unsigned short
Default: 0
Wertebereich: >= 0

Die Einstellung dient dazu, falls ein Archiv abgestellt wird, laufende Abfragen trotzdem "irgendwann" (d.h. nach max. xxx Sekunden) zu beantworten. Durch den Config-Eintrag definieren Sie, wieviele Sekunden der Data-Manager (=HDB) auf diese Antworten von Archiven (bei dpPeriodRequest(), dpGetAsynch() und dpQuery()) maximal warten soll. Trifft innerhalb diese Periode nicht von allen betroffenen Archiven eine Antwort ein, wird die Anfrage mit Fehler beendet. Es sollte auf dem Defaultwert 0 bleiben (unbeschränkte Wartezeit!). Anderenfalls sind Werte ab 120 [sek] sinnvoll, da Abfragen mitunter länger dauern. z.B. [data] archiveReqTimeout = 120

[data] bgOpenRetryCount

Typ: int
Default: 5
Wertebereich: 0 - 25

Gibt die Anzahl der Wiederholungen, die der DataBG-Manager probiert die Datenbank zu öffnen bevor er stoppt, an.

[data] checkDiskSpace

Typ: bool
Default: 1
Wertebereich: 0|1

Mit diesem Eintrag wird die Festplattenüberwachung ein- und ausgeschaltet. Ein Ausschalten ist dann nötig, wenn im DiskSpaceCheck-Datenpunkt ein zu hoher Wert für das EmergencyKBLimit angegeben wurde und der Data-Manager schon gleich beim Start in den Emergency-Modus wechselt.

[data] checkMemory

Typ: bool
Default: 1
Wertebereich: 0|1

Mit diesem Eintrag wird die Speicherüberwachung ein- und ausgeschaltet. Ein Ausschalten ist dann nötig, wenn im MemoryCheck-Datenpunkt ein zu hoher Wert für das EmergencyKBLimit angegeben wurde und der Data-Manager schon gleich beim Start in den Emergency-Modus wechselt.

[data] checkNetworkBackupPath

Typ: bool
Default: 1
Wertebereich: 0|1

Aktiveren (=1) des Eintrags erlaubt es dem Data-Manager, mittels icmp Ping, zu prüfen ob der konfigurierte Backup-Pfad verfügbar ist. Dies verhindert einen blockierenden Data-Manager wenn die Netzerk-Ressource nicht verfügbar ist. Der Config-Eintrag ist nur unter einem Windows Betriebssystem erforderlich. Der Config Eintrag wird empfohlen, wenn sich der Backup-Pfad für den Data-Manager auf einem Windows-Netzlaufwerk oder freigegebenen Verzeichnis befindet und die Netzwerk-Verbindung zu diesem Netzwerk-Pfad instabil ist.

[data] dataBgName

Typ: string
Default: WCCILdatabg

Gibt den Namen des Data-Background-Managers an. Der angegebene Data-Background-Manager wird automatisch von dem Data-Manager gestartet. Wenn "" angegeben ist, dann wird kein Data-Background-Manager gestartet.

Bei der Verwendung einer reinen Oracle Archivierung ist der DataBG-Manager nicht erforderlich und kann mittels "" deaktivert werden. In diesem Fall kann direkt nach dem Start das Recovery der Datenbank ausgeführt werden, da der Data-Manager bereits im Multi-User-Mode läuft.

In Projekten mit Standardarchivierung muss der Start des DataBg-Managers abgewartet werden, bevor das Recovery möglich ist.

[data] dbTmpDir

Typ: string
Default: OS specific tmp directory

Definiert das temporäre Verzeichnis für Lock-Manager-Dateien der RAIMA-Datenbank. Ein Leerstring "" heisst, dass der Lock-Manager das Defaultverzeichnis verwendet.

[data] DP_AlertDataSet

Typ: string
Default: _AlertDataSet

Legt den Namen des Datenpunktes vom Typ _DataSet fest, der zur Verwaltung der Datensätze von Alarmhistorie verwendet ist.

[data] DP_AlertSaveRestore

Typ: string
Default: _AlertSaveRestore

Legt den Namen des Datenpunktes vom Typ _AlertSaveRestore fest, der zur Verwaltung und beim Einspielen ausgelagerter Daten von Alarmhistorie verwendet ist.

[data] DP_DataBgManager

Typ: string
Default: _DataBgManager
Wertebereich: -

Interner Datenpunktname des DataBg Managers.

[data] DP_DataManager

Typ: string
Default: _DataManager

Interner Datenpunktname des Data Managers.

[data] DP_DataSaveRestore

Typ: string
Default: _DataSaveRestore

Legt den Namen des Datenpunktes vom Typ _DataSaveRestore fest, der zur Verwaltung und beim Einspielen ausgelagerter Daten von Wertehistorie verwendet ist.

[data] DP_DataSet

Typ: string
Default: _DataSet

Legt den Namen des Datenpunktes vom Typ _DataSet fest, der zur Verwaltung der Datensätze von Wertehistorie verwendet ist.

[data] DP_DiskCheck

Typ: string
Default: All DP from type _DiskSpaceCheck
Wertebereich: -

Legt fest, für welche Datenpunkte vom Typ _DiskSpaceCheck eine Festplattenüberwachung erfolgt. Der Eintrag gibt jeweils einen Datenpunktnamen an und kann mehrmals aufgeführt werden. Die Festplattenüberwachung kann mit DP_DiskCheck = "" oder checkDiskSpace = 0 ausgeschaltet werden.

[data] DP_MemoryCheck

Typ: string
Default: _MemoryCheck
Wertebereich: -

Legt den Namen des Datenpunktes vom Typ _MemoryCheck fest, über den die Überwachung des virtuellen Speichers erfolgt. Die Speicherüberwachung kann mit checkMemory = 0 ausgeschalten werden.

[data] DP_RaimaErr

Typ: string
Default: _RaimaErr
Wertebereich: -

Wenn hier ein Datenpunktelement vom Datentyp Integer eingetragen wird, wird der Code des aufgetretenen RAIMA-Fehlers auf dieses Datenpunktelement geschrieben. Wenn ein Problem während der Datenbankreparatur beim Start des Data-Managers auftritt, wird der Wert -1000 auf das DPE geschrieben. Der Wert wird auf dem DPE nicht automatisch gelöscht, ausgenommen bei einem erfolgreichen Start des Data-Managers indem er auf 0 (= kein Fehler) zurückgesetzt wird. Beachtet werden sollte, dass alle wichtigen Fehlercodes negativ sind (z.B. -27). Bei poositiven Fehlercodes handelt es sich um Warnungen. In einem redundanten System wird dem DPE auf dem zweiten System ein "_2" angehängt (d.h. "RaimaErr_2.value" wenn auf dem Config-Eintrag "RaimaErr.value" gesetzt wurde). Das DPE muss in der config.redu mit fwdDP weitergeleitet werden.

[data] DP_RDBArchive

Typ: string
Default: _RDBArchive

Legt den Namen des Datenpunktes vom Typ _RDBArchive fest, der die Einstellungen für die Archivierung unter Verwendung der relationalen Datenbank hält. Siehe auch RDB-Archivierung.

[data] DP_RDBArchiveGroup

Typ: string
Default: _RDBArchiveGroups

Legt den Namen des Datenpunktes vom Typ _RDBArchiveGroups fest, der die Einstellungen zu RDB Archivgruppen hält. Siehe auch Parametrierung der Archivgruppen.

[data] DP_ValueArchiveMedia

Typ: string
Default: _ValueArchiveMedia

Legt den Namen des Datenpunktes vom Typ _ValueArchivMedia fest, der die Einstellungen für den Datentransfer bei Archivsatzwechsel und Auslagerung der Archive hält. Siehe auch History DB.

[data] fileSwitchRoundOff

Typ: unsigned integer
Default: 360
Wertebereich: Seconds

Der Config-Eintrag "fileSwitchRoundOff" kann verwendet werden, um die Zeit aufzurunden, damit die Verzeichnisnamen der Alarmarchive in redundanten Systemen identisch sind. Der Name der Alarmarchive entspricht den Sekunden seit 01.01.1970.

[data] flushTimeForAliasCache

Typ: ushort
Default: 2
Wertebereich: 0..maxshort

Zeit in Sekunden, die zwischen zwei Flush-Vorgängen des Alias-Caches gewartet wird. Höherer Wert = bessere Performance / grösserer Datenverlust bei Systemabsturz.

[data] flushTimeForDpConfigCache

Typ: ushort
Default: 2
Wertebereich: 0..maxshort

Zeit in Sekunden, die zwischen zwei Flush-Vorgängen des Config-Caches gewartet wird. Höherer Wert = bessere Performance / größerer Datenverlust bei Systemabsturz.

[data] ignoreCorruptDB

Typ: bool
Default: 0
Wertebereich: 0|1

Dieser Config-Eintrag legt fest ob der Data-Manager gestartet wird, wenn die Datenbank defekt ist. Wird die Data-Manager Option "-repair" angegeben, wird ein Reparaturversuch der angegebenen Datenbank durchgeführt. Wenn der Reparaturversuch misslingt, startet der Data-Manager nicht. Dieses Verhalten kann durch den Config-Eintrag "ignoreCorruptDB = 1" in der [data]-Sektion übersteuert werden. Wenn dieser Config-Eintrag verwendet wird, startet der Data-Manager auch bei fehlgeschlagener Reparatur. Wird der Eintrag "ignoreCorruptDB = 0" bzw. kein Eintrag verwendet, startet der DM nicht bei defekter DB.

[data] keepLastTimeSmoothedValue

Typ: bool
Default: 0
Wertebereich: 0|1

Mit dem Config-Eintrag keepLastTimeSmoothedValue = 1 kann definiert werden, dass der aktuelle Wert am Ende einer Glättungsperiode archiviert wird wenn der unterschiedlich als der zuletzt archivierte Wert, der die Glättungsperiode gestartet hat, ist. Der Wert wird archiviert erst wenn es eine Wertänderung nach der Glättungsperiode gibt und nicht am Ende der Periode. Diese Funktionalität gilt nur für die zeitabhängige Glättung und Glättungsperioden, die mit dem Archiv-Config konfiguriert wurden, siehe _archive (Archivierung). Defaultmäßig ist diese Funktionalität deaktiviert und es wird kein zusätzlicher Wert archiviert.

[data] lastValBgUpdateCycle

Typ: unsigned integer
Default: 600
Wertebereich: >= 0

Der DataBGManager sendet bei Wertänderungen in der Vergangenheit Messages an den Data-Manager zum Aktualisieren der Letztwerte. Da dies pro DPE geschieht, kann eine erhebliche Belastung des Data-Managers daraus resultieren. Mit diesem Eintrag werden die Anfragen des DataBGManagers gesammelt und nur alle "lastValBgUpdateCycle"-Sekunden blockweise ausgeführt.

[data] lmcType

Typ: string
Default: LMC_IP (UNIX) / LMC_INTERNAL (Windows)
Wertebereich: LMC_INTERNAL, LMC_IP

Bestimmt den Typ des Lock-Managers, der verwendet wird. ACHTUNG: Unter Linux funktioniert der interne Lockmanager nicht prozessübergreifend. Er darf daher nur verwendet werden, wenn sichergestellt ist, dass zu einer bestimmten Zeit immer nur EIN Prozess auf die Datenbank zugreift (also nur der Data-Manager, nur der Ascii-Manager oder nur der DataBG-Manager). Wird beispielsweise die Archivierung von Alarmung mittels RAIMA durchgeführt, darf der interne Lockmanager unter Linux nicht verwendet werden, weil in diesem Fall der DataBG Manager und der Data Manager gleichzeitig auf die RAIMA-DB zugreifen können. Genauso kann dies auch beim Export von Daten über den Ascii-Manager der Fall sein.

[data] lockVATimeout

Typ: int
Default: 600
Wertebereich: 1..7200

Zeit in Sekunden, die der Data-Manager beim Redundanz-Abgleich wartet, bis die Value Archive rückmelden, dass die Archivsätze geschlossen sind.

ACHTUNG!Ändert man den [data] passiveRecoveryTimeout auf einen Wert kleiner als lockVATimeout, kann es dazu führen, dass ein Redu-Projekt nicht startet.

[data] maxAlertRequestCount

Typ: int
Default: 1000000
Wertebereich: >= 0

Definiert die Anzahl der Elemente (= Anzahl Zeilen x Anzahl Spalten), die in einer Query mit Alarmen abgefragt werden. Wird die eingestellte Anzahl überschritten, wird die Query sobald als möglich abgebrochen und ein Fehler zurückgemeldet. Dieser Config-Eintrag gilt für dpQuery() bzw. dpGetPeriod(). Wird der Eintrag auf 0 gesetzt, so gibt es keine Einschränkung.

[data] maxLinesInQuery

Typ: unsigned long
Default: 80000
Wertebereich: <number of dpe>.. MAX_UINT

Gibt die maximale Anzahl der Zeilen in einer Tabelle an.

[data] maxRequestLineCount

Typ: int
Default: 0
Wertebereich: >= 0

Mit "maxRequestLineCount" kann eingestellt werden, wie viele Rückgabezeilen eine Abfrage (dpQuery, dpGetPeriod) liefern darf. Das Überschreiten des Limits führt zu einem Fehler, der im CTRL über getLastError() abgefragt werden kann. Bei Queries werden keine Daten zurückgegeben, bei dpGetPeriod so viele Daten, die bis zum Abbruch gelesen wurden (+ etwas mehr). Zurzeit nur für Wertehistorie und RAIMA einsetzbar. Dieser Eintrag dient als Ergänzung zu mexRequestMemSize, d.h. es muss nur eines der beiden Kriterien erfüllt sein, um abzubrechen. Bei Datenabfragen (keine Alarmdaten) wird dieser Config-Eintrag nur bei Verwendung der RDB-Archivierung berücksichtigt. Default 0: kein Limit.

[data] maxRequestMemSize

Typ: int
Default: 0
Wertebereich: >= 0

Mit dem Config-Eintrag maxRequestMemSize wird angeben , wie viel Hauptspeicher eine Abfrage (dpQuery, dpGetPeriod) verwenden darf. Wird dieser Wert überschritten, bricht die Abfrage mit einem Fehler ab. Zurzeit nur für Wertehistorie und RAIMA einsetzbar. Default 0: kein Limit.

[data] maxUpdateMsgCount

Typ: unsigned
Default: 1000
Wertebereich: >=0

Der Eintrag gibt an, wieviele Identification-ändernde Messages (DP_MSG_MANIP_xxx) der Data puffert. Werden mehr Messages als angegeben gepuffert entfernt der Data Messages aus dem Liste. Wenn sich ein Client zum Data verbindet, versucht der Data, nur Updates aus dieser Liste zu senden. Reicht die Liste nicht aus schickt der Data die gesamte Identification.

[data] maxValueRequestCount

Typ: int
Default: 1000000
Wertebereich: >= 0

Definiert die Anzahl der Elemente (= Anzahl Zeilen x Anzahl Spalten), die in einer Query abgefragt werden. Wird die eingestellte Anzahl überschritten, wird die Query sobald wie möglich abgebrochen und ein Fehler wird ausgegeben. Dieser Config-Eintrag gilt für dpQuery() bzw. dpGetPeriod(). Auch Abfragen an die History DB werden mit diesem Config-Eintrag beschränkt. Wird der Eintrag auf 0 gesetzt, so gibt es keine Einschränkung.

[data] multiUserMode

Typ: bool
Default: 1
Wertebereich: 0|1

Wenn 1, dann wird die Datenbank in Multi User Betrieb geöffnet. Wenn 0, dann in Single User Mode.

[data] numberOfAlertsToBuffer

Typ: short
Default: 500
Wertebereich: 10..500

Maximale Anzahl der Meldungen, die aus der Eingangs-Message-Queue gelesen werden, bis die Meldungen geflusht werden. Die Meldungen werden NICHT nur nach diesem Counter geflusht, sondern es kann zu einem 'impliziten' Flush kommen, wenn z.B. der Puffer voll ist oder wenn der Data-Manager im Moment keine Nachrichten empfängt. Realistische Werte liegen zwischen 10 - 500. Der Wert ist projektabhängig!

[data] numberOfDatapointsToCache

Typ: int
Default: 10
Wertebereich: >= 1

Anzahl der Blöcke, die im Speicher als Cache angelegt werden. Jeder Block reserviert 1 KByte Speicher. Sollte an die Anzahl der archivierenden Werte angepasst sein. Der Wert ist projektabhängig.

[data] numberOfValuesInOneInitMessage

Typ: int
Default: 10
Wertebereich: 1..100

Anzahl der Items, die in einer Initialiserungsnachricht geschickt werden. Größere Werte bedeuten schneller Hochlauf, aber andere Prozesse werden dadurch verlangsamt.

[data] numberOfValuesToBuffer

Typ: short
Default: 500
Wertebereich: 10..500

Maximale Anzahl der Werte, die aus der Eingangs-Message-Queue gelesen werden, bis die Blöcke geflusht werden. Die Blöcke werden NICHT nur nach diesem Counter geflusht, sondern es kann zu einem 'impliziten' Flush kommen, wenn z.B. ein Block voll ist. Realistische Werte liegen zwischen 10 - 500 (je größer numberOfDatapointsToCache, desto größer darf die Resource sein, bis zu 10*numberOfDatapointsToCache). Der Wert ist projektabhängig.

[data] passiveRecoveryTimeout

Typ: unsigned integer
Default: 1800

Die maximale Zeit, die verwendet werden darf, um den Kopiervorgang der Datenbank Dateien abzuschließen.

ACHTUNG!Ändert man das passiveRecoveryTimeout auf einen Wert kleiner als [data] lockVATimeout, kann es dazu führen, dass ein Redu-Projekt nicht startet.

[data] quickStart

Typ: bool
Default: 1
Wertebereich: 0|1

Bestimmt, ob der DataBG Manager am Ende des Projektstarts (0) oder gleich mit dem Data-Manager gestartet wird (1). Erste Methode ist schneller, zweite kompatibler mit dem Originalverhalten. Bei der Verwendung von Quickstart kann kein anderen Manager (ASCII, DataBG) auf die Datenbank zugreifen bevor alle Prozesse vor dem DataBG gestartet wurden. Unter Linux kann der Quickstart Modus deaktivert werden, da hier der Unterschied der RAIMA Performance geringer ist. Ebenfalls kann es, abhängig vom jeweiligen Anwendungsfall, von Vorteil sein auf den Quickstart zu verzichten.

[data] repair

Typ: string
Default: on
Wertebereich: on, off, ignore, last, lastonly, only:dbname

Wird die Data-Manager Option "-repair" angegeben, wird ein Reparaturversuch der angegebenen Datenbank durchgeführt. Wenn der Reparaturversuch mißlingt, startet der Data-Manager nicht. Dieses Verhalten kann durch den Config-Eintrag "ignoreCorruptDB = 1" in der [data]-Sektion übersteuert werden. Wenn dieser Config-Eintrag verwendet wird, startet der Data-Manager auch bei fehlgeschlagener Reparatur. Wurde keine "-repair" Option angegeben, ermittelt der Data-Manager selbstständig (Erkennung, ob er zuvor ordnungsgemäß heruntergefahren wurde), ob Reparaturen duchgeführt werden sollten. Dabei wird die Alert-Datenbank nicht automatisch mitrepariert. Mode der Datenbankreparatur:

on = prüfe und repariere die DB, wenn die Datei 'dbase.status' existiert
off = wenn die Datei 'dbase.stat' existiert, dann beende DM
ignore = ignoriere die Datei 'dbase.status' und starte DM
last = repariere nur zuletzt geänderte Datensätze, wenn 'dbase.status' existiert
lastonly = repariere nur zuletzt geänderte Datensätze und beende
only:dbname = repariere nur den angegebenen Datensatz und beende

[data] repairDchain

Typ: bool
Default: 1
Wertebereich: 0|1

Legt fest ob das RAIMA Utility "dchain" für defekte Datenbanken gestartet werden soll. Datensätze die in der RAIMA gelöscht werden sollen sind zu Beginn nur als gelöscht markiert. Diese als gelöscht markierten Einträge werden in die dchain (delete chain) aufgenommen. Wird der Data-Manager unerwartet beendet, kann es sein, dass die tatsächlich gelöschten bzw. als gelöscht markierten Einträge nicht mit der dchain übereinstimmen. Durch diesen Config-Eintrag wird das durch das "dchain" Utility repariert.

[data] sendAlertsToRAIMA

Typ: bool
Default: 0
Wertebereich: 0|1

Setzt useRDBArchive = 1 voraus. Bei einem Wert von 1 werden Alarme sowohl in die RAIMA als auch in die RDB geschrieben. Es erfolgt jedoch kein Abgleich, darum kann es unter Umständen zu Lücken in der Archivierung kommen. Ein Wert von 0 gibt an, dass die Werte nur in die RDB geschrieben werden.

[data] sendUDAGNullValues

Typ: bool
Default: 1
Wertebereich: 0|1

Mit diesem Config-Eintrag geben Sie an ob der Data-Manager eine Null (sendUDAGNullValues =1) oder den letzten Wert (sendUDAGNullValues =0) an die RDB-Datenbank bei einer Änderung von einem einzelnen Wert senden soll. Das bedeutet, dass wenn es mehrere Datenpunkt-Elemente gibt und der Wert von nur einem Element geändert wird, wird der Wert der anderen Elemente auf den Letztwert oder auf 0 gesetzt.

[data] smoothBit

Typ: string
Wertebereich: Userbit 1.. Userbit 32, _active, _exp_default, _aut_default, _out_prange, _out_range, _exp_inv, _aut_inv, _online_bad, _default_bad, _from_GI, _from_SI, _per_active, _stime_inv, _uncertain

Dieser Eintrag gibt an, welche Statusbits in einer Glättung (Low-Level Alt/Neu-Vergleich vor dem Archivieren) berücksichtigt werden sollen. Ändert sich eines dieser Userbits, wird der Wert nicht geglättet, auch wenn sich der Originalwert nicht geändert hat. Dieser Eintrag muss für jedes Userbit, das berücksichtigt werden soll, einmal vorhanden sein. Mögliche Werte für die Userbits sind:


smoothBit = "_active"
smoothBit = "_exp_default"
smoothBit = "_aut_default"
smoothBit = "_out_prange"
smoothBit = "_out_range"
smoothBit = "_exp_inv"
smoothBit = "_aut_inv"
smoothBit = "_online_bad"
smoothBit = "_default_bad"
smoothBit = "_from_GI"
smoothBit = "_from_SI"
smoothBit = "_per_active"
smoothBit = "_stime_inv"
smoothBit = "_uncertain"
smoothBit = "Userbit 1"
smoothBit = "Userbit 2"
smoothBit = "Userbit 3"
smoothBit = "Userbit 4"
smoothBit = "Userbit 5"
...
smoothBit = "Userbit 30"
smoothBit = "Userbit 31"
smoothBit = "Userbit 32"

[data] startTimeVACorrection

Typ: bool
Default: 1
Wertebereich: 0|1

Mit dem Config-Eintrag startTimeVACorrection = 1 ändert Data-Manager Letztwertzeit bei Startmessage an Valarch-Manager auf Startzeit des aktuellen Archivsatzes, wenn erstere Zeit davor liegt. Mit startTimeVACorrection = 0 ist diese Funktionalität deaktiviert.

Anmerkung: Es ist nicht empfohlen diese Funktionalität deaktivieren.

[data] statFctInitInterval

Typ: unsigned integer
Default: 7200
Wertebereich: 0..7200

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 Letzwerte mit einem Zeitstempel nach 14:30 an ein neu startendes Archiv. Für statistische Datenpunkte werden aber alle Letzwerte 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.

[data] transactionLogging

Typ: bool
Default: 0
Wertebereich: 0|1

Da Daten nur blockweise in die Raima-Datenbank geschrieben werden, kann bei Systemabstürzen ein noch nicht gespeicherter Block verloren gehen und der Datenbestand dadurch beschädigt werden. Durch transactionLogging lässt sich eine dauerhafte Beeinträchtigung der Datenbank jedoch verhindern, da eine (Data-interne) Transaktion erst beendet wird, wenn die Daten auch auf die Disk geschrieben wurden. Wenn transactionLogging aktiviert wurde (= 1), ist keine Datenbankreparatur erforderlich. Die Angabe von transactionLogging hat Vorrang vor den Werten in dem internen DataManager-DPs. Eingeschaltetes transactionLogging hat zur Folge, dass der Data-Manager langsamer arbeitet als ohne.

Um Transaction-Logging zu deaktivieren, muss der Config-Eintrag explizit auf 0 gesetzt werden. Transaction-Logging kann nicht durch das Löschen des Eintrags deaktiviert werden.

[data] useAlertDpListCache

Typ: bool
Default: 1
Wertebereich: 0|1

Erhöht Leseperformance für historische Alarme (RAIMA DB) indem eine Index-Datenbank (adplist.db,adplist.key) in jedem alertset-Verzeichnis erstellt wird, um zu erfassen welche Alarme für den angegebenen DP in diesem Alarm-Datensatz gespeichert werden. Der Eintrag wird von den Data- und DataBG-Managern verwendet.

[data] useCurrentTimeForStartValue

Typ: bool
Default: 0
Wertebereich: 0|1

Mithilfe dieses Config-Eintrages kann erzwungen werden, dass ein Datenpunktelementwert mit dem aktuellen Zeitstempel beim Setzen des _archive.._archive Konfigs zu einem bestimmten Zeitpunkt (jedoch nicht beim Hochlauf) in die Datenbank geschrieben wird (useCurrentTimeForStartValue = 1).

[data] waitForRecFlag

Typ: int
Default: 1800 sec
Wertebereich: 0-MAXINT, negative values are not allowed

Der Eintrag definiet die Wartezeit auf die Verbindung zum anderen Redu-Partner beim Hochlauf beim passiven Recovery. Das ist die Zeit, in der sich der Redu-Partner verbinden muss. Wenn sich der Partner nicht verbindet und die Zeit abläuft, startet der Rechner neu (aktiv).

[data] waitTimeForBGStart

Typ: unsigned integer
Default: 60
Wertebereich: >= 0

Beschleunigt den Projektstart, indem der DataBG nicht gleich gestartet wird. Der Config-Eintrag definiert wie lange nach der Initialisierung der Manager gewartet wird bis der DataBGManager gestartet wird. Der DataBG unterstützt den Data-Manager bei nicht zeitkritischen Operationen. Die Zeit wird in Sekunden angegeben. Der Defaultwert ist 60. Bei fehlerhafter Eingabe wird der Defaultwert verwendet.