Details zur History DB

Konfiguration der Wertarchivierung

Die historische Archivierung von Wertänderungen wird wie bisher durch die Konfigs _archive durchgeführt (siehe _archive Konfigs).

Hinweis

Eine Archivierung können Sie nicht nur auf Blattebene der DP-Struktur, sondern an jedem Knoten einstellen. Damit werden auch alle Elemente unterhalb des Knotens automatisch archiviert.

archiveReqTimeout

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.

[data]

archiveReqTimeout = 120

-report 11

Mit dieser Kommandozeilenoption erhalten Sie Informationen, wieviele Abfragen (Queries) angefordert werden, und in welchen Archiv die einzelnen Datenpunkte gespeichert werden, Datenpunktname, Datenpunktnummer und die Zeitliste. Allgemeine Informationen zur HDB erhalten Sie mit -report all. Beachten Sie, dass diese Kommandozeilenoption beim Data-Manager aktiviert werden muss.

Start / Stop des Archivprozesses

Die Archivprozesse werden in der Console gestartet und gestoppt. Dabei wird jeweils die Archivnummer als Kommandozeilenparameter ("-num x") mitgegeben. Das Archiv meldet sich dann beim DM an und erhält von dort die notwendigen Konfigurationsdaten (z.B. zugeordnetes Verzeichnis usw.). Der Prozessname in der Console ist WCCOAvalarch (siehe Archivierung starten).

Da Teile der Archivkonfigurationsdaten auch im Archiv selbst abgelegt sind, erfolgt beim Start ein Gegencheck mit den im jeweiligen Archiv-DP gespeicherten Werten. Bei Abweichungen wird so vorgegangen, als ob eine Archivparameter-Änderung durch den Benutzer gemacht worden wäre. Details zur Behandlung von solchen Differenzen werden bei den einzelnen Archivparametern näher behandelt.

Ist kein interner Archiv-DP beim Starten eines Archivs vorhanden, beendet die Historienebene das Archiv wieder. Alle Archivparameter, welche mit einem dpSet() übertragen werden, werden auch gemeinsam im Archiv geändert.

Archivname und -nummer

Die Zuordnung Archivname/Archivnummer erfolgt über das Archiv- Datenpunktelement (_ValueArchive_x.general.arName). Derzeit sind die Datenpunktnamen für die internen DPs auf _ValueArchive_x vorgegeben, wobei x die Archivnummer darstellt. Für Redundante Projekte existiert für jedes Archiv ein zweiter interner DP, dessen Name mit "_<num>_2" endet. Die 2 bezeichnet die Redundanz, die andere Ziffer die Archivnummer.

Hinweis

Es wird empfohlen, dass Sie Ihre Einstellungen für Datenpunkte über die Panels vornehmen.

Außerdem wird im internen Datenpunkt des Data-Managers ("_DataManager") ein neues Element "UseValueArchive" vom Typ bool eingeführt, welches anzeigt, ob im Moment die Historiendatenbank verwendet wird. Der Wert dieses Elementes leitet sich vom entsprechenden Eintrag in der Config-Datei (s.o.) ab. Zum Neuanlegen eines Archivs wird ein neuer Archiv-DP angelegt und ein Eintrag in der Prozessliste der Console muss erfolgen (erfolgt nicht automatisch). Der Wert kann nur gelesen und nicht verändert werden.

Zusätzlich muss das Element im internen Archiv-DPE (_ValueArchive.general.createArchive) gesetzt sein, damit das Archiv das Neuanlegen des ersten Archivsatzes durchführt. Das Starten des zugehörigen Archivs erfolgt ebenfalls nicht automatisch.

