PostgreSQL®-Schema

Für die Versionen 3.20 und höher wurde der Standardindex für die Tabelle EVENT aus verschiedenen Gründen, insbesondere im Hinblick auf eine bessere Leseleistung, von BRIN auf BTREE geändert.

Note: Das PostgreSQL®-Schema wurde in Version 3.20 von BRIN-Indizes auf BTREE-Indizes umgestellt. BRIN-Indizes im PostgreSQL®-Schema sind daher obsolet. Ein Tool/Skript zur Konvertierung einer bestehenden PostgreSQL®-Datenbank von BRIN nach BTREE kann beim WinCC OA-Support angefordert werden.

Bitte wählen Sie eine Segmentgröße zwischen 15 und 50GB, da es bei größeren Segmenten langfristig zu einer Verringerung der Performance kommen kann (Degradation).

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.