Einstellungen für den Data Manager
[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.
HINWEIS: Wenn Sie für diesen Config-Eintrag höhere Werte als die Standardwerte setzen,
kann dies zu einem deutlichen Anstieg des Speicherverbrauchs (RAM) durch die WinCC
OA-Laufzeit führen.
[data] maxLinesInQuery
- Typ
- unsigned long
- Default
- 80000
- Wertebereich
- <number of dpe>.. MAX_UINT
Gibt die maximale Anzahl der Zeilen in einer Tabelle an.
HINWEIS: Wenn Sie für diesen Config-Eintrag höhere Werte als die Standardwerte setzen,
kann dies zu einem deutlichen Anstieg des Speicherverbrauchs (RAM) durch die WinCC
OA-Laufzeit führen.
[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.
HINWEIS: Wenn Sie für diesen Config-Eintrag höhere Werte als die Standardwerte setzen,
kann dies zu einem deutlichen Anstieg des Speicherverbrauchs (RAM) durch die WinCC
OA-Laufzeit führen.
[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] waitForRecoveryFlag
- 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.