Funktionsweise der RDB-Archivierung
Datenmodell
Der RDB Archiv-Manager übergibt die Wertänderungen aus WinCC OA in bestimmte Tabellen innerhalb der RDB. Die Zuordnung, welcher Wert in welche Tabelle geschrieben wird, wird analog zum Value Archiv mit Hilfe des Konfigs _archive festgelegt. Es besteht somit eine eindeutige Zuordnung zwischen einem Datenpunktelement in WinCC OA und einer Tabelle in der RDB, die für seine Archivierung zuständig ist.
Die Organisation der Tabellen in der DB selbst ist in Tabellen für Werte (Werte können in verschiedenen Werte-/Archivgruppen gespeichert werden - siehe auch Grafik am Ende dieser Seite) und in eine Tabelle für Alarme getrennt (für Alarme steht nur eine Tabelle in Oracle zur Verfügung). Jeweils zwei Tabellen werden wiederum innerhalb einer Werte-/Archivgruppe verwendet, um getrennt voneinander in einer Tabelle Werte vom Typ Array (z.B. der WinCC OA Datentyp dyn_float) und in der anderen Tabelle die restlichen Datentypen (z.B. der WinCC OA Datentyp int) verwalten zu können.
Es werden die WinCC OA Datentypen "blob", "struct", "langString", "dpIdentifier" und deren Ausprägung als Array (siehe Wertebereiche der Datentypen), sowie der Control Datentyp "dyn_dyn" (siehe Datentypen) vom RDB Archiv-Manager nicht unterstützt!
Die Gruppierung der Tabellen in Werte und Alarme trägt dem offensichtlichen Umstand Rechnung, dass der Typ und die zu erwartende Anzahl an Informationen in den beiden Gruppen unterschiedlich sein wird.
Die eigentliche Archivierung in Oracle wird nicht in den Eingangstabellen selbst durchgeführt; dorthin werden nur die mit einem Archivkonfig versehenen Werte aus WinCC OA geschrieben. Jede Eingangstabelle besitzt eine ihr nachgelagerte Tabelle, die die Wertänderungen der Eingangstabelle protokolliert und somit archiviert.
Eine Eingangstabelle in Oracle enthält somit alle aktuellen Werte der ihr zugeordneten Datenpunktelemente und somit eigentlich auch das aktuelle Prozessabbild, aber nur noch von Daten, die als zu archivieren gekennzeichnet sind. Werte in der Eingangstabelle werden ständig überschrieben. Die nachgelagerte Tabelle übernimmt die Werte aus der Eingangstabelle, wobei aber die Wertänderungen gemerkt und nicht überschrieben werden.
Datenfluss bei schreibendem Zugriff in die RDB
WinCC OA UI (oder WinCC OA Treiber) > WCCILevent > WCCILdata > WCCOArdb > libSQLAPI.dll > RDB
Datenfluss bei lesendem Zugriff in die RDB
Variante 1 (ohne config-Eintrag):
WinCC OA UI (oder WinCC OA Treiber) > WCCILevent > WCCILdata > WCCOArdb > BasicRDBArchive.dll > libSQLAPI.dll > RDB
Variante 2 (mit config-Eintrag):
WinCC OA UI (oder WinCC OA Treiber) > CtrlRDBArchive.dll > BasicRDBArchive.dll > libSQLAPI.dll > RDB
Datenfluss beim Lesen von Verdichtungswerten aus der RDB
WinCC OA UI (oder WinCC OA Treiber) > CtrlRDBCompr.dll > BasicRDBArchive.dll > libSQLAPI.dll > RDB
Archivierung, Archivgruppen, Tablespaces, Namenskonvention
Das Schreiben in die den Eingangstabellen nachgelagerten Tabellen (= Archivsätze) löst also den eigentlichen Archivierungsprozess aus. Nachgelagerte Tabellen, in die aktuell geschrieben wird, werden als "Current" bezeichnet, vergleichbar mit einem aktuellen Archivsatz bei den Value Archiven. Und genauso wie dort, wird, entweder mengen- und/oder zeitmäßig gesteuert, die aktuelle Tabelle geschlossen. Sie wird dann als "Online" bezeichnet und an ihre Stelle tritt eine neue "Current"-Tabelle.
Solange eine Tabelle den Status "Online" oder "Current" hat, kann sie, entweder von WinCC OA oder mit einem externen Auswertetool, ausgelesen oder beschrieben werden. Tabellen können aber auch den Status "Offline" einnehmen. Sie sind dann nicht mehr im Zugriff ("ausgehängt" - es ist nur mehr ein Eintrag in Oracle, dass es diese Tabelle gibt), aber das physikalische File befindet sich bereits im Backup-Verzeichnis (auf ein Offline Archiv kann somit nicht mehr über die Oracle Datenbank zugegriffen werden). Dieser Zustand ist notwendig, damit Tabellen ausgelagert (= auf ein fremdes Medium verschoben) werden können. Ausgelagerte Tabellen werden dann mit dem Status "Backup" versehen und sind nur noch am Auslagerungsmedium vorhanden (die entsprechende Offline Tabelle wird am Oracle Server gelöscht). Diese Tabellen können natürlich später wieder eingelagert werden und stehen somit wieder für Abfragen zur Verfügung. Bevor eine Tabelle ausgelagert wird, wird von jedem in ihr enthaltenen Datenpunktelement der jüngste Wert gesucht und als sogenannter "Bodensatz" in die älteste verbleibende verwandte Tabelle geschrieben. Der Bodensatz dient dazu, um Werte nicht vollständig zu verlieren. Wenn ein Wert lange Zeit nicht kommt und immer wieder ausgelagert wird, wäre dieser Wert verloren.
Es ist nicht erlaubt eine Archivdatei OFFLINE zwischen ONLINE- und CURRENT-Archivdateien zu setzen. Es wird dringend empfohlen nur die älteste Archivdatei OFFLINE zu setzen.
Wenn Oracle Standard Edition verwendet wird, werden Tablespaces nicht gelöscht, sondern es werden nur die entsprechenden Datendateien wegkopiert und diese dann gelöscht. Ansonsten wären die Tablespaces nicht wiederherstellbar.
Alle zusammengehörenden Tabellen ("Current", "Online", "Offline") bilden eine Archivgruppe. Zusammengehörend sind in diesem Fall die beiden Eingangstabellen (wie schon besprochen, eine für die "normalen" Werte und eine für die array-Datentypen) und die ihnen nachgelagerten Tabellen, die für die eigentliche Archivierung zuständig sind. Der kleinstmögliche Inhalt einer Archivgruppe ist somit vier Tabellen - 2 Eingangstabellen und 2 nachgelagerte Tabellen im Status "Current". Natürlich kann eine Archivgruppe aber auch noch zusätzlich eine (einstellbare) Anzahl von "Online" und "Offline" Tabellen beinhalten.
Die Zuordnung von Oracle-Tabellen zu Archivgruppen erfolgt über einen eindeutigen, maximal 7-stelligen Namen. Dieser Name wird für die Bezeichnung der Gruppe verwendet und findet sich auch als Teil des Tabellennamens. Betrachtet man die defaultmäßig angelegten Tabellen (EventLastVal und EventLastValValues mit EventHistory und EventHistoryValues, sowie AlertLastVal und AlertLastValValues mit AlertHistory und AlertHistoryValues), so sieht man, dass die ersten vier Tabellen offensichtlich einer Gruppe mit Namen "Event" und die vier anderen Tabellen einer Gruppe mit dem Namen "Alert" zugeordnet sind. Das sind die Leseviews. Die einzelnen Tabellen heißen z.B. EventHistory_00000021 (siehe auch Grafik unten).
Die Einstellungen über Tabellenwechsel, Auslagerungszeitpunkt, etc. werden pro Archivgruppe festgelegt. Wird in einer Archivgruppe ein Archivsatzwechsel durchgeführt (die "Current"-Tabellen werden geschlossen und werden zu den jüngsten Online-Tabellen, ein neues "Current"-Tabellenpaar wird angelegt), dann wird jedes neue Tabellenpaar mit einer eindeutigen 8-stelligen Nummer gekennzeichnet. Diese Nummer wird als Suffix im Namen der neuen Tabellen vermerkt. Außerdem wird für jedes neu erstellte Tabellenpaar ein eigener Tablespace angelegt.
Nachdem jeder Archivsatz in einem eigenem Tablespace liegt, kann die Aufgabe der Aus- und Einlagerung leicht durchgeführt werden. Der betreffende Tablespace muss nur aus Oracle ausgelagert und an eine andere Stelle verschoben werden.
Die Namensgebung der Tablespaces lehnt sich an die der Archivgruppen an. Tablespaces, die eine Archivgruppe beinhalten, werden wie die Archivgruppe genannt und erhalten zusätzlich den Benutzernamen als Präfix sowie die Archivnummer als Suffix (z.B.: Tablespace Schmidt_Antriebe_00000228.DBF beinhaltet das Archiv Nummer 228 der Archivgruppe Antriebe mit den Tabellen AntriebeHistory_00000228 und AntriebeHistoryValues_00000228).
Zu beachten ist, dass ein Benutzername maximal 13-Zeichen enthalten darf.
Der Tablespace, der alle anderen Tabellen, die für die Verwaltung des Archives notwendig sind, enthält, wird wie der in Oracle angemeldete Benutzer genannt und erhält als Präfix die Buchstabenkombination "TS". Wird also zum Beispiel beim RDB-Setup festgelegt, dass sich in Oracle ein Benutzer mit Namen "Operator" anmeldet, dann wird der Tablespace für die übrigen Tabellen "TS_Operator" genannt.