Das Löschen eines Archivs besteht im Setzen des Archiv-DP-Elements "state" (s. unten) auf den Status gelöscht und dem Austragen des Archivprozesses aus der Prozessliste der Console (erfolgt nicht automatisch). Starten Sie ein Archiv mit Status "gelöscht", so wird es sofort wieder beendet. Außerdem sind alle DPE, die diesem Archiv zugeordnet sind, auf ein anderes Archiv umzustellen oder die Archivierung ist zu deaktivieren. Dies erfolgt nicht automatisch. Falls ein DPE einem gelöschten Archiv zugeordnet ist, wird es anschließend im Default-Archiv (Archiv 0) abgelegt. Alle historischen Daten der DPEs des gelöschten Archivs gehen verloren. Die Archivdateien werden nicht automatisch gelöscht.

Überwachung und Steuerung der Archivprozesse

Einstellen der Archivparameter

Die Archivparameter werden als Elemente des Archivdatenpunktes (_ValueArchive) verwaltet. Dabei gibt es reine Parameter und Aktionen. Während die Parameter nur dem Archiv mitgeteilt werden, lösen Aktionen Vorgänge im Archivprozess aus, welche über andere DPEs des Archivdatenpunktes rückgemeldet werden. In diesem Kapitel werden die "einfachen" Archivparameter beschrieben.

Die <DPE>.Get- und <DPE>.Set-Elemente werden für Parameter verwendet, welche im Archiv nicht sofort geändert werden. In <DPE>.Set wird eine gewünschte Änderung eingetragen, in <DPE>.Get wird der jeweils aktuelle Stand des Archivs angezeigt.

Die Zeitangaben zur Auslösung verschiedener Ereignisse sind als Referenzen auf einen _TimedFunc-Datenpunkttyp realisiert. Ist zu einem Prozess noch kein DP angelegt und parametriert, erfolgt eine Fehlermeldung.

Tabelle: Teile des DP _ValueArchive

Anmerkungen:

1. nur beim Archiv anlegen einstellbar, sonst read-only

2. read-only

3. ab nächstem Archivstart aktiv, read-only

4. ab nächstem Archivsatzwechsel aktiv, read-only

Archivsatzwechsel/-komprimierung/-löschung

Archivsatzwechsel können automatisiert (über Archivparameter, siehe voriges Kapitel) und /oder manuell ausgelöst werden. Für letztere Methode dient das _ValueArchive_X.action.fileSwitch.start-DPE des jeweiligen Archiv-DPs. Über _ValueArchive_X.action.fileSwitch.progress- DPE wird der aktuelle Status des Archivsatzwechsels angezeigt. Das gleiche gilt für die Vorgänge Komprimierung und Löschung von Archivsätzen. Bei manuellem Auslösen der letztgenannten Vorgänge sind immer der oder die ältesten Archivsätze betroffen (Ausnahme: bei Steuerung über die Konfigurationsoberfläche [..progress=2] können auch die betroffenen Archivsätze direkt spezifiziert werden, siehe Kapitel 5). Beim Löschen von Archivsätzen ist neben der Angabe der Anzahl der zu behaltendenen Archivsätze auch die Angabe einer Zeitperiode (im interval-Teil des removeTime-Elementes) möglich. Ein Wert von 0 (als interval oder count) bedeutet, dass diese Art der Spezifikation nicht verwendet werden soll, werden beide Parameter angegeben, wird zuerst der interval- und anschließend der count-Parameter berücksichtigt. Die in diesem Kapitel besprochenen Methoden werden alle autark vom Archiv selbst durchgeführt bzw. können mit dem .start-DP-Element manuell ausgelöst werden.

Durch Setzen von maxFillPct auf -1 kann ein automatischer Archivsatzwechsel bei Erreichen der max. Werteanzahl unterbunden werden. In diesem Fall können dadurch auch Werte verloren gehen. Im errDp-DPE wird angezeigt, welcher DPE das Vollwerden eines Archivsatzes ausgelöst hat. Zusätzlich wird in diesem Fall das errBit gesetzt, um eine Meldebehandlung zu ermöglichen. Es können für die Kompression, Sicherung und Löschung maximal 9999 Dateien pro Archivsatz parametriert werden.

