[fertig] fhem.db "aufräumen"

[franky08]

Ich stelle die Frage mal hier im Anfängerbereich, da es sich ja nicht um das DbLog Modul handelt, sondern die fhem.db direkt betrifft.
Also ich wollte heute mal die fhem.db aufräumen, Datenbank ist sqlite3. Also mit:

Code Auswählen Erweitern

cubie@Cubian:/opt/fhem$ sqlite3 fhem.db
SQLite version 3.7.13 2012-06-11 02:05:22
Enter ".help" for instructions
Enter SQL statements terminated with a ";"
sqlite> delete from history where TIMESTAMP like "2014%";
   ...>
   ...>

aber dann passiert nichts weiter!? Wo liegt mein Fehler, das Statement delete from history where TIMESTAMP like "2014%"; müsste doch OK sein um alle Datensätze aus dem Jahr 2014 loszuwerden.

VG
Frank

[marvin78]

Warum benutzt du nicht das FHEM "Boardmittel" deleteOldDays?

[franky08]

Weil die db mittlerweile 8Gb gross ist und mit delete olddays hängt fhem ewig.

VG
Frank

[betateilchen]

deleteOldDays macht auch nix anderes.

Und Dein Problem ist, dass Du einfach viel zu ungeduldig bist. Bei 8GB in Sqlite kannst Du in aller Ruhe erstmal an den Herd gehen und Mittagessen zubereiten, bis der Befehl zu Ende ausgeführt ist.

[franky08]

Danke, dachte ich schon das es dauert. Wir essen dann erst einmal 

Gesundes neues Jahr noch

VG
Frank

[marvin78]

An deiner Stelle würde ich deleteOldDays in einem at regelmäßig verwenden. Ich habe zu dem Zweck mehere Log-DBs und diese haben eine abgestufte "Lebensdauer" für die Daten. 

[betateilchen]

An deiner Stelle würde ich deleteOldDays in einem at regelmäßig verwenden.

Genau dafür ist es ja eingebaut worden...

[franky08]

Ja, aber da verliere ich die Jahresdaten vom Energieverbrauch.

[marvin78]

Wie gesagt: Lege einfach mehre logDBs an und logge die Energiedaten in eine DB und den Rest in andere DB(s). Das deleteOldDays wendest du dann nur auf die letztere(n) an.

[franky08]

Nur mal interessehalber, habe heute morgen mal delete from history like TIMESTAMP "2014%" auf meine sqlite DB losgelassen. Der Prozess scheint bis jetzt immer noch nicht abgeschlossen zu sein. Die fhem.db ist ca. 8Gb groß, bis dato erscheint kein Prompt auf der Konsole. Frage, dauert das so lange oder ist da irgendwas schiefgelaufen?
Im fhem Verzeichnis ist zu sehen, dass sich die write ahead logging (WAL) Datei mittlerweile auf 13 Gb vergrößert hat und noch wächst, also scheint der Prozess ja noch zu laufen.


VG
Frank

[franky08]

Nach 9 Stunden ist der Cubie jetzt fertig geworden! Hätte nie gedacht, dass es soooo zeitaufwendig ist 


VG
Frank

[marvin78]

Daher habe ich für die Zukunft die Vorschläge oben gemacht. Für die Aufgabe benötigen auch wesentlich performantere Server eine Weile

[franky08]

Dafür habe ich jetzt ein Problem fhem zu stoppen oder den Cubie mittels shutdown runterzufahren, das Webif von fhem ist auch nicht erreichbar, fhem läuft aber. Ein Blick mittels top zeigt, das fhem bis zu 99 % CPU Last erzeugt, desshalb reagiert das System auch auf nichts mehr.
Warten oder Hart "ausschalten"? Ein kill 2112 oder pkill fhem geht leider auch nicht.

VG
Frank

[betateilchen]

Das dürften die Nachwirkungen Deiner Löschaktion sein.

