dblog eingerichtet und loggt auch - aber irgendwann zerschiesst es die Datenbank

[wowogiengen]

Hallo,
ich habe das dblog nach Anleitung eingerichtet, und mit filelogconverter meine Logs von 2018 begonnen zu importieren.
Aber irgendwie zerschiesst es mir immer die Datenbank (nach dem das Konvertieren aber bereits abgeschlossen ist!):
z.B.:

Code Auswählen Erweitern

DBD::SQLite::st execute failed: database disk image is malformed at ./FHEM/93_DbRep.pm line 4910

Muss man beim Einsatz der Module irgendwas beachten? Anhalten des Loggings, wenn mit filelogconvert was eingelesen wird? Oder mit dbreport die Datenbank gedumpt wird?

Im Prinzip tut ja alles, aber so kann ich das Dblog nicht verwenden...
Viele Grüße
Wolfgang

[DS_Starter]

Hallo Wolfgang,

du setzt SQLite ein. Diese DB verträgt parallele Schreibprozesse nicht so gut.

Wenn du FileLogConvert zum Import von Filelogdaten verwendest, solltest du während dieser Zeit DbLog nicht in die DB schreiben lassen.
Das geht einfach mit

Code Auswählen Erweitern

set dblog reopen <Zeit>

Während der Zeit kannst du den Import durchführen.
Events schreibt Dblog nach Ablauf der Zeit in die DB sofern du DbLog im asynchronen Modus betreibst.

Wenn du einen Dump mit DbRep machst brauchst du nichts zu beachten, da das Modul extra eine Online-API verwendet die eine Erstellung eines Backup im geöffneten Zustand erlaubt.
Bei SQLite kann "database disk image is malformed" allerdings auch durch andere Umstände eintreten, siehe hier : https://www.sqlite.org/howtocorrupt.html

Im DbRep gibt es eine Reparaturoption:

Code Auswählen Erweitern

set dbrep repairSQLite

die man ausprobieren kann um die DB in diesem Fall zu reparieren. siehe commandref DbRep.

Um näheres dazu sagen zu können, müsstest du versuchen zu ergründen ob irgendein Zusammenhang der Korruption mit einer durchgeführten Operation zu erkennen ist.
Meine Test-SQLite die ständig mitläuft ist inzwischen 2,3 GB groß und ich habe schon sehr lange kein malformed mehr erlebt.
Ich hatte diesen Fehler öfter als ich testweise das SQLite-File auf einem Netzwerk-Share erstellt hatte Ich wollte einfach wissen wie gut das funktioniert.

Grüße
Heiko

[wowogiengen]

Hallo Heiko,
wenn ich

Code Auswählen Erweitern

set dblog reopen <Zeit>
benutze, werden dann die Grenzen fürs Caching eingehalten, oder wird solange gecached, bis die Zeit für den reopen abgelaufen ist?

Ich würde nämlich schon gerne alle meine FileLogs importieren und weiter verwenden.
Wenn du schreibst, dass deine DB 2,3GB groß ist, dann löscht du alte Dinge nicht aus der DB raus?
Und in meinem Fall könnte ich dann auch alle Logeinstellungen so belassen wie bisher (also quasi .*:.*) - momentan habe ich es beschränkt auf

Code Auswählen Erweitern

Rolladen.*:.*|Hzg.*:.*|PWMR.*:.*

Viele Grüße und Danke

Wolfgang

[DS_Starter]

werden dann die Grenzen fürs Caching eingehalten, oder wird solange gecached, bis die Zeit für den reopen abgelaufen ist?

Das letztere Wolfgang. Es wird gecached bis die DB wieder verfügbar ist.

Wenn du schreibst, dass deine DB 2,3GB groß ist, dann löscht du alte Dinge nicht aus der DB raus?

Es ist meine Test-DB. Die nutze ich inbesondere für die Entwicklungen und darauf aufbauenden Tests mit SQLite.
Da fliegt auch mal was raus, aber ich bin da nicht so kleinlich, habe genügend Platz.

Anders ist es auf meinem Produktivsystem. Dort arbeite ich ausschließlich mit zwei MariaDB auf meiner remoten Synology. Eine DB für Loggings die ich nur kurz (180 Tage) behalten will und eine zweite, die die Einträge ohne Zeitbeschränkung enthält (Energiedaten PV-Anlage usw.). Diese zweite DB hat inzwischen auch ca. 2,5 GB Größe. Dabei achte ich schon darauf dass nur die Daten geloggt werden die ich in irgendeiner Weise auch auswerten will.

Noch ein Hinweis.
Im DBRep gibt es zwei Attribute executeBeforeProc, executeAfterProc die dazu genutzt werden können, um bei bestimmten Aufgaben vor der Abarbeitung und danach FHEM/Perl-Kommandos abzuarbeiten.
Also zum Beispiel ein "set dblog reopen 3600" bzw. "set dblog reopen", um vor einer Tabellenoptimierung mit "set dbrep vacuum" die Datenbank für DbLog zu schließen und danach wieder zu öffnen.

viele Grüße,
Heiko

[wowogiengen]

