DBLog - Historische Werte ausdünnen

[Amenophis86]

Finde ich sehr gut. Sollte nur auch mit MariaDB funktionieren

[Sidey]

Das Vorgehen ist auch mit MariaDB kompatibel. Es sind nur Syntax Anpassungen der SQL Befehle notwendig.

[AB1970]

Code: [Auswählen]

set DBLOG reduceLog 10 include=FritzBoxDevice:FritzBoxReading
set DBLOG reduceLog 10 average=day exclude=FritzBoxDevice:FritzBoxReading


So würdest du dein Internetnutzungs Reading auf den ersten Wert jeder Stunde reduzieren und alle anderen Werte in der db auf den Tagesmittelwert. (Ältere Readings als 10 Tage)
Bei der Internetnutzung würdest du die Zeit (readings) seit dem ersten reading nach 23:00 Uhr bis Mitternacht verlieren.

EDIT: nur "average", nicht "average=day" reduziert auf den Mittelwert je Stunde, statt den Tagesmittelwert.
« Letzte Änderung: Gestern um 19:34:26 von rapster »

Hi , erstmal danke für dein Antwort!
Da der letzte Tageswert der Höchste vor dem Reset um 0:00 Uhr ist, darf ich ihn nicht verlieren, da ich ansonsten einen immer größer werdenen Fehler habe. 
Allerdings überlege ich mir gerade, ob es vielleicht doch besser ist die Funktion unabhängig von reducelog zu implementieren.


Aber vielen Dank noch mal!

[Elektrofreak]

Hallo zusammen,

ich habe ein etwas komisches Problem. Ich habe jetzt seit ein paar Wochen die logDB am Laufen und diese ist mittlerweile knapp 300MB groß. Jetzt habe ich mit reduceLog ... und deleteOldDays 1 alle Daten bis auf die letzten 24h gelöscht. Komischerweise ist die Größe der Datenbank immer noch identisch groß  In den Plots sind aber alle Einträge bis auf die letzten 24h verschwunden. Falls in der Datenbank ein Fehler wäre, würde ich einfach eine neue erzeugen. Aber das würde ja das Problem nicht lösen, wenn reduceLog und deleteOldDays nicht richtig funktionieren würde 

Hatte jemand schon mal das selbe Problem?

Edit: Das Reading countHistory zählt aktuell noch 146887 Einträge 

[KernSani]

Welche Datenbank? sqlite braucht noch ein "VACUUM" um physisch kleiner zu werden, delete alleine hinterlässt "leeren Raum", der mit Vacuum beseitigt wird.

[Elektrofreak]

Welche Datenbank?

SQLite 

sqlite braucht noch ein "VACUUM" um physisch kleiner zu werden, delete alleine hinterlässt "leeren Raum", der mit Vacuum beseitigt wird.

Hallo,

danke für die Info. Wie kann ich das VACUUM denn füllen/leeren? Macht das denn sinn oder sollte die Datenbank so groß bleiben, um dann performanter gefüllt zu werden? Vielleicht sollte man die VACUUM-Funktion auch in das FHEM-Modul integrieren

[kumue]

nach einem Vacuum wird die Datenbank physisch nicht kleiner.
Erklärung siehe hier
https://sqlite.org/faq.html#q12

[KernSani]

Nach einem vacuum wird die Datei kleiner - das meinte ich mit "physisch kleiner". In FHEM integriert is vacuum über Dblog userCommand

[Elektrofreak]

Nach einem vacuum wird die Datei kleiner - das meinte ich mit "physisch kleiner". In FHEM integriert is vacuum über Dblog userCommand

Also ich habe jetzt folgenden Befehl ausgeführt, aber keine Größenreduktion feststellen können 

Code Auswählen Erweitern

set sys_logdb userCommand VACUUM;

Ist der Befehl richtig?

Nach einem vacuum wird die Datei kleiner

nach einem Vacuum wird die Datenbank physisch nicht kleiner.

Verstehe ich jetzt leider nicht. Laut deiner Referenz

Erklärung siehe hier
https://sqlite.org/faq.html#q12

würde ich es auch so verstehen, dass sie kleiner wird 

[kumue]

Der freie Platz entsteht in der Datenbank. Auf der Platte bleibt die Größe vorerst gleich.
Neue Daten werden in den freien Bereich geschrieben, die DB wächst somit erstmal nicht weiter.
So mein Verständnis, zumal ich selbst feststellte, daß nach einem vacuum der Platz auf der Platte nicht kleiner wurde.

[Elektrofreak]

Gibt es denn eine Möglichkeit, die Größe wieder zu reduzieren? Ich bin mit den knapp 300MB noch recht zufrieden. Wenn aber durch einen Fehler die Größe mal auf 1GB oder so ansteigt, möchte ich diese auch wieder verkleinern können  . Sonst ist irgendwann die SD-Karte voll 

Edit: Und noch etwas, dass ich leider nicht verstehe 

Ich habe nun auf die Datenbank ein

Code Auswählen Erweitern

set sys_logdb reduceLog 14 average

