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

[DS_Starter]

Hallo Wolfgang,

ich habe das mal bei mir nachvollzogen.
Ich habe eine SQLite-DB in /opt. Sie heißt fhem.db. Von dieser ziehe ich täglich Backups.
Das letzte Backupfile heißt: fhem_2018_06_22_17_25.sqlitebkp.gzip (Ordner /sds1/backup/dumps_FHEM)

Das dazugehörige DbRep-Device ist so definiert:

Code Auswählen Erweitern

defmod Rep.SQLite.Backup DbRep LogSQLITE
attr Rep.SQLite.Backup allowDeletion 1
attr Rep.SQLite.Backup devStateIcon connected:10px-kreis-gelb .*disconnect:10px-kreis-rot .*done:10px-kreis-gruen
attr Rep.SQLite.Backup disable 0
attr Rep.SQLite.Backup dumpCompress 1
attr Rep.SQLite.Backup dumpDirLocal /sds1/backup/dumps_FHEM
attr Rep.SQLite.Backup dumpFilesKeep 1
attr Rep.SQLite.Backup event-on-update-reading state
attr Rep.SQLite.Backup ftpDir /ftp
attr Rep.SQLite.Backup ftpDumpFilesKeep 1
attr Rep.SQLite.Backup ftpPwd ftpftp1
attr Rep.SQLite.Backup ftpServer sds1.myds.me
attr Rep.SQLite.Backup ftpUse 0
attr Rep.SQLite.Backup ftpUser ftpuser
attr Rep.SQLite.Backup optimizeTablesBeforeDump 0
attr Rep.SQLite.Backup room DbLog
attr Rep.SQLite.Backup showproctime 1
attr Rep.SQLite.Backup verbose 3

setstate Rep.SQLite.Backup Database backup finished
setstate Rep.SQLite.Backup 2018-06-22 17:27:21 DumpFileCreated /sds1/backup/dumps_FHEM/fhem_2018_06_22_17_25.sqlitebkp.gzip
setstate Rep.SQLite.Backup 2018-06-22 17:27:21 DumpFileCreatedSize 485.18 MB
setstate Rep.SQLite.Backup 2018-06-22 17:27:21 DumpFilesDeleted fhem_2018_06_21_17_25.sqlitebkp.gzip
setstate Rep.SQLite.Backup 2018-06-22 17:27:21 DumpRowsCurrent n.a.
setstate Rep.SQLite.Backup 2018-06-22 17:27:21 DumpRowsHistory n.a.
setstate Rep.SQLite.Backup 2018-06-22 17:27:21 background_processing_time 141.2785
setstate Rep.SQLite.Backup 2018-06-22 17:27:21 state Database backup finished

Für den Restore-Test habe ich in /opt eine Sqlite-DB mit dem Namen fhem1.db angelegt. Mit dem DEF "./db_sqlite1.conf aaaa:bbbbb" im
DbLog-Device wird nichts geloggt. Die Rechte der DB habe ich so gesetzt:

Code Auswählen Erweitern


sudo chmod 664 /opt/fhem1.db
stehen also auf: -rw-rw-r--   fhem dialout

 
Nun habe ich noch ein DbRep-Device für den Resore angelegt. Das ist so definiert:

Code Auswählen Erweitern


defmod Rep.SQLite1.Restore DbRep LogSQLITE1
attr Rep.SQLite1.Restore aggregation no
attr Rep.SQLite1.Restore allowDeletion 1
attr Rep.SQLite1.Restore devStateIcon connected:10px-kreis-gelb .*disconnect:10px-kreis-rot .*done:10px-kreis-gruen
attr Rep.SQLite1.Restore disable 0
attr Rep.SQLite1.Restore dumpDirLocal /sds1/backup/dumps_FHEM
attr Rep.SQLite1.Restore dumpFilesKeep 1
attr Rep.SQLite1.Restore event-on-update-reading state
attr Rep.SQLite1.Restore executeAfterProc set LogSQLITE1 reopen
attr Rep.SQLite1.Restore executeBeforeProc set LogSQLITE1 reopen 3600
attr Rep.SQLite1.Restore room DbLog
attr Rep.SQLite1.Restore showproctime 1
attr Rep.SQLite1.Restore verbose 3

