[vz-users] Aggregation (minute) schlägt fehl

Fr Mär 24 18:46:09 CET 2023

Hallo Michael,

wie Christian unten schon schreibt, kommt der Fehler vermutlich von 
folgender Zeile:

 > COALESCE( SUM(agg.val_by_time) / (MAX(agg.timestamp) - 
MIN(agg.prev_timestamp)),
die zur Division durch Null führt.

Wenn ich den SQL Code richtig verstehe, wird zunächst in der aggregate 
Tabelle der jüngste Timestamp gesucht, die glatte Minute dazu berechnet 
und eine Minute aufaddiert - nennen wir das mal T1. Das ist der 
Startpunkt für die Aggregation der neuen Daten, die dann angehängt werden.
Die Division durch Null kann eigentlich nur genau an dieser Stelle T1 
passieren, da T1 dann als prev_timestamp verwendet wird.
Wenn dann der Sonderfall eintritt, dass die neuen Daten nur einen 
Datenwert für den Minutenslot T1 haben und noch dazu dieser Timestamp 
(der ja in Millisekunden gezählt wird) auch genau auf eine glatte Minute 
fällt, dann wird der Nenner Null. Die Wahrscheinlichkeit ist ziemlich 
klein, es scheint aber zu passieren.

Du solltest das in deinem Datensatz nachvollziehen können.
Wenn dein Datensatz so aussieht, wird das aggregate nie mehr klappen, 
solange du die Daten nicht manipulierst (z.B. ein paar Milisekunden auf 
den Timestamp addieren).

Löscht man die aggregate Tabelle und berechnet sie neu, kommt man über 
diese Stelle hinweg, weil da ja nicht "angestückelt" wird.

Falls es das nicht ist: Eine andere mögliche Ursache ist folgender Teil 
des SQL Codes:
"SELECT channel_id, timestamp, value, value * (timestamp - 
@prev_timestamp) AS val_by_time, COALESCE(@prev_timestamp, 0) AS 
prev_timestamp, @prev_timestamp := timestamp"
da die MariaDB Dokumentation sagt: "It is unsafe to read a user-defined 
variable and set its value in the same statement (unless the command is 
SET), because the order of these actions is undefined."
Genau das passiert nämlich. Wenn die Zweisung @prev_timestamp := 
timestamp vor der COALESCE(@prev_timestamp, 0) ausgeführt wird, ergibt 
sich ebenfalls das Problem der Division durch Null, falls man nur einen 
Datenwert im Minutenslot hat - dann auch unabhängig von der Nahtstelle.

Gruss
Manfred

Am 21.03.2023 um 18:31 schrieb Michael Hartmann:
>
> Ich habe den von René verlinkten thread durchgelesen. Ja, das ist das 
> gleiche Problem wie bei mir. Nur das der Workaround den er seinerzeit 
> durchgeführt hat,, nämlich das Aggregate-Table zu löschen und neu 
> aufzubauen bei mir nur temporär wirkt.
>
> Der Fehler kommt nach einiger Zeit wieder.
>
> Leider scheint es seither keine Lösung dafür zu geben oder auch nur 
> eine konkrete Ursache bekannt zu sein.
>
> Grüße
>
> Micha
>
> *Von:*volkszaehler-users 
> [mailto:volkszaehler-users-bounces at demo.volkszaehler.org] *Im Auftrag 
> von *René W
> *Gesendet:* Montag, 20. März 2023 15:10
> *An:* volkszaehler.org - users
> *Betreff:* Re: [vz-users] Aggregation (minute) schlägt fehl
>
> Ich hatte „damals“ auch schon diese nervige Meldung:
>
> https://demo.volkszaehler.org/pipermail/volkszaehler-users/2019-June/013374.html
>
> Vielleicht sind dort ja noch ein paar Hinweise. Ich selber nutze VZ 
> nicht mehr dafür.
>
> Gruß René
>
> Michael Hartmann <hartmann-micha at web.de> schrieb am Mo. 20. März 2023 
> um 15:03:
>
>     Hallo Christian,
>
>     ich hatte erst an negative Werte gedacht und keine um den
>     „Ausstiegszeitpunkt“ gefunden. Das scheidet aber auch aus, da sich
>     die Werte im Zähler befinden und somit keine Division durch Null
>     hervorrufen können.
>
>     Was mich irritiert ist das nach Löschen der aggregierten Daten
>     deren Neuerstellung fehlerfrei durchläuft.
>
>     Kann jemand aus der Fehlermeldung erkennen um welchen Kanal
>     (Channel_ID) es gehen könnte?
>
>     Grüße
>
>     Micha
>
>     *Von:*volkszaehler-users
>     [mailto:volkszaehler-users-bounces at demo.volkszaehler.org] *Im
>     Auftrag von *Christian Lange
>     *Gesendet:* Montag, 20. März 2023 11:29
>     *An:* volkszaehler-users at demo.volkszaehler.org
>     *Betreff:* Re: [vz-users] Aggregation (minute) schlägt fehl
>
>     Hi Micha,
>
>     ich hab leider keine Ahnung, wie die Datenbank aussieht (ich nutze
>     selbst eine andere), aber der Fehler sagt aus, dass eine Division
>     durch 0 vorliegt.
>
>     Die einzige Zeile in der SQL Query, die mir da ins Auge sticht ist
>     diese hier:
>
>     > COALESCE( SUM(agg.val_by_time) / (MAX(agg.timestamp) -
>     MIN(agg.prev_timestamp)),
>
>     Das Maximum des Timestamps minus dem Minimum des vorherigen
>     Timestamps aus der (on the fly) erzeugten "agg" Tabelle sind
>     zusammen 0. Daher klappt die Division und damit die SQL Query
>     nicht. Die Daten stammen (soweit ich das sehen kann) aus der
>     "data" Tabelle. Vielleicht fällt dir ja da etwas auf in den Daten
>     bei den Timestamps. Den Rest überlasse ich den Experten, die das
>     Tool so im Einsatz haben ;)
>
>     Viel Erfolg,
>     Christian
>
>     Am 20.03.2023 um 10:37 schrieb Michael Hartmann:
>
>         Hallo,
>
>         ich hole das hier noch einmal vor, da es ziemliche nervt.
>
>         Via cronjob lasse ich alle 10min eine Aggregation auf die
>         Minute laufen. Bereits vor einigen Wochen ist diese dann
>         plötzlich mit der folgenden Fehlermeldung ausgestiegen:
>
>         In AbstractMySQLDriver.php line 128:
>
>           An exception occurred while executing 'REPLACE INTO
>         aggregate (channel_id,
>
>           type, timestamp, value, count) SELECT channel_id, ? AS type,
>         MAX(agg.timest
>
>           amp) AS timestamp, COALESCE( SUM(agg.val_by_time) /
>         (MAX(agg.timestamp) - M
>
>           IN(agg.prev_timestamp)), AVG(agg.value)) AS value,
>         COUNT(agg.value) AS coun
>
>           t FROM ( SELECT channel_id, timestamp, value, value *
>         (timestamp - @prev_ti
>
>           mestamp) AS val_by_time, COALESCE(@prev_timestamp, 0) AS
>         prev_timestamp, @p
>
>           rev_timestamp := timestamp FROM data CROSS JOIN (SELECT
>         @prev_timestamp :=
>
>         UNIX_TIMESTAMP(DATE_ADD(FROM_UNIXTIME(MAX(timestamp) / 1000,
>         "%Y-%m-%d %H:%
>
>           i:00"), INTERVAL 1 minute)) * 1000 FROM aggregate WHERE type
>         = ? AND aggreg
>
>           ate.channel_id = ?) AS vars WHERE channel_id = ? AND
>         timestamp >= IFNULL((S
>
>           ELECT UNIX_TIMESTAMP(DATE_ADD(FROM_UNIXTIME(MAX(timestamp) /
>         1000, "%Y-%m-%
>
>           d %H:%i:00"), INTERVAL 1 minute)) * 1000 FROM aggregate
>         WHERE type = ? AND
>
>           aggregate.channel_id = ? ), 0) AND timestamp <
>         UNIX_TIMESTAMP(DATE_FORMAT(N
>
>           OW(), "%Y-%m-%d %H:%i:00")) * 1000 ) AS agg GROUP BY
>         channel_id, YEAR(FROM_
>
>           UNIXTIME(timestamp/1000)),
>         DAYOFYEAR(FROM_UNIXTIME(timestamp/1000)), HOUR(F
>
>           ROM_UNIXTIME(timestamp/1000)),
>         MINUTE(FROM_UNIXTIME(timestamp/1000))' with
>
>           params [1, 1, "3", "3", 1, "3"]:
>
>           SQLSTATE[22012]: Division by zero: 1365 Division by 0
>
>         In Exception.php line 18:
>
>           SQLSTATE[22012]: Division by zero: 1365 Division by 0
>
>         In PDOStatement.php line 117:
>
>           SQLSTATE[22012]: Division by zero: 1365 Division by 0
>
>         Die Aggregation auf Stunde und Tag bereitet (bisher) keine
>         Probleme.
>
>         Beim letzten Mal hatte ich die Aggregationstabelle gelöscht
>         und neu aufgebaut. Nach einigen Wochen kommt der Fehler nun
>         wieder.
>
>         Kann mir jemand erklären wo das Problem liegt? Die
>         Fehlermeldung kann ich nicht interpretieren.
>
>         Viele Grüße
>
>         Micha
>
-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://demo.volkszaehler.org/pipermail/volkszaehler-users/attachments/20230324/3a2c20ef/attachment-0001.html>