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
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.
Zitat2016.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?
Zitat von: franky08 am 08 September 2016, 23:30:30
Es ist mehr als ärgerlich wenn sämtliche statistische Jahresplots/Daten flöten gehen.
Auch für sowas sollte man sich ein Backup einrichten.
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
Schreibst Du die DB auf eine SD-Karte? Wäre denn - nennen wir es mal so - suboptimal...
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.
.mode insert
.output dump_all.sql
.dump
.exit
Im Dump-File musst Du alles entfernen, was nach Transaktionssteuerung aussieht.
Danach kannst Du mit
sqlite3 <dbName> < dump_all.sql
die Daten in eine neue Datenbank schreiben. Die alte Datenbank solltest Du vorher umbenennen.
@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
Zitat von: Tedious am 09 September 2016, 13:41:40
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...
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 ...
Zitat von: wowogiengen am 02 Juni 2020, 14:52:36
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
Zitat von: Guybrush am 02 Juni 2020, 16:25:55
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...:
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>&1Viele Grüße
Wolfgang
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
Zitat von: Wernieman am 02 Juni 2020, 19:23:28
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.
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
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)
Zitat von: Wernieman am 02 Juni 2020, 21:15:05
USB beim PI4 soll besser als bei 1-3 sein. Mich stöhrt schon, das Leute von "soll" sprechen ... Hardware muß einffach funktionieren.
wieso soll? der Pi 4 hat USB 3.0. Das IST besser/schneller als USB 2.0, was die Pi Vorgänger nur hatten. Für die Pis reicht aber auch eine USB 2.0 to Sata Schnittstelle. Sata schafft zwar theoretisch 300 mb/s, aber die 60 mb/s mit usb 2.0 reichen. Die meisten SD Karten sind langsamer...
Es geht um USB am Raspberry, nicht um USB generell.
Am PI sind die USB suboptimal an der CPU dran und teilen sich das noch mit dem Netzwerk.
Der 4er ist da besser designt. Aber obs in der Praxis auch was bringt...
Gesendet von meinem S68Pro mit Tapatalk
die 4 usb ports sind bei allen raspberry pi nativ an die cpu angebunden. das einzige mank daran ist nur, dass zur cpu nur eine usb 2.0 leitung besteht, die dann über eine. hub aufgeteilt wird, insofern solange kein problem, wie man keine anderen datenfresser ranhängt.
Dann würde ich Dir Vorschlagen, das Du die Doku liest. USB IST an Pi1-3 ein Problem. Egal welche Version. Gibt auch genug Test dafür ....
Aber wir werden jetzt OT
Und beim 4er gibt es noch keine aussagekräftigen Testberichte.
Also ist und bleibt USB am PI wackelig.
Gesendet von meinem S68Pro mit Tapatalk
das ist zwar sicherlich nicht (mehr) ganz beim thema. mich interessieren aber gerade die ,,probleme". geht das genauer oder ists nur weiter transportiertes hörensagen?
grundlegend ist das beim Pi ziemlich alternativlos über usb einen massenspeicher anzubinden, wenn man viel io hat. iscsi etc fressen z.b. zuviel leistung, zumal die meisten dafür keine infrastruktur haben.
Zitat von: wowogiengen am 02 Juni 2020, 19:21:18
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...:
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
Hallo,
bleiben wir mal beim Thema :D
ich hab offensichtlich laut Log keine Probleme mit der Datenbank, aber beim SVGPlot kommen keine aktuellen Werte an.
Die Daten der letzten Wochen / Monate muss ich nochmals aus den ebenfalls vorhandenen Text-Logdateien importieren, aber alles was neu ist, ist nicht zu sehen :-(
Wo kann ich da gucken ?
Werde heute abend mal nochmal die DB dumpen und dann auf dem PC anschauen, was da alles drin steht.
wo kann man die SVG-Plots zwischen History und Current umschalten?
VG Wolfgang
Zitat von: wowogiengen am 03 Juni 2020, 08:27:13
ich hab offensichtlich laut Log keine Probleme mit der Datenbank, aber beim SVGPlot kommen keine aktuellen Werte an.
Die Daten der letzten Wochen / Monate muss ich nochmals aus den ebenfalls vorhandenen Text-Logdateien importieren, aber alles was neu ist, ist nicht zu sehen :-(
Wo kann ich da gucken ?
Werde heute abend mal nochmal die DB dumpen und dann auf dem PC anschauen, was da alles drin steht.
wo kann man die SVG-Plots zwischen History und Current umschalten?
define <name> SVG <logDevice>:<gplotfile>:<logfile>
bei <logfile> dann statt HISTORY CURRENT angeben
ansonsten würde ich einfach mal händisch daten aus der db auslesen, welche seit dem reingeschrieben worden sein müssen. wenn das schon keine Ergebnisse liefert, liegt das Problem jedenfalls nicht am SVGPlot
Will mal kurz was gerade rücken ...
Zitatwo kann man die SVG-Plots zwischen History und Current umschalten?
garnicht. SVG-Plots mit DbLog ziehen die Daten immer aus der history Tabelle.
Die current ist ausschließlich als Ausfüllhilfe bei SVG Editor vorhanden.
Du kannst mit einem DbRep Device und "set <> fetchrows" immer einen Blick in die history oder auch current Tabelle werfen und siehst was drin steht bzw. geloggt wird.
Für eine SQLIte gibt es im DbRep auch eine Reparaturmöglichkeit (repairSQLite). Zumindest kann man es damit versuchen sofern nötig.
Grüße,
Heiko
@DS_Starter - das ist hardcoded im Quellcode drin? Gut zu wissen... ging jetzt nur davon aus, dass das nur als Default gilt. Wobei die Current von der Struktur für Plots wenig Sinn macht, hätte man mal vorher mehr denken müssen :)
Zitatdas ist hardcoded im Quellcode drin?
Es kommt eine Fehlermeldung wenn Current angegeben ist und wird intern auf history umgesetzt.
Zitat von: Guybrush am 02 Juni 2020, 23:20:48
das ist zwar sicherlich nicht (mehr) ganz beim thema. mich interessieren aber gerade die ,,probleme". geht das genauer oder ists nur weiter transportiertes hörensagen?
grundlegend ist das beim Pi ziemlich alternativlos über usb einen massenspeicher anzubinden, wenn man viel io hat. iscsi etc fressen z.b. zuviel leistung, zumal die meisten dafür keine infrastruktur haben.
Nichts ist alternativlos - da die Einrichtung etwas komplexer ist weil es nicht für jeden Schritt ein YT-Video gibt kann man auch Ebay und Co für einen ganz schmalen Taler Bananapi-M1/2/3 schießen. ich nutze u.a. auch einen einen BananaPi M2 Ultra - der hat von Haus aus 2GB DDR-3-Ram, 8Gb emmc Flash (man braucht also keine SD-Karte zum Betrieb, nur zum Einrichten) und einen dedizierten SATA-Port. Gepaart mit einer quad-core cortex -A7 ist der flott und sparsam unterwegs.
Zitat von: Tedious am 04 Juni 2020, 11:20:43
Nichts ist alternativlos - da die Einrichtung etwas komplexer ist weil es nicht für jeden Schritt ein YT-Video gibt kann man auch Ebay und Co für einen ganz schmalen Taler Bananapi-M1/2/3 schießen. ich nutze u.a. auch einen einen BananaPi M2 Ultra - der hat von Haus aus 2GB DDR-3-Ram, 8Gb emmc Flash (man braucht also keine SD-Karte zum Betrieb, nur zum Einrichten) und einen dedizierten SATA-Port. Gepaart mit einer quad-core cortex -A7 ist der flott und sparsam unterwegs.
Es mag sicher Alternativen geben. Ich bezog mein Feedback auf Raspberry Pi. Davon ab: Der Banana Pi ist jedenfalls keine Alternative. Der hat zwar einen direkten Sata Port, aber auch nur USB 2.0. Die Sata Schnittstelle ist jedoch nicht "dediziert". Das ist eine USB-to-Sata Bridge... Ist also defakto genauso schnell/lahm wie bei einem Raspberry Pi 1-3. USB/Eth/SATA haben da - wie beim Pi 1-3 - zusammen eine maximale Bandbreite von 60mb/s. Der Pi4 schafft wegen USB 3.0 600mb/s. Das langt für eine SSD und 1Gbe.
...aber es ging ja hierbei nicht drum (ursprünglich) einen schnellen Fileserver aufzusetzen, sondern ein stabiles DB-System zu etablieren was nicht an ständigem Sterben von MicroSDs oder USB-Sticks durch hohe E/A leidet. Dabei ist es denn egal ob USB2 oder 3, denn einer SSD machen die vielen Schreibzugriffe im Vergleich zu obigem nahezu nichts aus. Zudem besitzt der Controller eine eigene Logik, Stichwort SMART und möglichem Alerting.
Zuguterletzt möchte ich (und ich habe auch diverse PIs im Einsatz) die interne eMMC definitiv nicht mehr missen.
Ich muß gestehen, das ich für eine dauerhafte Stabile HomeAutomatisation auf eine bessere Hardware als Pi (und Vergleichbare) setzen würde. Möchte da mein x86 Server nicht missen. Mit 7W (incl. Zusatz USB-Hub) ist er nicht weit weg von dem Verbrauch eines Pis, bei einer deutlich anderen Leistungsklasse.
Habe hier auch einen Pi, der macht aber "nur" Gateway .... und schreibt deshalb praktisch nichts. Genau das schreiben dürfte hier das Problem sein ....