Hilfe · Historisierung

QuantumLeap: Dezimalwert kann nicht gespeichert werden

QuantumLeap meldet bei einem Wert wie 31.84 den Fehler „invalid input syntax for type bigint“. Diese Anleitung zeigt, warum Stellio den Wert trotzdem führen kann und wie Sie die zu eng angelegte TimescaleDB-Spalte administrativ korrigieren.

Das Fehlerbild erkennen

QuantumLeap legt Tabellen und neue Attributspalten beim ersten historischen Datensatz dynamisch an. Ist der Attributtyp nicht eindeutig vorgegeben, leitet QuantumLeap den SQL-Typ aus dem ersten Wert ab: Ein ganzzahliger Wert wird zu bigint, ein Dezimalwert zu einem Fließkommatyp. Dadurch kann beispielsweise ein erster waterLevel von 31 die Spalte waterlevel bigint erzeugen. Ein späterer Wert 31.84 passt nicht mehr in diese Spalte.

Typisch für diesen Fehler ist:

• Stellio führt den aktuellen Dezimalwert korrekt.
• In der QuantumLeap-Historie fehlt genau diese Aktualisierung.
• QuantumLeap oder die Datenbank meldet einen Typfehler für bigint und einen Wert mit Dezimalstellen.
• Frühere ganzzahlige Werte sind in der historischen Tabelle weiterhin vorhanden.

Der Fehler entsteht nicht in Stellio

Stellio verwaltet den aktuellen Zustand der NGSI-LD-Entität. Der Fehler entsteht erst, wenn QuantumLeap die Benachrichtigung in die vorhandene TimescaleDB-Spalte schreiben will. Prüfen Sie aktuellen Zustand und Historie deshalb getrennt. Eine Änderung an der QuantumLeap-Tabelle verändert die Entität in Stellio nicht.

Für die folgenden Schritte benötigen Sie eine ausdrücklich freigegebene administrative Verbindung zur QuantumLeap-/TimescaleDB. Ein lesender Grafana- oder Analysezugang reicht nicht aus. Sind Sicherung, Wartungsfenster oder Berechtigung ungeklärt, geben Sie den Befund an den Plattformbetrieb weiter und führen das ALTER TABLE nicht selbst aus.

1. Tabelle und Spaltentyp nachweisen

Die Pegelreferenz verwendet die Datenbank quantumleap, das Schema mtds_environment, die Tabelle etwaterobserved und die Spalte waterlevel. Öffnen Sie in pgAdmin nur die dafür freigegebene administrative Verbindung. Ist sie noch nicht im persönlichen pgAdmin-Konto hinterlegt, folgen Sie zuerst der Anleitung Datenbank in pgAdmin registrieren.

Prüfen Sie zuerst Datenbank, Benutzer und aktuellen Spaltentyp:

Datenbank, Tabelle und Spaltentyp prüfen

SELECT current_database(), current_user;

SELECT
  table_schema,
  table_name,
  column_name,
  data_type
FROM information_schema.columns
WHERE table_schema = 'mtds_environment'
  AND table_name = 'etwaterobserved'
  AND column_name = 'waterlevel';

Das Fehlerbild ist bestätigt, wenn data_type = bigint zurückgegeben wird und QuantumLeap beim Dezimalwert einen Fehler wie invalid input syntax for type bigint: "31.84" protokolliert hat.

Ändern Sie die Spalte nicht, wenn Schema, Tabelle, Attribut oder Fehlermeldung von diesem Befund abweichen. Ein Textwert in einem eigentlich numerischen Attribut muss im Datenfluss korrigiert werden; ein breiterer SQL-Typ würde die fachlich falsche Eingabe nur verdecken.

2. Wartungsgrenzen prüfen

Vor dem SQL-Eingriff müssen folgende Punkte erfüllt sein:

• Für die Datenbank liegt ein aktueller, geprüfter Sicherungs- oder Wiederherstellungspunkt vor.
• Betroffene Node-RED-Flows und weitere Schreiber auf etwaterobserved sind für das Wartungsfenster pausiert.
• Dashboards und Alert-Regeln dürfen während des exklusiven Tabellen-Locks vorübergehend keine Daten erhalten.
• Der angemeldete Datenbankbenutzer darf die konkrete Tabelle ändern.
• Es ist geprüft, ob die Tabelle komprimierte TimescaleDB-Chunks besitzt.