Hallo,
welches Modul erzeugt mir jetzt jede Stunde ein komplett-Backup der FHEM-Installation? Gibt jedesmal 120MB, wenn das so weitergeht, wird meine SD-Card voll...
VG
Wolfgang

[DS_Starter]

Hallo Wolfgang,

das ist jetzt wohl ein anderes Thema ... bitte neuen Thread aufmachen 

Da wirst du wohl auch nicht drumrum kommen ein paar mehr Infos deines Systems zu liefern ...

Grüße,
Heiko

[wowogiengen]

Ich glaube nicht, dass es ein neues Thema ist.
Das passiert erst seit ich dblog, dbrep und FileLogConvert aktiviert / in Gebrauch habe...

Viele Grüße
Wolfgang

[DS_Starter]

Hallo Wolfgang,

dann solltest du zumindest den Titel ändern !

Nun ja, keines der Module macht selbständig etwas ... außer loggen natürlich.
Und wenn du schreibst es passiert jede Stunde ein Backup deines Gesamtsystems, hat das nichts mit der DB zu tun, oder ?

Wenn es regelmäßig jede Stunde passiert, hilft vielleicht ein

Code Auswählen Erweitern

list TYPE=at

weiter wenn du die Devices durchsiehst und schaust was denn jede Stunde gestartet wird.

Grüße,
Heiko

[wowogiengen]

Hallo Heiko,
jetzt hab ich den Übeltäter gefunden...
War ein von mir zu Testzwecken eingerichtetes notify:
hier das list ntest

Code Auswählen Erweitern


Internals:
   CFGFN     
   DEF        AlleRolladen:.*|HzgAktorBad:.*|a b
   NAME       ntest
   NR         476
   NTFY_ORDER 50-ntest
   REGEXP     AlleRolladen:.*|HzgAktorBad:.*|a
   STATE      2018-04-09 22:27:38
   TYPE       notify
   READINGS:
     2018-04-09 22:27:32   state           active
Attributes:



Wenn ich mich nicht irre, dann ist hierbei "b" der Befehl, welcher ausgeführt wird?
Aber wieso b = backup?

Viele Grüße
Wolfgang...

PS.: Nach deiner Antwort schliessen wir den OT-Teil ab, denke ich...

[Edit]: habe tatsächlich mal nur b als Kommando eingegeben, und schon wird ein backup erstellt.
Und je mehr b in den Events, desto mehr backup...?

[DS_Starter]

Code Auswählen Erweitern

jetzt hab ich den Übeltäter gefunden...


Also ich kann jetzt nur mutmassen. Wenn dort nur "b" steht, und ich glaube es dir natürlich, dann könnte es sein dass du dir vielleicht ein commandalias "b" eingerichtet hast. Dort steht dann der tatsächliche fhem-Befehl drin.
Naja und je öfter das Notify zuschlägt, dest öfter hast du ein Backup.

Das wäre jetzt mal meine, für mich wahrscheinliche, Erklärung.

Grüße
Heiko

[stefanpf]

Das ist ja drollig,
b legt bei mir ebenfalls ein Backup an,
genau so wie "ba", "bac", ...

genauso steht "s" für save, "u" für update, quasi eine Befehlszeilenergänzung ohne Tab

[helmut]

In der fhem-Doku habe ich zwar nichts dazu gefunden, aber das Zulassen von Abkuerzungen bei Eindeutigkeit ist
doch nichts Besonderes. Das Linux Kommando "ip" ist ein schoenes Beispiel, wenn auch mit umgekehrten Vorzeichen.

"ip address show" kann ich auch als "ip a s" schreiben.

Bei fhem kann ich das Kommando abkuerzen, nicht aber die Parameter.

Wer oft mit der Kommandozeile arbeitet, weiss diese Abkuerzungen zu schaetzen.

Gruss Helmut

[wowogiengen]

Hallo,
wenn man weiß, was passiert, dann ist man beruhigt.
Mein Beispiel mit dem notify hab ich irgendwo rauskopiert, wegen der RegEx für die Geräte... Dass dann ein backup ausgeführt wird (wegen der Abkürzung), wenn das notify triggert, war mir bisher nicht bekannt.

Könnte man in die FHEM-Doku mit aufnehmen (zumal nicht alle Nutzer in der Linux-Welt unterwegs sind).

VG
Wolfgang

[helmut]

Mein Beispiel mit dem notify hab ich irgendwo rauskopiert, wegen der RegEx für die Geräte... Dass dann ein backup ausgeführt wird (wegen der Abkürzung), wenn das notify triggert, war mir bisher nicht bekannt.

Hallo Wolfgang,

etwas zu kopieren, nicht zu wissen, was da passiert und dann im Betrieb zu benutzen, ist _immer_ eine ganz
schlechte Idee.

Könnte man in die FHEM-Doku mit aufnehmen (zumal nicht alle Nutzer in der Linux-Welt unterwegs sind).

Ob das hilft? Ich wage zu behaupten, dass nein.  Aber Du kannst es mit diesem Ansinnen ja mal bei Rudi versuchen.

Gruss Helmut