Hauptmenü

dblog verkleinern

Begonnen von Christian72D, 09 Juli 2017, 21:11:03

Vorheriges Thema - Nächstes Thema

Christian72D

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.

Frank_Huber

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


kadettilac89

#2
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

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`

Christian72D

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?

kadettilac89

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.

Frank_Huber

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

kadettilac89

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.

Frank_Huber

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;

DS_Starter

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
Proxmox+Debian+MariaDB, PV: SMA, Victron MPII+Pylontech+CerboGX
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard, PylonLowVoltage
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

Christian72D

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?

kadettilac89

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

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 ...

Christian72D

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?

kadettilac89

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