durchgeführt. Dabei hat sich die Datenbankgröße überhaupt nicht geändert, obwohl ich folgende Readings habe:

countHistory: 1877864 (nachher <100 Einträge unterschied, beide male ein count ausgeführt)
lastReduceLogResult: Rows processed: 1556274, deleted: 1501897, updated: 41159, time: 241.00sec

Wenn er 1.5Mio Einträge gelöscht hat, müsste ich es ja auch in den Plots sehen. Aber die Plots, die älter als 14 Tage sind, haben keinen average erfahren. Es sind immer noch alle Punkte vorhanden. Das finde ich extrem komisch 

Edit2: Irgendwie spinnen bei mir die Datenbanken. Irgendwann war die Datei doch kleiner und Datensätze wurden gelöscht. Einmal Backup einspielen und nochmal probieren. Vieleicht funktioniert es dann 

[KernSani]

nochmal zum Thema Plattenplatz und Vacuum...

EDIT: Ich mache täglich

Code Auswählen Erweitern

reduceLog 90 average=day
und

Code Auswählen Erweitern

reduceLog 30 average

und wöchentlich ein VACUUM

[Elektrofreak]

Danke, funktioniert jetzt wie gewünscht 

[dancatt]

Hallo zusammen,

meine "fhem.db" ist knapp 50 GB groß und wollte das nun mal aufräumen bzw. kleiner machen.

Habe

Code Auswählen Erweitern

reduceLog 90 average=day
gemacht:
Im Log:

Code Auswählen Erweitern

2017.02.07 08:32:18.742 3: DbLog dbLog: reduceLog requested with DAYS=90, AVERAGE=DAY
2017.02.07 08:37:52.222 3: DbLog dbLog: reduceLog executed. Rows processed: 0, deleted: 0, updated: 0, time: 334.00sec

und danach

Code Auswählen Erweitern

reduceLog 30 average
Im Log:

Code Auswählen Erweitern

2017.02.07 09:06:53.798 3: DbLog dbLog: reduceLog requested with DAYS=30, AVERAGE=HOUR
2017.02.07 09:23:16.028 3: DbLog dbLog: reduceLog executed. Rows processed: 0, deleted: 0, updated: 0, time: 983.00sec

Danach VACUUM. Da ist fhem runtergefahren und das wars.

DbLog nutze ich schon seit ca. 2 Jahren.

Warum steht im Log immer 0?
Wie kriege ich denn das File "fhem.db" kleiner?

Vielen Dank.

Gruß Daniel

[Amenophis86]

Ich hatte die Tage das selbe Problem. Aus mir unbekannten Gründen musste ich mich langsam mit reduce und Tagen runter arbeiten. Das habe ich wie folgt gemacht:

1. Schauen, wann der letzte average Eintrag erstellt wurde, wenn überhaupt jemals erstellt.

Wenn jemals erstellt wie folgt weiter verfahren:
2a. Die Tage von heute bis zu diesem Tag zählen (Gibt gute Seiten im Internet, die das für dich machen)

Wenn noch nie ein reduceLog mit average durchgeführt wurde wie folgt verfahren:
2b. Den ersten Tag der Datenbank nehmen und von heute bis zu diesem Tag die Tage zählen

3. Den Befehl reduceLog mit deinem Wert aus 2a oder 2b - 10 beginnen.
4. Warten und schauen, ob es funktioniert hat (Sieht man, weil die Angaben was gemacht wurde nicht null sind)

Wenn es geklappt hat wie folgt weiter verfahren:
5a. Nun arbeitest du dich weiter runter mit dem Wert des Tages. Ich habe immer mal wieder variiert zwischen 10 - 20 Tagen. Machmal hat es geklappt mehr als 10 zu nehmen, manchmal hat es nicht geklappt.

Wenn es nicht geklappt hat wie folgt verfahren:
5b. Denn Wert aus 2a oder 2b - 5 ausrechnen und damit ein reduceLog und average ausführen. Danach wieder schauen, ob es geklappt hat. Wenn nicht den Wert 5 noch mehr verkleinern.

Der Grund warum es nur so geht erschließt sich mir überhaupt nicht. Aus irgendeinem Grund kann reduceLog scheinbar mit zu vielen Reihen nix anfangen und macht einfach nichts. Ich habe am Ende dann ein at aufgesetzt, welches mir alle 5 Minuten in reduceLog ausgeführt hat. In dem at befand sich eine Berechnung, welche den Wert für reduceLog um eins reduziert hat, bis es einen Stopwert erreichte. Ein Dummy dazu war auch noch nötig. Geht sicher auch besser, aber so sah es bei mir grob aus:

Beispiel:

Code Auswählen Erweitern


define reduce_dummy dummy
set reduce_dummy <Wert aus 2a oder 2b>

define reduce_auto at +*00:05:00 {
my $wert = Value("reduce_dummy");
$neu = $wert - 10;
fhem("set reduce_dummy $neu");

if($neu > 50)
{fhem("set DBLog reduceLog $neu average");}
else {Log 1, "Reduce at beenden, ist fertig!"}
}

Der Code ist ungetestet und gerade nur grob aus der Erinnerung.