Den letzten Punkt weist diese Abfrage nach:

Hypertable und komprimierte Chunks prüfen

SELECT
  h.hypertable_schema,
  h.hypertable_name,
  h.compression_enabled,
  EXISTS (
    SELECT 1
    FROM timescaledb_information.chunks AS c
    WHERE c.hypertable_schema = h.hypertable_schema
      AND c.hypertable_name = h.hypertable_name
      AND c.is_compressed
  ) AS has_compressed_chunks
FROM timescaledb_information.hypertables AS h
WHERE h.hypertable_schema = 'mtds_environment'
  AND h.hypertable_name = 'etwaterobserved';

Keine Ergebniszeile bedeutet, dass die Tabelle keine TimescaleDB-Hypertable ist. has_compressed_chunks = false erlaubt den folgenden normalen Änderungspfad. Bei komprimierten Chunks darf der Spaltentyp nicht direkt geändert werden. Planen Sie dann Dekomprimierung, Speicherbedarf, Änderung und erneute Komprimierung als eigenes Datenbank-Wartungsfenster nach der TimescaleDB-Betriebsanleitung.

3. waterlevel auf double precision ändern

Führen Sie den folgenden Block im pgAdmin Query Tool als eine Transaktion aus. Der kurze lock_timeout verhindert, dass die Sitzung unbegrenzt auf eine weiterhin beschriebene Tabelle wartet. Der Cast ist für vorhandene bigint-Werte verlustfrei.

Spaltentyp transaktional korrigieren

BEGIN;

SET LOCAL lock_timeout = '10s';
SET LOCAL statement_timeout = '15min';

LOCK TABLE mtds_environment.etwaterobserved
  IN ACCESS EXCLUSIVE MODE;

ALTER TABLE mtds_environment.etwaterobserved
  ALTER COLUMN waterlevel
  TYPE double precision
  USING waterlevel::double precision;

COMMIT;

Schlägt ein Befehl fehl, wird die Transaktion nicht teilweise übernommen. Führen Sie dann ROLLBACK; aus, prüfen Sie die Fehlermeldung und lassen Sie die Flows pausiert, bis die Ursache geklärt ist. Wiederholen Sie das ALTER TABLE nicht mit einem anderen Zieltyp oder deaktivierten Zeitlimits, ohne Lock, Abhängigkeiten und Speicherbedarf erneut zu bewerten.

4. Korrektur über den normalen Datenweg prüfen

Bestätigen Sie unmittelbar nach dem Commit den neuen Typ:

Neuen Spaltentyp bestätigen

SELECT data_type
FROM information_schema.columns
WHERE table_schema = 'mtds_environment'
  AND table_name = 'etwaterobserved'
  AND column_name = 'waterlevel';

Erwartet wird double precision. Starten Sie anschließend die betroffenen Flows wieder und senden Sie einen kontrollierten neuen Pegelwert mit Dezimalstellen und einem neuen dateObserved. Prüfen Sie den Historieneintrag:

Neuen Dezimalwert in der Historie prüfen

SELECT
  entity_id,
  dateobserved,
  time_index,
  waterlevel,
  source
FROM mtds_environment.etwaterobserved
WHERE waterlevel IS NOT NULL
ORDER BY dateobserved DESC
LIMIT 20;

Der neue Wert muss ohne Cast als Dezimalzahl erscheinen. Vergleichen Sie außerdem dieselbe Entity über Stellio und kontrollieren Sie das betroffene Dashboard.

Ein zuvor fehlgeschlagener historischer Messpunkt wird durch die Typänderung nicht automatisch nachgeschrieben. Soll er erhalten bleiben, muss seine Wiederholung anhand der autoritativen Quelle separat entschieden und über einen kontrollierten Datenweg ausgeführt werden. Fügen Sie keine Fachzeile direkt per INSERT in die QuantumLeap-Tabelle ein.

Den Fehler künftig früher erkennen

Prüfen Sie bei der Abnahme einer neuen Historisierung nach dem ersten Testdatensatz die erzeugten SQL-Typen gegen den fachlich zulässigen Wertebereich. Kann ein Messwert Dezimalstellen enthalten, umfasst die Abnahme mindestens einen repräsentativen Dezimalwert, bevor der Datenfluss produktiv freigegeben wird.

Referenzen