PostgreSQL®-Schema

Note:
Bei der Verwendung von NextGen Archiver mit PostgreSQL® oder MS SQL® sind Datenpunktelemente vom Typ ulong, long oder bit64 auf 53 Bit Genauigkeit beschränkt.

Das PostgreSQL®-Datenbankschema enthält mehrere Tabellen:

  • systems – enthält Information der Systeme des WinCC OA-Projektes.
  • elements – enthält Information der Datenpunktelemente, die ihre eigenen Werte lesen/schreiben/archivieren müssen.
  • archive_groups – enthält Archivgruppen des Backends.
  • elements_to_archive_groups – Definiert Relationen (many-to-many) zwischen "Archivgruppen" und "Elemente". Diese Tabelle erlaubt es Verbindungen zwischen mehreren Archivgruppen zu speichern.
  • segments – speichert Segmente der Archivgruppen.
  • _event_%segment_id%_a – speichert einfache (non-dyn) EVENT-Werte.
  • _events_%segment_id%_d – speichert Events für Dyn-Werte.
  • _alert_%segment_id%_a – speichert ALARM-Werte.
  • _alert_%segment_id%_add – speichert zusätzliche Werte für ALARMS.
  • configuration – wird als key-value-Speicher von internen Parametern verwendet. Diese werden definiert, wenn die Datenbank erstellt wird.
  • scheduler_tasks – enthält Information der letzten erfolgreichen periodischen Taskausführung und deren Ausführungsperiode in Sekunden.

Die Datenbank bietet die folgenden VIEWS:

  • view_events – die View enthält die Verbindung (Union) aller EVENTS-Segementtabellen: Tabellen mit Stati ONLINE, CURRENT, ONLINE UND BACKUPED und RESTORED.
  • view_alarms – die View enthält die Verbindung (Union) aller ALARMS-Segementtabellen: Tabellen mit Stati ONLINE, CURRENT, ONLINE UND BACKUPED und RESTORED.
Figure 1. PostgreSQL®-Datenbankstruktur

Maximale Anzahl der erforderlichen PostgreSQL®-Verbindungen in einem verteilten System

Wenn ein Schema von mehreren verteilten Systemen gemeinsam genutzt wird, baut jedes System so viele Verbindungen auf, wie das Backend, mit dem es verbunden ist, benötigt. Darüber hinaus hat jeder Manager, der direkte Lesevorgänge (direct reads) durchführt, seine eigenen unabhängigen Leseverbindungen.

Wenn man alle diese Verbindungen zusammenzählt, kann die Gesamtzahl beträchtlich sein. Die Schätzung der erforderlichen Anzahl von Verbindungen hängt stark vom jeweiligen Anwendungsfall ab. Für die meisten Benutzer sollte der Standardwert von 100 Verbindungen ausreichend sein. Im Falle eines gemeinsam genutzten Schemas, mehrerer verteilter Systeme und vieler gleichzeitiger Operationen ist dies jedoch möglicherweise nicht ausreichend.

Zur Ermittlung der richtigen Anzahl von Verbindungen, wenn mehrere Clients parallel Abfragen durchführen, mehrere verteilte Systeme Abfragen von derselben Datenbank durchführen oder mehrere Clients direkten Lesezugriff verwenden. Verwenden Sie die folgende Abfrage, um die Anzahl der offenen Verbindungen zu überprüfen: 
SELECT COUNT(*) FROM pg_stat_activity;
Sie können die Anzahl der Verbindungen in der Datei :

Project_name/db/wincc_oa/localdb/postgresql/16/pgdata/postgresql.conf über den Eintrag max_connections = 100 # (change requires restart) ändern.