Damit der Cross-Restore funktioniert habe ich das bestehende BackupFile kopiert:

Code Auswählen Erweitern

cp /sds1/backup/dumps_FHEM/fhem_2018_06_22_17_25.sqlitebkp.gzip /sds1/backup/dumps_FHEM/fhem1_2018_06_22_17_25.sqlitebkp.gzip

Das File muß mit "fhem1" beginnen, weil die Zieldatenbank so heißt und das File sonst vom DbRep nicht gefunden wird (Feature).
Den Restore habe ich nun mit dem "Rep.SQLite1.Restore"-Device gestartet.
Das ca. 3GB große Backupfile mit rund 15 Mio Datensätzen wurde in rund 440 Sekunden reingefahren.

Hier das Log noch dazu:

Code Auswählen Erweitern

2018.06.23 15:21:40.137 3: DbRep Rep.SQLite1.Restore - ################################################################
2018.06.23 15:21:40.138 3: DbRep Rep.SQLite1.Restore - ###             New database Restore/Recovery                ###
2018.06.23 15:21:40.139 3: DbRep Rep.SQLite1.Restore - ################################################################
2018.06.23 15:21:40.140 3: DbRep Rep.SQLite1.Restore - execute command before restore: 'set LogSQLITE1 reopen 3600'
2018.06.23 15:21:40.144 2: DbLog LogSQLITE1: Connection closed until 16:21:40 (3600 seconds).
2018.06.23 15:21:40.166 3: DbRep Rep.SQLite1.Restore - uncompress file /sds1/backup/dumps_FHEM/fhem1_2018_06_22_17_25.sqlitebkp.gzip
2018.06.23 15:22:34.630 3: DbRep Rep.SQLite1.Restore - file uncompressed to output file: /sds1/backup/dumps_FHEM/fhem1_2018_06_22_17_25.sqlitebkp
2018.06.23 15:22:34.645 3: DbRep Rep.SQLite1.Restore - Size of uncompressed file: 3236.36 MB
2018.06.23 15:22:34.646 3: DbRep Rep.SQLite1.Restore - Starting restore of database 'fhem1.db'
2018.06.23 15:29:09.218 3: DbRep Rep.SQLite1.Restore - Restore of /sds1/backup/dumps_FHEM/fhem1_2018_06_22_17_25.sqlitebkp into 'fhem1.db' finished - total time used: 449 seconds.
2018.06.23 15:29:09.227 3: DbLog LogSQLITE1: Reopen requested.
2018.06.23 15:29:09.228 3: DbLog LogSQLITE1 - Creating Push-Handle to database SQLite:dbname=/opt/fhem1.db with user
2018.06.23 15:29:09.240 3: DbLog LogSQLITE1 - Push-Handle to db SQLite:dbname=/opt/fhem1.db created
2018.06.23 15:29:09.249 2: DbRep Rep.SQLite1.Restore - command message after restore: "Reopen executed."
2018.06.23 15:29:09.254 3: DbRep Rep.SQLite1.Restore - Database restore finished successfully.

Hat also so geklappt wie es soll.
Das hilft dir jetzt wahrscheinlich noch nicht weiter, aber ich konnte deinen Fehler bei mir nicht nachvollziehen, was auch unschön ist.
Hast du mal Google befragt ? Ich denke mal noch etwas darüber nach.
Je nachdem wie groß dein File ist kannst du es vllt. mal bei Dropbox ablegen. Dann könnte ich es mal bei mir probieren, falls dir das recht sein sollte.

LG,
Heiko

[DS_Starter]

Hallo Wolfgang,

habe mal schnell die SuFu angeworfen und gefunden:

2
down vote

In Linux command shell, I did:

chmod 777 <db_folder>

Where contains the database file.

It works. Now I can access my database and make insert queries.

aus: https://stackoverflow.com/questions/1518729/change-sqlite-database-mode-to-read-write

Grüße
Heiko

[pechnase]

Hallo Heiko,
herzlichen Dank für die schnelle und professionelle Hilfe. Da bekommt man ja schon fast ein schlechtes Gewissen für die Zeit, die Du da investiertst.
Das Verzeichnis hatte ich schon auf 777 eingestellt, was aber nicht von Erfolg beschieden war. Ich hatte auch noch ein paar andere DbRep auf die Datenbank definiert, die als Status 'connected' angezeigt haben. Die habe ich über das Attribut 'disable 1' jetzt alle mal vorsichtshalber disabled, nicht dass es da irgend welche Nebeneffekte gibt. Aber auch das hat an der Situation nichts geändert.

Auf dem System gibt es zwei defines für DbLog (unterschiedliche Datenbanken). Könnte das noch ein Problem sein?

Ich hätte jetzt kein Problem, Dir das Backup der Datenbank auf Dropbox hochzuladen. Also wenn Du die Zeit wirklich spendieren möchtest, kannst Du mir den Dropbox Link schicken. Ich vertraue Dir, dass die Daten in Deiner Hand bleiben.

Viele Grüße
Wolfgang

[DS_Starter]

Hallo Wolfgang,

Auf dem System gibt es zwei defines für DbLog (unterschiedliche Datenbanken). Könnte das noch ein Problem sein?

Nein, kann ich mir nicht vorstellen. Das sind andere Handles.

Ist das dazugehörige DbLog auf asynchron eingestellt ? Wenn nicht, könnte das ein Problem sein.

Ich hätte jetzt kein Problem, Dir das Backup der Datenbank auf Dropbox hochzuladen. Also wenn Du die Zeit wirklich spendieren möchtest, kannst Du mir den Dropbox Link schicken. Ich vertraue Dir, dass die Daten in Deiner Hand bleiben.

Die Daten werde ich nach dem Test natürlich wieder löschen. Einen Versuch wäre es wert.

Ich habe auf meinem Testsystem 6 Datenbanken mit den dazu gehörigen DbLogs drauf und vielleicht 40 DbReps. Gegen die zu restorende DB arbeiten 2 DbReps und hat auch nicht gestört.

Grüße,
Heiko

[pechnase]

Hallo Heiko,
jetzt bin ich einen anderen Weg zur Rettung der Daten gegangen.

Nachdem ich irgendwo im WEB gelesen habe, dass man das sqlite-backup als DB mit sqlite3 auf der Kommandozeile öffnen kann, habe ich das versucht und das hat auch geklappt.
Dann auf der sqlite-Kommandozeile pragma integrity_check ausgeführt und siehe da, das Backup hatte einige Fehler. Dann wie im DbLog-Wiki beschrieben, einen kompletten sql-Dump der DB gemacht und alle weiteren Schritte, wie im Wiki beschrieben, durchgeführt. Also neue DB mit .read aus dem sql-Dump befüllen. sqlite verlassen, DB umbenennen, Rechte und Owner anpassen.
Dann wieder fhem gestartet und testweise mit DbRep ein backup -> restore durchgeführt. Das hat jetzt funktioniert. Ich schließe daraus, dass DbRep restore mit der korrupten DB ein Problem hatte und es deshalb nicht auf dem direkten Weg, wie wir ihn heute Nachmittag diskutiert haben, funktioniert hat.
Erste Daten habe ich jetzt mit DbRep export als .csv gesichert um diese dann in die originale DB wieder einlesen zu können. Ich bin mir sicher, dass ich damit dann alle Daten wieder herstellen kann.

Falls Du das defekte backup, bei dem immer der Fehler

Code Auswählen Erweitern

DBD::SQLite::db sqlite_backup_from_file failed: sqlite_backup_from_file failed with error attempt to write a readonly database at ./FHEM/93_DbRep.pm line 6902.\ aufgetreten ist, für einen Test haben möchtest, kann ich es Dir schicken.

Also nochmals herzlichen Dank für die Unterstützung. Ich hoffe, dass ich so schnell nicht wieder eine defekte DB habe.

Viele Grüße
Wolfgang

[DS_Starter]

Na das ist doch eine gute Nachricht.

Ich schließe daraus, dass DbRep restore mit der korrupten DB ein Problem hatte und es deshalb nicht auf dem direkten Weg, wie wir ihn heute Nachmittag diskutiert haben, funktioniert hat.

Nicht ganz. DbRep verwendet eine von SQLite bereit gestellte Funktion zum Restore. Die meldet diesen Fehler und DbRep schiebt ihn durch.

Die Daten brauche ich dann nicht mehr denke ich.
Na dann viel Glück beim weiteren Loggen 

Grüße
Heiko

[supergrobi]

Hallo Forum,

als Anfänger benötige ich bitte noch mal eure Hilfe...
Wenn ich das DBReporting tool als SQL Abfrage benutze, kann ich mir z.B. mit

Code Auswählen Erweitern

set DBReporting sqlCmd select MAX(CAST(VALUE AS double)) from history where device = 'LaCrosse_3E' and READING = 'temperature' and TIMESTAMP like '2018-05%';

...die maximale Außentemperatur vom Monat Mai Anzeigen lassen.
Als Ergebnis kommt dann
SqlResultRow_1    35.5

Soweit alles gut. Jetzt aber die Anfängerfrage:
Wie kann ich diesen Wert jetzt einem Dummy zuweisen, das ich mir das täglich berechnen und in die DB speichern kann...? ALso sozusagen einen Watchdog ala

Code Auswählen Erweitern

define sun_riseSet_timer at *03:00:00 { my $s = sunrise("REAL");; fhem("set Sonnenaufgang $s");; $s = sunset("REAL");; fhem("set Sonnenuntergang $s");; }


ist das machbar?

lg
Thomas

[DS_Starter]

Hallo Thomas,

ja, ist machbar. Es gibt mindestens zwei Varianten. Eine ist im Wiki beschrieben: https://wiki.fhem.de/wiki/DbRep_-_Reporting_und_Management_von_DbLog-Datenbankinhalten

Die andere Variante betrifft die Verwendung des Attr userExitFn. Dafür muss man etwas selbst programmieren, kann dadurch aber mehr.
Schau im Wiki ma! zuerst.

EDIT:
Eine weitere Variante ohne Umwege könnte folgende sein. Setze dir im DbRep die Attribute:

Code Auswählen Erweitern


device = LaCrosse_3E
reading = temperature
timestamp_begin = current_month_begin
timestamp_end = current_month_end
aggregation = month


Dann könntest du:

Code Auswählen Erweitern


set <DbRep> maxValue writeToDb

regelmäßig laufen lassen um den Maximalwert des aktuelle Monats immer in die DB schreiben zu lassen. Ist bereits ein Wert in der DB, wird er aktualisiert.
Der Maximalwert wird für das Device "LaCrosse_3E" mit dem neuen Readingnamen "max_month_temperature" in die DB geschrieben.

Lg
Heiko

[supergrobi]

Hallo Heiko,

danke für die Hilfe. Ich werde mich die Tage dann mal durch das Wiki kämpfen. beim überfliegen hab ich es noch nicht verstanden.
dein Beispiel hier hat auch nicht das gewünschte ergebnis gebracht. Zumindest wird kein Reading im LaCrosse eingetragen...
Wenn ich hinterher eine Abfrage der DB mache (select * from history where device = 'LaCrosse_3E' and reading like 'max%' and Timestamp like '201%';)
liefert er 0 Ergebnisse
Attribute:

Code Auswählen Erweitern


aggregation = day
device = LaCrosse_3E
reading = temperature
timestamp_begin = 2018-07-07 00:00:00
timestamp_end = 2018-07-08 00:00:00


Mein Gedanke, oder mein wunsch ist eigentlich für viele verschiedene Devices eine Min/Max/AVG Temperatur für Tag/Monat abzuspeichern.
Ebenso für Stromverbrauch einen Max...

Gruß
Thomas

[DS_Starter]

Hallo Thomas,

hier nochmal der Link für den konkreten Abschnitt: https://wiki.fhem.de/wiki/DbRep_-_Reporting_und_Management_von_DbLog-Datenbankinhalten#Reading_von_DbRep_nach_Dummy_.C3.BCbertragen

Das ging vorhin in der Kürze nicht.

Wenn du verbose 4 im DbRep einstellst siehst du wenn/welches Ergebnis mit "set <DbRep> maxValue writeToDb" abgespeichert wird.
Schau nochmal bzw. poste mal was da kommt.

Mein Gedanke, oder mein wunsch ist eigentlich für viele verschiedene Devices eine Min/Max/AVG Temperatur für Tag/Monat abzuspeichern.
Ebenso für Stromverbrauch einen Max...

Ja, so etwas ähnliches mache ich auch. Ich benutze mehrere DbReps um die Summenwerte der Energieverbräuche/Erzeugung zu ermitteln und per Readingsgroup darzustellen.
siehe Anhang

[pechnase]

Hallo Heiko,

nach unserer letzten Konversation in diesem Thread im Juni bezüglich retten von Daten aus einer korrupten SQLITE DB habe ich mir mit DOIF einen E-Mail Alarm eingerichtet, der alarmiert, wenn der DB Zustand 'connected' verlassen wird.

Eine Änderung von 'connected' zu einem anderen Zustand tritt geplant ein, wenn ich vor dem nächtlichen Backup ein reopen xxxxsec absetze, dann ist die DB im Zustand 'closed' bzw. in 'reopen' nach dem Backup und dann wieder in 'connected'. Das ist für mich schlüssig.
Zu einem anderen regelmäßigen Zeitpunkt in der Nacht, wenn ich Einträge älter als 31 bzw. 10 Tage weglösche ändert sich der Zustand in 'Commit already running - resync at NextSync'. Das könnte ich wahrscheinlich vermeiden, wenn ich vor den Löschaktionen auch ein reopen xxxxsec einfügen würde.

Was mich aber eigentlich verunsichert ist, dass zu beliebigen Zeitpunkten die DB immer mal wieder in den Zustand 'Commit already running - resync at NextSync' geht. Ich habe jetzt im Forum schon gesucht und auch im WEB gegoogelt, aber noch nichts gefunden, wo ich sagen würde, das beschreibt mein Problem.
Woher kommt der Zustand 'Commit already running - resync at NextSync' , ist das 'gefährlich' oder gibt es eine Abhilfe dafür?

Danke schon mal für eine Erklärung.

Viele Grüße
Wolfgang

[DS_Starter]

Hallo Wolfgang,

Zu einem anderen regelmäßigen Zeitpunkt in der Nacht, wenn ich Einträge älter als 31 bzw. 10 Tage weglösche ändert sich der Zustand in 'Commit already running - resync at NextSync'. Das könnte ich wahrscheinlich vermeiden, wenn ich vor den Löschaktionen auch ein reopen xxxxsec einfügen würde.

Ja, genau. Wenn du das machst, wäre für DbLog von vornherein klar, dass es momentan keine Schreibaktion auf der DB ausführen soll.

Was mich aber eigentlich verunsichert ist, dass zu beliebigen Zeitpunkten die DB immer mal wieder in den Zustand 'Commit already running - resync at NextSync' geht.....Woher kommt der Zustand 'Commit already running - resync at NextSync' , ist das 'gefährlich' oder gibt es eine Abhilfe dafür?

Grundsätzlich ist die Meldung 'Commit already running - resync at NextSync' erstmal nichts gefährliches.
Sie beschreibt den Zustand, dass ein Schreibzyklus in die DB stattfinden soll (z.B. durch erreichen syncInterval oder cacheLimit), aber bereits ein Schreibzyklus läuft der noch nicht abgeschlossen ist.
Dann passiert nichts anderes, als das die Daten weiterhin im Cache bleiben und nach einer gewissen Periode wieder versucht wird in die DB zu schreiben.
Wenn das also "immer mal" passiert, ist das nichts gravierendes, wenn es über einen längeren Zeitraum permanent in dem Zustand bleibt, sollte man sich mal darum kümmern.

Im Grunde kann sowas passieren wenn deine DB relativ langsam im Vergleich zu deinem eingestellten syncInterval (cacheLimit) ist, oder aber ein anderer Prozess temporär ein Schreiben verhindert weil der die Tabelle history gerade sperrt. Zum Beispiel beim Löschen von Daten oder Tabellenreorganisation (vacuum).

D.h. DbLog will seine Daten schreiben und startet den Hintergrundprzess dafür, der muss im Hintergrund warten weil die history Tabelle gerade nicht beschrieben werden kann (warum auch immer) ... in der Zwischenzeit wird SyncInterval/cacheLimit erreicht und der nächste Schreibprozess will starten und kann es nicht weil der Vorherige noch läuft --->  dann wird die Meldung 'Commit already running - resync at NextSync'  generiert !

Ich hoffe der Zusammenhang wurde jetzt ein bisschen klarer.

LG,
Heiko

[pechnase]

Hallo Heiko,

danke für die, wie immer, fixe Antwort auf meine Frage. Zu dem einen Fall habe ich jetzt das executeBefore und executeAfter Attribut gesetzt. Mal sehen was heute Nacht dann gemeldet wird.
Für die sporadischen 'Commit already running - resync at NextSync' habe ich jetzt mal versuchsweise syncInterval von 30 auf 60 abgeändert. Der Fall kommt so 0 - 4 mal in 24h vor.

Viele Grüße
Wolfgang

[supergrobi]

Hallo Heiko,

wieder einmal Danke für die schnelle Hilfe. Leider ist es wieder komplizierter, oder ich stell mich wieder zu blöd dazu an...

Code Auswählen Erweitern


define Energy.Tag.Kuehlschrank dummy
attr Energy.Tag.Kuehlschrank room Energy

define N.Energy.Tag.Kuehlschrank notify DBReporting:(\d).*Grid.* { fhem "setreading Energy.Tag.Kuehlschrank".(split(":",$EVTPART0))[0]." $EVTPART1"}
attr N.Energy.Tag.Kuehlschrank room Energy

dies sind mein angelegtes Test-Dummy und dazu das notify.
So wie ich das verstehe, sollte doch jetzt alles an Readings, das beim Aufruf von DBReporting (DBRep heißt bei mir so) erscheint, auf das Dummy übertragen werden. So also bei

Code Auswählen Erweitern

set DBReporting sqlCmd select MAX(VALUE) from history where DEVICE = "FBDECT_fbahahttp_08761_0044555" AND TIMESTAMP like "2018-07-09%" AND READING = "energy";

sollte er den W/h Zähler auf das Dummy übetragen... oder ?

weil es passiert nix.

im DBReporting werden die Readings erzeugt:
Readings

SqlResultRow_1 423962 2018-07-11 11:15:31
sqlCmd select MAX(VALUE) from history where DEVICE = "FBDECT_fbahahttp_08761_0044555" AND TIMESTAMP like "2018-07-09%" AND READING = "energy"; 2018-07-11 11:15:31
sqlResultNumRows 1 2018-07-11 11:15:31
state done 2018-07-11 11:15:31

aber im dummy ist nix.

was mache ich falsch?

gruß
Thomas

[DS_Starter]

du triggerst dein notify auf DBReporting:(\d).*Grid.* , aber dein Reading / Event heisst doch SqlResultRow_1 ?!
bin grad unterwegs, deswegen kurz und knapp.

lg