Entweder geduldig sein und warten oder mutig sein und Stecker ziehen.

[franky08]

Ich war dann mal mutig und hab den Stecker gezogen. Nach einem Neustart und versuchten Zugriff aufs Webif, geht die cpu Last gleich wieder auf 96%.

Code Auswählen Erweitern

2015.01.04 19:43:01 1: Including fhem.cfg
2015.01.04 19:43:02 3: Connecting to database SQLite:dbname=/opt/fhem/fhem.db with user
2015.01.04 19:43:02 3: Connection to db SQLite:dbname=/opt/fhem/fhem.db established for pid 2131
2015.01.04 19:53:40 3: Connection to db SQLite:dbname=/opt/fhem/fhem.db established
2015.01.04 19:53:40 3: telnetPort: port 7072 opened
2015.01.04 19:53:40 3: WEB: port 8083 opened
2015.01.04 19:53:40 3: WEBphone: port 8084 opened
2015.01.04 19:53:40 3: WEBtablet: port 8085 opened
2015.01.04 19:53:40 3: WEBtablet2: port 8086 opened
2015.01.04 19:53:41 1: HMLAN_Parse: HMLAN1 new condition disconnected
2015.01.04 19:53:41 3: Opening HMLAN1 device 192.168.2.222:1000
2015.01.04 19:53:41 3: HMLAN1 device opened
2015.01.04 19:53:41 1: HMLAN_Parse: HMLAN1 new condition init
2015.01.04 19:53:41 1: HMLAN_Parse: HMLAN2 new condition disconnected
2015.01.04 19:53:41 3: Opening HMLAN2 device 192.168.2.223:1000
2015.01.04 19:53:41 3: HMLAN2 device opened
2015.01.04 19:53:41 1: HMLAN_Parse: HMLAN2 new condition init
2015.01.04 19:53:41 3: FHEM2FHEM opening ds2 at 192.168.2.54:7072
2015.01.04 19:53:41 3: FHEM2FHEM device opened (ds2)
2015.01.04 19:53:43 2: VIERA: defined with host: 192.168.2.20 and interval: 30
2015.01.04 19:53:45 3: Opening FB7390 device 192.168.2.1:1012
2015.01.04 19:53:45 3: FB7390 device opened
2015.01.04 19:53:47 3: FHEM2FHEM opening ds1 at 192.168.2.30:7072
2015.01.04 19:53:47 3: FHEM2FHEM device opened (ds1)
2015.01.04 19:53:47 2: Heizungen_Sommer: no reading yet for Temperatur_Garten temperature
2015.01.04 19:53:50 2: WZ_HZ_boost2: no reading yet for Differenz_HZ temperature
2015.01.04 19:53:50 2: WZ_HZ_alarm: no reading yet for Diff_Sensor_WZ_T1_T2 temperature
2015.01.04 19:53:51 3: Opening my_callmonitor device 192.168.2.1:1012
2015.01.04 19:53:51 3: my_callmonitor device opened
2015.01.04 19:53:51 3: FB_CALLMONITOR (my_callmonitor) - loading cache file /opt/fhem/callmoncache.txt
2015.01.04 19:53:51 2: FB_CALLMONITOR (my_callmonitor) - read 11 contacts from Cache
2015.01.04 19:53:51 2: FB_CALLMONITOR (my_callmonitor) - found FritzBox phonebook /opt/fhem/fb_phonebook.xml
2015.01.04 19:53:51 2: FB_CALLMONITOR (my_callmonitor) - read 58 contacts from FritzBox phonebook
2015.01.04 19:53:51 3: Opening Pioneer device 192.168.2.50:23
2015.01.04 19:53:51 3: Can't connect to 192.168.2.50:23: Connection refused
2015.01.04 19:54:28 3: PIONEERAVR Pioneer: PIONEERAVR_statusUpdate()
2015.01.04 19:54:31 1: Including ./log/fhem.save