Der Parameter fileswitchRoundOff bestimmt, wieviele Sekunden nach dem Eintreten eines Archivsatzwechsel-Ereignisses die Umschaltung der Schreibvorgänge tatsächlich erfolgt. Dies dient dazu, bei redundanten Systemen eine gleiche Benennung der Archivdateien zu erreichen und die Umschaltzeitpunkte zu synchronisieren.

Berücksichtigen Sie, dass ein passender Wert für das Element setMgmt.fileSwitch.switchRoundOff gesetzt wird (Defaultwert 30 Sekunden). Wenn ein manueller oder zeitgesteuerter Archivsatzwechsel durchgeführt wird und während der Periode zwischen Wechsel und switchRoundOff-Sekunden später das vorige Archiv voll wird, wird kein neuer Archivsatz erstellt. In diesem Fall können Werte verloren gehen. Beachten Sie weiters, dass manuell oder zeitgesteuerte Archivsatzwechsel nicht später als mit switchRoundOff definiert, erfolgen sollen, da sonst verschiedene Archivsatz-Namen auf den redundanten System erfolgen können.

In redundanten Systemen werden zeitgesteuerte Archivsatzwechsel während der Datei-Synchronisation unterdrückt. Archivsatzwechsel, die während des Backup-Prozesses durchgeführt werden sollen, werden nach der Sicherung durchgeführt (mit Original-Zeitstempel)

Beachten Sie, dass zeitgesteuerte Archivsatzwechsel auf dem aktiven System, die nach der Redu-Datei Synchronisation und bevor das entsprechende Archiv auf dem passiven System gestartet, wurde, verschiedene Archivsatz-Dateinamen verursachen.

Die Operation fileSwitch kann nur vom Archiv oder durch manuelles Setzen des start-Elementes auf 1 aktiviert werden. Die Operationen fileCompression, fileMerge und fileDeletion können vom Archiv selbst, manuell durch Setzen des start-Elementes auf 1 und über die Konfigurationsoberfläche (siehe Datenarchivierung) aktiviert werden. Die Operation fileRestore kann nur über die Konfigurationsoberfläche aktiviert werden.

Sichern/Auslagern/Löschen

Die hier besprochenen Methoden arbeiten mit einer Kooperation von Konfigurationsoberfläche und Historienebene. Die Historienebene hat dabei zu prüfen, ob der Vorgang im Moment durchgeführt werden kann. Falls nicht, wird ein Fehlercode gesetzt, statt eine Dateiliste zurückgeliefert.

Beim Starten des Archivs werden die Elemente action.*.progress von der Historien-DB auf 0 gesetzt (Ausnahme: fileBackup.progress, damit eine begonnene Sicherung weitergeführt werden kann). Beim Starten der Konfigurationsoberfläche werden alle Status (..progress) zurückgesetzt, falls der Status > 0 war, wird die Operation frisch angestoßen (Wiederholung).

Online-Sicherung

Die Online-Sicherung dient im Gegensatz zum Auslagern, der Sicherung aller Dateien eines Archivs. Dieser Vorgang wird vom Archiv nicht selbst durchgeführt. Das Archiv wird nur veranlasst, für eine möglichst kurze Zeit, alle Dateien zu schließen. Eine extern angestoßene Sicherung, die nicht Teil des Archivprozesses oder der Historienebene ist, kann dann diese Dateien sichern. Es wird zwischen dem aktuellen Archivsatz und geschlossenen Archivsätzen unterschieden, d.h. diese können getrennt angefordert werden. Aus dem Grund ist die Zeit, die der aktuelle Archivsatz nicht verwendet werden kann, zu minimieren. In action.fileList werden die Dateinamen der gerade geschlossenen Dateien angezeigt.

Eine Online-Sicherung kann nur bei gestopptem Archiv wieder eingespielt werden. Dieser Vorgang ist ebenfalls extern anzustoßen und ist nicht Teil des Archivs oder der Historienebene.

Tabelle: DPE onlineBackup von DP _ValueArchive

Löschen von Archivsätzen

