DBLog,sqlite DB defekt, zum zweiten mal

[franky08]

Komme eben von der Arbeit und musste feststellen das seit ca. 12:30 Uhr keinerlei Daten mehr in die sqlite Datenbank geloggt wurden. Also auf der Konsole nachgesehen und festgestellt das keine tables mehr vorhanden sind 
Das ist mir nun schon 2 mal, innerhalb von 3 Jahren, passiert. Als Konsequenz werde ich sämtliche Log's wieder auf Filelog umstellen. Es ist mehr als ärgerlich wenn sämtliche statistische Jahresplots/Daten flöten gehen. Habe jetzt erst einmal eine neue DB erstellt, die funktioniert auch. Betroffen war nur die allgemeine fhem.db, die esa2000.db, welche die Energiewerte loggt war zum Glück nicht betroffen.
Hat jemand einen Tipp wie dieser crash passieren konnte? Es war zu dieser Zeit niemand in der Wohnung und an fhem wurde zu der Zeit auch nicht's gearbeitet/geändert.

VG
Frank

[Ellert]

Hatte ich auch gerade zum ersten Mal. Nach einem Stromausfall gestern Morgen, kamen viele Fehlermeldungen und etwa 7 Stunden später, war die Datenbank hin.

2016.09.08 16:58:05.661 2: DbLog: Failed to insert new readings into database: DBD::SQLite::st execute failed: database disk image is malformed at ./FHEM/93_DbLog.pm line 613, <GEN17> line 127.

Kann man die Datenbank irgendwie retten?

[Benni]

Es ist mehr als ärgerlich wenn sämtliche statistische Jahresplots/Daten flöten gehen.

Auch für sowas sollte man sich ein Backup einrichten.

[franky08]

Ich hatte gar keine Fehlermeldung und die DB war auch geöffnet aber eben enthielt die DB keine tables mehr. fhem hängt komplett mit allen I/O devives an einer USV, Stromausfall kommt also nicht in Frage.

@Benni

Backup läuft bei mir mit wöchentlichen cronjob, wobei ich mittels cp den kompletten fhem Ordner auf eine externe Platte kopiere.

Die Frage ist ja eigentlich auch WARUM so ein Fehler mit der DB auftritt und sämtliche tables fehlen?

VG
Frank

[Tedious]

Schreibst Du die DB auf eine SD-Karte? Wäre denn - nennen wir es mal so - suboptimal...

[betateilchen]

Das passiert einfach bei sqlite. Bei mir läuft jede nacht per at-Job ein "set <> reopen" um die Datenbank regelmäßig zu schließen und neu zu öffnen.

Probiere folgendes, nachdem Du Dich mit "sqlite3 <dbName>" mit der Datenbank verbunden hast.

Code Auswählen Erweitern


.mode insert
.output dump_all.sql
.dump
.exit


Im Dump-File musst Du alles entfernen, was nach Transaktionssteuerung aussieht.

Danach kannst Du mit

Code Auswählen Erweitern

sqlite3 <dbName> < dump_all.sql

die Daten in eine neue Datenbank schreiben. Die alte Datenbank solltest Du vorher umbenennen.

[franky08]

@betateilchen

Habe das so ähnlich gemacht:
Mit sqlite3 fhem.db .dump>fhem_dump.sql

und dann mit:
/opt/fhem/ cat fhem_dump.sql | sqlite3 fhem.db

vorher habe ich mit  drop beide tables gelöscht. Hat auch funktioniert.

Vielen Dank

VG
Frank

[wowogiengen]

Schreibst Du die DB auf eine SD-Karte? Wäre denn - nennen wir es mal so - suboptimal...

Hallo Tedious,
wie soll man es denn sonst machen, wenn man einen raspberry Pi hat? der hat ja nur SD-Karte on board, alles andere würde mehr Strom verbrauchen, oder eine funktionierende Netzwerkverbindung vorraussetzen...

[Wernieman]

Allerdings können SDCard nur eine (sehr) beschränkte Schreibanzahl pro Zelle überleben. Das kann durch eine (viel schreibende) DB durchaus zu solchen Effekten führen ...

[Guybrush]

Hallo Tedious,
wie soll man es denn sonst machen, wenn man einen raspberry Pi hat? der hat ja nur SD-Karte on board, alles andere würde mehr Strom verbrauchen, oder eine funktionierende Netzwerkverbindung vorraussetzen...

https://geekworm.com/products/raspberry-pi-4-model-b-x825-2-5-inch-sata-hdd-ssd-expansion-board

gibts auch für alle anderen Pi Versionen

[wowogiengen]

https://geekworm.com/products/raspberry-pi-4-model-b-x825-2-5-inch-sata-hdd-ssd-expansion-board

gibts auch für alle anderen Pi Versionen

Aha,
gut... Muss ich mir angucken.
Aber ich glaube, nein ich weiss, dass meine zerschossene Sqlite-DB auf meine Kappe geht...
Ich habe ein rsync von der diskstation auf den rpi gemacht, und irgendwie sichert der alles, was geht. Habe zwar ein exclude auf .db gemacht, aber eben nicht *.db und /proc/*, so dass die Datenbank während des Betriebs kopiert wurde, und das kann nur schief gehen.

Habe jetzt zum einen dem FHEM eine Zwangspause beim Beschreiben der Datenbank eingerichtet, für 4h, das sollte erst mal reichen. Zum Anderen habe ich den rsync wie oben beschrieben angepasst...:

Code Auswählen Erweitern

rsync -avuz --delete --numeric-ids --exclude=*.db --exclude=/mnt/* /proc/* -e ssh root@fhem2:/ /volume1/für_alle/Büro/Heimautomation/fhem2/aktuell/ >> /volume1/für_alle/Büro/Heimautomation/fhem2/$(date +%Y%m%d)-backup.log 2>&1
cp -Rv /volume1/für_alle/Büro/Heimautomation/fhem2/aktuell/ /volume1/für_alle/Büro/Heimautomation/fhem2/$(date +%Y%m%d) 2>&1

Viele Grüße
Wolfgang

[Wernieman]

Ich muß gestehen, das ich den Anschluß von Festplatten über USB am PI auch nicht optimal finde ..... dazu ist USB beim Pi Hardware bedingt nicht so ..... optimal

[Guybrush]

Ich muß gestehen, das ich den Anschluß von Festplatten über USB am PI auch nicht optimal finde ..... dazu ist USB beim Pi Hardware bedingt nicht so ..... optimal

wieso? usb 3.0 ist deutlich schneller als ein sata ii/iii Anschluss. Das was nicht optimal ist, ist dass man ne blöde Brücke am externen Port braucht. Ansonsten sehe ich da keinen Nachteil.

[Frank_Huber]

Der Nachteil war bis zum 3er PI.
Beim 4er mag das anderst aussehen, hab ich aber noch keine Erfahrung gemacht.

Gesendet von meinem S68Pro mit Tapatalk

[Wernieman]

USB beim PI4 soll besser als bei 1-3 sein. Mich stöhrt schon, das Leute von "soll" sprechen ... Hardware muß einffach funktionieren.

Habe hier auch Pis laufen, die müssen aber nicht schreiben ... (FHEM lauf auf eine ZOTAC-Minirechner Lüfterlos)