Wie bekomme ich meine Datenbank kleiner? Also von der Definition her habe ich es schon auf das für mich wichtige beschränkt.
Ein "set logdb deleteOldDays 30" hat nichts gebracht, die Datei ist über 2GB groß und meine Karte bald voll.
Bei sqlite heißt der Befehl vacuum. Ist ein Befehl für die SQL Konsole. Der gibt freien Platz auch wirklich frei.
Gesendet von meinem S3_32 mit Tapatalk
Zitat von: Christian72D am 09 Juli 2017, 21:11:03
Wie bekomme ich meine Datenbank kleiner? Also von der Definition her habe ich es schon auf das für mich wichtige beschränkt.
Ein "set logdb deleteOldDays 30" hat nichts gebracht, die Datei ist über 2GB groß und meine Karte bald voll.
Gib ein paar Informationen ...
wie viele Geräte loggst du?
wie viele Einträge hat deine Datenbank (Tabelle history)
was hast du schon unternommen um die Anzahl der Eiträge zu verringern
Wiki gelesen? Vor Allem "Einschränkung über die jeweiligen Devices"
https://wiki.fhem.de/wiki/DbLog#Einschr.C3.A4nkung_.C3.BCber_die_jeweiligen_Devices (https://wiki.fhem.de/wiki/DbLog#Einschr.C3.A4nkung_.C3.BCber_die_jeweiligen_Devices)
Edit:
Weißt du wie man ein SQL-Statement absetzt ... wenn nicht goolge fragen.
Damit kannst du rausfinden ob ein einzelnes Device deine DB zumüllt. Das gibt dir alle Devices und Anzahl der Messages dazu aus.
select `history`.`DEVICE` AS `device`,`history`.`READING` AS `reading`,count(0) AS `number` from `history` group by `history`.`DEVICE`,`history`.`READING`
Aktuell sieht meine Definition so aus:
Internals:
COLUMNS field length used for Device: 64, Type: 64, Event: 512, Reading: 64, Value: 128, Unit: 32
CONFIGURATION ./db.conf
DBMODEL SQLITE
DEF ./db.conf .*:(Activity|actuator|alarmTest|battery|batteryLevel|desired-temp|dewpoint|humidity|level|motorErr|measured-temp|pct|residentsHome|smokeChamber|state|temperature|Valve|wind).*
MODE synchronous
NAME logdb
NR 302
NTFY_ORDER 50-logdb
PID 823
REGEXP .*:(Activity|actuator|alarmTest|battery|batteryLevel|desired-temp|dewpoint|humidity|level|motorErr|measured-temp|pct|residentsHome|smokeChamber|state|temperature|Valve|wind).*
STATE connected
TYPE DbLog
VERSION 2.17.1
dbconn SQLite:dbname=/opt/fhem/fhem.db
dbuser christian
Helper:
COLSET 1
DEVICECOL 64
EVENTCOL 512
READINGCOL 64
TYPECOL 64
UNITCOL 32
VALUECOL 128
Readings:
2017-07-09 21:07:21 lastRowsDeleted 0
2017-07-10 09:15:43 state connected
Cache:
index 0
Attributes:
DbLogType Current/History
room hidden
userReadings DbFileSize:lastReduceLogResult.* { (split(' ',`du -m fhem.db`))[0] }
Ich habe es also nicht Device spezifisch gemacht sondern global.
Die anderen Sachen kann ich erst heute am frühen Abend testen, aber evtl. reicht das VACUUM ja auch erst mal.
Dafür muß ich aber bestimmt fhem beenden, oder?
Zitat von: Christian72D am 10 Juli 2017, 09:18:36
Aktuell sieht meine Definition so aus:
Internals:
COLUMNS field length used for Device: 64, Type: 64, Event: 512, Reading: 64, Value: 128, Unit: 32
CONFIGURATION ./db.conf
DBMODEL SQLITE
DEF ./db.conf .*:(Activity|actuator|alarmTest|battery|batteryLevel|desired-temp|dewpoint|humidity|level|motorErr|measured-temp|pct|residentsHome|smokeChamber|state|temperature|Valve|wind).*
MODE synchronous
NAME logdb
NR 302
NTFY_ORDER 50-logdb
PID 823
REGEXP .*:(Activity|actuator|alarmTest|battery|batteryLevel|desired-temp|dewpoint|humidity|level|motorErr|measured-temp|pct|residentsHome|smokeChamber|state|temperature|Valve|wind).*
STATE connected
TYPE DbLog
VERSION 2.17.1
dbconn SQLite:dbname=/opt/fhem/fhem.db
dbuser christian
Helper:
COLSET 1
DEVICECOL 64
EVENTCOL 512
READINGCOL 64
TYPECOL 64
UNITCOL 32
VALUECOL 128
Readings:
2017-07-09 21:07:21 lastRowsDeleted 0
2017-07-10 09:15:43 state connected
Cache:
index 0
Attributes:
DbLogType Current/History
room hidden
userReadings DbFileSize:lastReduceLogResult.* { (split(' ',`du -m fhem.db`))[0] }
Ich habe es also nicht Device spezifisch gemacht sondern global.
Die anderen Sachen kann ich erst heute am frühen Abend testen, aber evtl. reicht das VACUUM ja auch erst mal.
Dafür muß ich aber bestimmt fhem beenden, oder?
Beenden - ja. Macht Sinn.
Du hast alles "global" gemacht bedeutet, kein "even-on-update reading" in den einzelnen Devices wie im Wiki beschrieben? Dann musst dich über die DB-Größe nicht wundern da du die DB mit Events bombadierts.
Zitat von: kadettilac89 am 09 Juli 2017, 21:41:04
Damit kannst du rausfinden ob ein einzelnes Device deine DB zumüllt. Das gibt dir alle Devices und Anzahl der Messages dazu aus.
select `history`.`DEVICE` AS `device`,`history`.`READING` AS `reading`,count(0) AS `number` from `history` group by `history`.`DEVICE`,`history`.`READING`
Der Befehl ist ja mal genial. Sowas hat mir noch gefehlt! :)
Kriegt man den count noch als "ORDERBY" unter? ich scheitere gerade beim Versuch das mit reinzubringen.
Danke & Grüße
Frank
Zitat von: Frank_Huber am 10 Juli 2017, 09:43:54
Der Befehl ist ja mal genial. Sowas hat mir noch gefehlt! :)
Kriegt man den count noch als "ORDERBY" unter? ich scheitere gerade beim Versuch das mit reinzubringen.
Danke & Grüße
Frank
versuche mal " .... order by `number` DESC ..... " hinten anzuhängen. Gib nochmal bescheid wenn es nciht funktioniert, dann schau ich heute Abend die Syntax nochmal an.
Zitat von: kadettilac89 am 10 Juli 2017, 10:12:29
versuche mal " .... order by `number` DESC ..... " hinten anzuhängen. Gib nochmal bescheid wenn es nciht funktioniert, dann schau ich heute Abend die Syntax nochmal an.
läuft! DANKE! :-)
select `history`.`DEVICE` AS `device`,`history`.`READING` AS `reading`,count(0) AS `number` from `history` group by `history`.`DEVICE`,`history`.`READING` order by `number` DESC;
Hallo,
Die Tabellenoptimierung gibt es inzwischen im DbRep (vacuum) zur regelmäßigen Einplanung wenn man will.
Wenn DbLog im asynchmode betrieben wird braucht FHEM dafür auch nicht beendet werden (blockiert nicht).
Im Wiki und Commandref zu DbRep ist es (hoffentlich) hinreichend gut beschrieben.
VG
Heiko
Zitat von: kadettilac89 am 10 Juli 2017, 09:30:32
Du hast alles "global" gemacht bedeutet, kein "even-on-update reading" in den einzelnen Devices wie im Wiki beschrieben? Dann musst dich über die DB-Größe nicht wundern da du die DB mit Events bombadierts.
Kann man das nicht auch global machen?
Zitat von: Christian72D am 10 Juli 2017, 16:17:40
Kann man das nicht auch global machen?
Kannst du ... ja. Ich glaube aber wir reden von unterschiedlichen Dingen.
1) Global def. was geloggt wird ist völlig OK. Habe ich genau so gemacht
2) Jedes Device macht alle xxx min (z. B. 5) einen Update auf alle Attribute. Auch wenn sich nichts ändert wird alle 5 min. ein Satz in die DB geschrieben was eigentlich unnötig ist, und deine DB aufbläht.
Für 2) macht es Sinn allen Devices "even-on-update/change-reading" nur noch bei Änderung ein Update zu gestatten. Beispiel: batteryLevel Ändert sich alle 7 Tage --> ohne Einschränkung hast du 2016 Werte pro Woche (alle 5 min), mit Einschränkung nur 1 Satz pro Woche. Hierzu der von mir gepostete Bereich im Wiki. Oder commandref event-on-change + event-on-update.
Ein weiterer Link in dem ein bischen zu dem Thema steht .... http://www.phobal.de/haustechnik/fhem/daten_reduktion.html (http://www.phobal.de/haustechnik/fhem/daten_reduktion.html)
Schau mal was vacuum bewirkt und poste mal was mein SQL-Statement ausgibt und ob ggf. DEvices/Readings enthalten sind die du gar nicht willst bzw. brauchst ...
Der Integritätscheck meldet mir massig Fehler.
Ich mache jeden Tag ein komplettes Backup von fhem, innerhalb einer Woche in die Datenbank die seit MONATEN existiert um über 200MB gewachsen.
16 GB Karte ist bestellt, dann kommt ein Image Backup auf die größe Karte und dann werde ich mal ein paar Tage zurück gehen und eine alte db einspielen, da denke ich werde ich keine Fehler drin haben.
Und DANN schau ich mir den Rest an.
Wie kann ich denn jetzt den Inhalt der db KOMPLETT löschen?
Oder soll ich besser die Datei löschen und dann nach Wiki neu aufsetzen?
Zitat von: Christian72D am 10 Juli 2017, 17:04:47
Wie kann ich denn jetzt den Inhalt der db KOMPLETT löschen?
Oder soll ich besser die Datei löschen und dann nach Wiki neu aufsetzen?
Wenn es schon Probleme gibt würde ich einen Dump erstellen, DAtenbank komplett neu aufbauen (db_create file aus dem forum / wiki) und dann den dump in die neu erstellte DB einlesen. Wenn du die DB-Datei vorher sichernst ist das ein geringes Risiko. Wenn du irgendwo eine VM mit Linux / Ubuntu hast kannst es dort testen und FHEM so lange laufen lassen bis du mit der Prozedur vertraut bist.
http://www.ibiblio.org/elemental/howto/sqlite-backup.html (http://www.ibiblio.org/elemental/howto/sqlite-backup.html)