Für konstante Archivgrößen sind Lösch- und oder Auslagerungsvorgänge notwendig. Diese betreffen immer ganze Archivsätze (d.h. alle DPEs eines Archivs für einen gewissen Zeitraum). Als Parameter sind die zu löschenden Dateinamen, der action.fileList zu übergeben. Das Löschen kann manuell oder zeitgesteuert ausgelöst werden und wird von der Konfigurationsoberfläche gesteuert und aktiviert.

Redundanzabgleich: Beim Hochfahren prüft das Archiv, ob die übermittelte Files-Liste mit dem Inhalt des Archivierungs-Verzeichnisses zusammenpaßt (state = online). Überflüssige Dateien im Dateisystem werden gelöscht.

Tabelle: DPE lifeList von _ValueArchive

Sichern/Einlagern abgeschlossener Archivsätze

Ähnlich wie das Löschen erfolgt auch das Sichern von Archivsätzen. Es wird je Archiv für einen Zeitraum gestartet. Die Konfigurationsoberfläche meldet dabei die zu sichernden Archivsätze an das Archiv, welches diese für die Zeit der Sicherung für Schreibvorgänge sperrt. Das Skript archiv_client.ctl führt das tatsächliche Auslagern durch. (Bei neuen Projekten ist das Skript standardmäßig in der Skriptliste pvss_scripts.lst des CTRL-Managers vorhanden.) Zum zyklischen Aktivieren steht der Konfigurationsoberfläche das Element action.fileBackup.startTime zur Verfügung.

In den Strukturen action.media und archive kann eine Zuordnung Archivsatz-Dateiname - Backup-Medium (+ Zeitraum) vom Sicherungsskript abgelegt werden, um das spätere Einlagern für den Benutzer zur erleichtern. Das Auslagern kann manuell oder zeitgesteuert ausgelöst werden.

Die Einlagerung erfolgt auf dem umgekehrtem Weg.

Beim Start des Archivs prüft dieses den aktuellen Zustand von action.fileBackup.progress und setzt einen bereits begonnenen Sicherungsvorgang fort.

Komprimieren/Dekomprimieren von Archivsätzen

Die Komprimierung von Archivsätzen kann einerseits durch die Dateisystem-Funktion unter Windows (siehe compressValueArchive) oder durch Parametrierung der Komprimierung von Archiven ab 2.12.1 erfolgen (siehe History DB - Komprimierung der Archive).

Beim automatischen Aufruf der Komprimierung werden alle Komprimierungsstufen abgearbeitet.

Es werden nacheinander 2 Filelisten aufgebaut:

Für Stufe 1:

Alle Archivsätze die sich auf der Platte befinden, mit Ausnahme des aktuellen Archivsatzes, und die, die Komprimierungsstufe kleiner 1 haben.

Für Stufe 2:

Alle Archivsätze, die Komprimierungsstufe 1 haben (d.h. der aktuelle AS ist nicht dabei), vermindert um die Anzahl an AS die in Stufe 1 verbleiben sollen (DPE "packCount").

Die beiden Filelisten müssen addiert werden. Nach dem Addieren der Filelisten wird diese durch den Config-Eintrag maxNumberOfFilesToCompress (Default = 5, d.h. 5 Archivsätze pro Archiv werden bei jedem Durchgang komprimiert) verkürzt. Für jeden Eintrag in der Fileliste wird die Komprimierung angestoßen und zwar:

• Falls aktuelle Stufe == 0 dann Komprimierung in Stufe 1

• Falls aktuelle Stufe == 1 dann Komprimierung in Stufe 2

Dies gilt für die Einstellung einer automatischen Komprimierung (DPE "autoStartAfterSwitch") nach einem Archivsatzwechsel und dem Abwarten der Verzögerungszeit (DPE "expKeepPeriod"). Die Komprimierung der Archive kann ebenfalls manuell angestoßen werden (siehe Panel Historiendatenbank Aktion).

Folgende Tabelle gibt einen Überblick über die wichtigsten internen Datenpunktelemente und den parametrierbaren Wertebereich im Zusammenhang mit der History DB-Komprimierung: