Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)

[ch.eick]

Hallo Christian,

ich habe beide SQLs jetzt mal rauskopiert und bei mir ausgeführt.
Laufen fehlerfrei durch. Zwar ohne Wert, aber syntaktisch ok.

Code Auswählen Erweitern


2022.01.27 20:13:18.101 4: DbRep Rep.LogDB - -------- New selection ---------
2022.01.27 20:13:18.102 4: DbRep Rep.LogDB - Command: sqlCmd INSERT INTO history (TIMESTAMP,DEVICE,READING,VALUE) SELECT TIMESTAMP,DEVICE,READING,VALUE FROM ( SELECT DATE_ADD(CURDATE(),INTERVAL t2.HOUR HOUR) AS TIMESTAMP, t2.DEVICE, @readingname AS READING, cast(if(avg(t2.FACTOR) > 1.6, 1.6, avg(t2.FACTOR) ) AS DECIMAL(2,1)) AS VALUE FROM ( SELECT * FROM ( SELECT t1.TIMESTAMP, t1.HOUR, t1.DEVICE, t1.READING, t1.VALUE, if(@diff = 0,NULL, @temp:=cast((t1.VALUE-@diff) AS DECIMAL(6,2))) AS DIFF, cast((t1.VALUE/(t1.VALUE+(-1*@temp))*@corr) AS DECIMAL(4,1)) AS FACTOR, @diff:=t1.VALUE AS curr_V FROM ( SELECT h.TIMESTAMP, date(h.TIMESTAMP) AS DATE, hour(h.TIMESTAMP) AS HOUR, h.DEVICE, h.READING, h.VALUE FROM history AS h WHERE h.DEVICE = @device AND (h.READING = @reading1 OR h.READING = @reading2) AND h.TIMESTAMP >= DATE_SUB(DATE(now()),INTERVAL @days DAY) AND h.TIMESTAMP <= CURDATE() AND MINUTE(h.TIMESTAMP) = 0 AND h.VALUE >= 0 GROUP BY DATE,HOUR,h.READING,h.DEVICE,h.TIMESTAMP )t1 )tx WHERE READING != @reading2 AND HOUR > 6 )t2 GROUP BY t2.HOUR,t2.DEVICE )t3 WHERE t3.VALUE != 0 ON DUPLICATE KEY UPDATE VALUE=t3.VALUE;
2022.01.27 20:13:18.103 4: DbRep Rep.LogDB - FullDay option: 0
2022.01.27 20:13:18.103 4: DbRep Rep.LogDB - Timestamp begin human readable: 2022-01-01 00:00:00
2022.01.27 20:13:18.104 4: DbRep Rep.LogDB - Timestamp end human readable: 2022-01-26 23:59:59
2022.01.27 20:13:18.308 4: DbRep Rep.LogDB - adminCredentials successfully read from file
2022.01.27 20:13:18.310 4: DbRep Rep.LogDB - Database connect - user: root, UTF-8 option set: yes
2022.01.27 20:13:18.312 4: DbRep Rep.LogDB - SQL execute: INSERT INTO history (TIMESTAMP,DEVICE,READING,VALUE) SELECT TIMESTAMP,DEVICE,READING,VALUE FROM ( SELECT DATE_ADD(CURDATE(),INTERVAL t2.HOUR HOUR) AS TIMESTAMP, t2.DEVICE, @readingname AS READING, cast(if(avg(t2.FACTOR) > 1.6, 1.6, avg(t2.FACTOR) ) AS DECIMAL(2,1)) AS VALUE FROM ( SELECT * FROM ( SELECT t1.TIMESTAMP, t1.HOUR, t1.DEVICE, t1.READING, t1.VALUE, if(@diff = 0,NULL, @temp:=cast((t1.VALUE-@diff) AS DECIMAL(6,2))) AS DIFF, cast((t1.VALUE/(t1.VALUE+(-1*@temp))*@corr) AS DECIMAL(4,1)) AS FACTOR, @diff:=t1.VALUE AS curr_V FROM ( SELECT h.TIMESTAMP, date(h.TIMESTAMP) AS DATE, hour(h.TIMESTAMP) AS HOUR, h.DEVICE, h.READING, h.VALUE FROM history AS h WHERE h.DEVICE = @device AND (h.READING = @reading1 OR h.READING = @reading2) AND h.TIMESTAMP >= DATE_SUB(DATE(now()),INTERVAL @days DAY) AND h.TIMESTAMP <= CURDATE() AND MINUTE(h.TIMESTAMP) = 0 AND h.VALUE >= 0 GROUP BY DATE,HOUR,h.READING,h.DEVICE,h.TIMESTAMP )t1 )tx WHERE READING != @reading2 AND HOUR > 6 )t2 GROUP BY t2.HOUR,t2.DEVICE )t3 WHERE t3.VALUE != 0 ON DUPLICATE KEY UPDATE VALUE=t3.VALUE;
2022.01.27 20:13:18.316 4: DbRep Rep.LogDB - data autocommitted
2022.01.27 20:13:18.317 3: DbRep Rep.LogDB - Number of entries processed in db fhemtest: 0 by INSERT


Grüße,
Heiko

Okay, danke,
dann muss es doch etwas mit den Daten zu tun haben.
Aber warum geht der SELECT, mit der Berechnung? Der liefert ein Korrektes Ergebnis.
Dann mit dem INSERT, bei dem nichts mehr zusätzlich gerechnet wird kommt die Meldung.

Besten Dank
   Christian

[DS_Starter]

Aktuell sind wir schon bei dieser eingecheckten Version:

93_DbRep.pm:v8.47.0-s25492/2022-01-17

[ch.eick]

Aktuell sind wir schon bei dieser eingecheckten Version:

93_DbRep.pm:v8.47.0-s25492/2022-01-17

Bin wieder on Track

Das Problem waren letztlich die Daten. Ich habe jetzt expliziet die Division durch Null abgefangen und schon geht es.
Warum das SELECT das nicht als Fehler gemeldet hat, aber das Umklammernde INSERT kann ich nicht verstehen. => böser Woodoo Zauber

VG
  Christian

[t1me2die]

Moin zusammen, ich wollte hier einmal mein Problem in Verbindung mit dem DbRep, MariaDB und OptimizeTable verlinken:

https://forum.fhem.de/index.php/topic,125762.0.html

Falls jemand einen hilfreichen Tipp für mich hat, oder ob ich irgendwas falsch konfiguriert hat wäre ich sehr hilfreich.

Gruß
Mathze

[Didi]

Hallo seit dem letzten Update funktioniert bei mir "dumpmysql" nicht mehr. Es scheint das noch die current-Tabelle gesichert wird dann tut sich aber nichts mehr.
Mit der Version "93_DbRep.pm:v8.46.11-s25414/2022-01-03" läuft noch alles und das Dumpfile mit gut 1.1 GB ist nach ca 3 Minuten geschrieben.

Fhem läuft auf einem Rasberry 4, der Dump wird clientside ausgeführt

Woran kann das liegen?

[DS_Starter]

Schalte bitte verbose 4 im Device ein und wiederhole bitte den dump.
Dann bitte noch ein List vom Device.
Bei mir läuft alles wie gewohnt.  Allerdings sind wir inzwischen offiziell bereits bei der Version V8.47.0.
Mach bitte vorher noch ein update.

LG

[DS_Starter]

Noch besser wäre es die aktuellste Entwicklungsversion zu benutzen. Die habe ich im Einsatz und steht kurz vor dem Check In.

Zum Download in der FHEMWEB Kommandozeile inklusive der Anführungszeichen angeben und danach FHEM restarten:

Code Auswählen Erweitern

"wget -qO ./FHEM/93_DbRep.pm https://svn.fhem.de/fhem/trunk/fhem/contrib/DS_Starter/93_DbRep.pm"

Grüße,
Heiko

[Didi]

Hallo DS_Starter,

ich habe es schon mehrfach probiert aber das Problem tritt bei mir seit der Version "93_DbRep.pm:v8.46.11-s25414/2022-01-03" jedes mal auf. Jetzt habe ich noch mal auf die aktuelle Version upgedatet und einen Logauszug und  ein List vom Device an gehangen. Es scheint was abgearbeitet zu werden aber es wird nichts in den Speicher geschrieben. Die Dateigröße bleibt bei 39KB stehen.
Logauszug:

Code Auswählen Erweitern

2022.01.30 13:17:24 3: DbRep repdb - ################################################################
2022.01.30 13:17:24 3: DbRep repdb - ###             New database clientSide dump                 ###
2022.01.30 13:17:24 3: DbRep repdb - ################################################################
2022.01.30 13:17:24 3: DbRep repdb - Starting dump of database 'fhem'
2022.01.30 13:17:24 4: DbRep repdb - Database connect - user: fhem, UTF-8 option set: yes
2022.01.30 13:17:24 4: DbRep repdb - SQL execute: SELECT VERSION()
2022.01.30 13:17:24 3: DbRep repdb - Characterset of collection and backup file set to utf8.
2022.01.30 13:17:24 3: DbRep repdb - Searching for tables inside database fhem....
2022.01.30 13:17:24 4: DbRep repdb - SQL execute: SHOW TABLE STATUS FROM `fhem`
2022.01.30 13:17:24 4: DbRep repdb - SQL execute: SELECT count(*) FROM `current`
2022.01.30 13:17:24 4: DbRep repdb - SQL execute: SELECT count(*) FROM `history`
2022.01.30 13:17:33 3: DbRep repdb - Found 2 tables with 6401083 records.
2022.01.30 13:17:33 3: DbRep repdb - Dumping table current (Type InnoDB):
2022.01.30 13:17:33 4: DbRep repdb - SQL execute: SHOW CREATE TABLE `current`
2022.01.30 13:17:33 4: DbRep repdb - SQL execute: SHOW FIELDS FROM `current`
2022.01.30 13:17:33 4: DbRep repdb - SQL execute: SELECT * FROM `current` LIMIT 0,5000;
2022.01.30 13:17:33 3: DbRep repdb - 212 records inserted (size of backupfile: 38.10 KB)
2022.01.30 13:17:33 3: DbRep repdb - Dumping table history (Type InnoDB):
2022.01.30 13:17:33 4: DbRep repdb - SQL execute: SHOW CREATE TABLE `history`
2022.01.30 13:17:33 4: DbRep repdb - SQL execute: SHOW FIELDS FROM `history`
2022.01.30 13:17:33 4: DbRep repdb - SQL execute: SELECT * FROM `history` LIMIT 0,5000;
2022.01.30 13:17:33 4: DbRep repdb - SQL execute: SELECT * FROM `history` LIMIT 5000,5000;
2022.01.30 13:18:15 4: DbRep repdb - SQL execute: SELECT * FROM `history` LIMIT 10000,5000;
2022.01.30 13:19:31 4: DbRep repdb - SQL execute: SELECT * FROM `history` LIMIT 15000,5000;
2022.01.30 13:21:17 4: DbRep repdb - SQL execute: SELECT * FROM `history` LIMIT 20000,5000;
2022.01.30 13:23:33 4: DbRep repdb - SQL execute: SELECT * FROM `history` LIMIT 25000,5000;
2022.01.30 13:26:19 4: DbRep repdb - SQL execute: SELECT * FROM `history` LIMIT 30000,5000;
2022.01.30 13:29:36 4: DbRep repdb - SQL execute: SELECT * FROM `history` LIMIT 35000,5000;
2022.01.30 13:33:22 4: DbRep repdb - SQL execute: SELECT * FROM `history` LIMIT 40000,5000;
2022.01.30 13:37:39 4: DbRep repdb - SQL execute: SELECT * FROM `history` LIMIT 45000,5000;
2022.01.30 13:42:25 4: DbRep repdb - SQL execute: SELECT * FROM `history` LIMIT 50000,5000;
2022.01.30 13:47:42 4: DbRep repdb - SQL execute: SELECT * FROM `history` LIMIT 55000,5000;
2022.01.30 13:53:29 4: DbRep repdb - SQL execute: SELECT * FROM `history` LIMIT 60000,5000;
Device:

Code Auswählen Erweitern

Internals:
   DATABASE   fhem
   DEF        logdb
   FUUID      5c52f431-f33f-e11d-c0b2-f1dc4dfa79b37156
   FVERSION   93_DbRep.pm:v8.47.0-s25492/2022-01-17
   LASTCMD    dumpMySQL clientSide
   MODEL      Client
   NAME       repdb
   NOTIFYDEV  global,repdb
   NR         436
   NTFY_ORDER 50-repdb
   ROLE       Client
   STATE      clientSide Dump is running - be patient and see Logfile !
   TYPE       DbRep
   UTF8       1
   HELPER:
     DBLOGDEVICE logdb
     IDRETRIES  3
     PACKAGE    main
     VERSION    8.47.0
     RUNNING_BACKUP_CLIENT:
       abortFn    DbRep_DumpAborted
       bc_pid     150
       finishFn   DbRep_DumpDone
       fn         DbRep_mysql_DumpClientSide
       loglevel   5
       pid        5340
       telnet     telnetForBlockingFn_1643544554_127.0.0.1_56806
       timeout    86400
       abortArg:
       arg:
         name       repdb
         table      history
         hash:
   OLDREADINGS:
   READINGS:
     2022-01-30 13:17:24   state           clientSide Dump is running - be patient and see Logfile !
Attributes:
   DbLogExclude .*
   DbLogInclude DumpRowsHistory
   aggregation hour
   allowDeletion 1
   dumpDirLocal backup
   dumpMemlimit 500000000
   dumpSpeed  5000
   event-on-update-reading state,DumpRowsHistory
   group      DbLog
   room       Technik->Funktionen
   seqDoubletsVariance 0.15
   showTableInfo %history%,%current%
   timeDiffToNow d:70
   timeOlderThan d:62
   verbose    4

[DS_Starter]

Sieht doch gut aus. Die SQL zeigen den Fortschritt:

Code Auswählen Erweitern


2022.01.30 13:17:33 4: DbRep repdb - SQL execute: SELECT * FROM `history` LIMIT 0,5000;
2022.01.30 13:17:33 4: DbRep repdb - SQL execute: SELECT * FROM `history` LIMIT 5000,5000;
2022.01.30 13:18:15 4: DbRep repdb - SQL execute: SELECT * FROM `history` LIMIT 10000,5000;
2022.01.30 13:19:31 4: DbRep repdb - SQL execute: SELECT * FROM `history` LIMIT 15000,5000;
2022.01.30 13:21:17 4: DbRep repdb - SQL execute: SELECT * FROM `history` LIMIT 20000,5000;
2022.01.30 13:23:33 4: DbRep repdb - SQL execute: SELECT * FROM `history` LIMIT 25000,5000;
2022.01.30 13:26:19 4: DbRep repdb - SQL execute: SELECT * FROM `history` LIMIT 30000,5000;
2022.01.30 13:29:36 4: DbRep repdb - SQL execute: SELECT * FROM `history` LIMIT 35000,5000;
2022.01.30 13:33:22 4: DbRep repdb - SQL execute: SELECT * FROM `history` LIMIT 40000,5000;
2022.01.30 13:37:39 4: DbRep repdb - SQL execute: SELECT * FROM `history` LIMIT 45000,5000;
2022.01.30 13:42:25 4: DbRep repdb - SQL execute: SELECT * FROM `history` LIMIT 50000,5000;
2022.01.30 13:47:42 4: DbRep repdb - SQL execute: SELECT * FROM `history` LIMIT 55000,5000;
2022.01.30 13:53:29 4: DbRep repdb - SQL execute: SELECT * FROM `history` LIMIT 60000,5000;


Das Ausgabefile sollte auch entsprechend wachsen.

[Didi]

nein leider wächst das File nicht.

[DS_Starter]

Hmm, komisch. Bei mir läufts grad parallel astrein.

Lass es erstmal laufen. Ich schau mal ob ich etwas bei der Optimierung übersehen habe.

Achso, zieh dir mal die aktuellste Entwicklungsversion wie gerade oben geschrieben. Und starte damit nochmal den Dump.

[Didi]

Hallo Heiko,

mit der Version 93_DbRep.pm:v8.47.0-s25492/2022-01-17 habe ich leider das gleiche Problem.
Ich habe mal mit ein paar Einstellungen experimentiert, wenn ich dumpMemlimit ud dumpSpeed drastisch reduziere wird zwar das Ausgabefile geschrieben aber die Performance ist unterirdisch.
Nach 30 Minuten noch nicht mal die Hälfte der zu erwartende Größe.
Ich habe auch die Beobachtung gemacht, das die Abstände der SQL Aufrufe

SQL execute: SELECT * FROM `history` LIMIT 0,50000;

immer länger werden, von anfänglich Sekunden bis zu mehreren Minuten.

Vielleicht hilft dir das ja bei der Fehlersuche.

[DS_Starter]

Und wie sieht es mit der aktuellen Entwicklungsversion aus ? Wäre mir noch wichtig zu wissen.

[Didi]

Ich dachte die 93_DbRep.pm:v8.47.0-s25492/2022-01-17 wäre die aktuellen Entwicklungsversion.
Ich hatte

"wget -qO ./FHEM/93_DbRep.pm https://svn.fhem.de/fhem/trunk/fhem/contrib/DS_Starter/93_DbRep.pm"

schon mal ausgeführt, scheint nicht geklappt zu haben. Werde es noch mal versuchen.

[DS_Starter]

Ist diese:

FVERSION 93_DbRep.pm:v8.48.0-s25492/2022-01-17