DBLog - Historische Werte ausdünnen

[Tedious]

Am einfachsten gehts via HeidiSQL, einer kleinen schlanken Workbench für SQL. Du connestest die DB (IP, User, Passwort), generierst die Abfrage - in die Ergebnisse, rechte Maustaste - exportieren (in eine Datei). Am besten als INSERT, denn kannst Du die Inhalte bei Bedart per Mausklick importieren.

(http://www2.pic-upload.de/thumb/31637388/Heidi1.png)

(http://www2.pic-upload.de/thumb/31637389/Heidi2.png)

[pc1246]

Hallo zusammen
Nun habe ich endlich mal wieder Zeit, Urlaub und andere Aktivitaeten sind beendet. Es wird so langsam eng auf meiner SD-Karte, 1,4GB sind noch frei! Da ich ja eine SQlite Datenbank habe, habe ich mal mein Glueck mit phpLiteAdmin versucht. Dummerweise kriege ich beim Oeffnen gleich ein paar nette Fehlermeldungen, mit denen ich dann leider nichts anfangen kann.

Code Auswählen Erweitern


Checking supported SQLite PHP extensions...
PDO: installed
PDO SQLite Driver: not installed
SQLite3: not installed
SQLiteDatabase: not installed


Ich verstehe, dass etwas fehlt, aber wo ist mir nicht klar. Koennt Ihr mir auf die Spruenge helfen?
Gruss Christoph

[chris1284]

wenn du sql lite hast nutze doch einfach die sqlite befehle (zb direkt aus fehm) oder fhem beenden und über die shell.

zum ausdünnen reducelog im dblog modul und dann "userCommand vacuum" um das file selbst zu verkleinern

[pc1246]

Hallo Chris
Ich habe es dann jetzt wirklich geschafft. Ist nur bloed wenn man sich eine offenen DB vom RPI holt. Die ist dann defekt fuer SQLITE. Naja ich habe es geschafft, 1,5 Jahre geloescht, und mit dem DBBrowser komprimiert, Vacuum wollte nicht! Morgen spiele ich die dann auf den RPI, und dann kann ich wieder ruhiger schlafen.
Gruss und Danke nochmals Christoph

[pc1246]

Moin
Nun habe ich doch noch ein Problem. Seitdem die "kleine" DB auf dem RPI ist, wird nichts mehr reingeschrieben. Lediglich die .shm ist aktuell. Dblog sagt auch connected, und ein reread config erfolgt auch anstandslos! Ich habe ja kein Problem damit, dass mir jetzt eine Woche fehlt, aber wie kriege ich das loggen jetzt wieder in Gang?
Gruss Christoph

Edit: Beim Plot kann ich auch nichts mehr auswaehlen. Aber die alten Werte, sind noch da!

[pc1246]

Och man
Beim kopieren haben sich leider die Dateirechte veraendert, kaum macht man es richtig!
Danke fuer Eure Geduld
Christoph

[Sailor]

Moin zusammen

was die Geschichte um das "Vacuum" betrifft habe ich folgendes im Internet gefunden: https://www.tutorialspoint.com/sqlite/sqlite_vacuum.htm

Kann man das auf unsere fhem.db anwenden und was hat das für Konsequenzen?

Auto-VACCUM

SQLite Auto-VACUUM does not do the same as VACUUM rather it only moves free pages to the end of the database thereby reducing the database size. By doing so it can significantly fragment the database while VACUUM ensures defragmentation. So Auto-VACUUM just keeps the database small.

You can enable/disable SQLite auto-vacuuming by the following pragmas running at SQLite prompt:
sqlite> PRAGMA auto_vacuum = NONE;  -- 0 means disable auto vacuum
sqlite> PRAGMA auto_vacuum = INCREMENTAL;  -- 1 means enable incremental vacuum
sqlite> PRAGMA auto_vacuum = FULL;  -- 2 means enable full auto vacuum

You can run following command from command prompt to check the auto-vacuum setting:
$sqlite3 database_name "PRAGMA auto_vacuum;"

Gruss
   Sailor

PS: Obwohl meine Datenbank "nur" 1400MB groß ist, dauert der direkte "VACUUM;" - Befehl in der SQLITE3 - Konsole bei vorher gestoppten fhem Service nunmehr schon 10 Minuten an...
Das kann doch nicht gesund sein, oder?

PSPS: Abgeschlossen und nun ist sie nur noch 910MB groß...

[Sidey]

Bitte entschuldigt, dass ich einen so alten Beitrag zitiere.
Bei mir ist die Datenbank mittlerweile auch recht groß und ich möchte mich an das Ausdünnen machen.

Ich möchte das ganze möglichst wenig invasiv auf einzelne Devices beschränken und mir rantasten. Prüfen wie lange es dauert, etc.
Deshalb ist der der Include Parameter für mich interessant:

Vielleicht ist es für viele User verwirrend, dass sie bei include eine Database-deviceRegExp angeben müssen und bei exclude eine Perl-Regexp.

Ich stehe auf dem Schlauch, was eine Database-deviceRegExp sein soll, bzw. warum ich mich als Anwender damit auseinander setzen soll.
Die Regex Syntax unterscheidet sich nach meinem Stand nicht zwischen SQL und Perl.
Für sqlite kann das Paket "Perl regular expressions"

Code Auswählen Erweitern

sqlite3-pcre für sqlite installiert werden.

Wird das im Moment verwendet, wenn es installiert ist? Das Keyword REGEXP habe ich im Quellcode nicht finden können. Demnach nehme ich an, es handelt sich hier um gar keine Regexp sondern um etwas anderes.


Zu dem Thema Blockieren von FHEM, habe ich eventuell auch eine Idee.
Es wäre möglich, die SQL Statements mit einem Limit auszustatten (z.B. immer nur 100 Zeilen) und das ganze über einen internal timer asyncron laufen zu lassen.
Dann wird FHEM zwar in Summe ebenso lange blockiert, aber eben nicht kontinuierlich.

Grüße Sidey

[Masterfunk]

Hi Sailor,

ein simples userReading sollte das tun, z.B. in MB:

Code Auswählen Erweitern

attr dbLog userReadings DbFileSize:lastReduceLogResult.* { (split(' ',`du -m dbLog.db`))[0] }

Funktioniert das nur mit SQLite?

Ich nutze MYSQL und in meinen "lastReduceLogResult" steht nichts von Dateigröße:

   

Code Auswählen Erweitern

Rows processed: 44724, deleted: 0, time: 0.93sec

Gruß Detlef

[rapster]

Zu dem Thema Blockieren von FHEM, habe ich eventuell auch eine Idee.
Es wäre möglich, die SQL Statements mit einem Limit auszustatten (z.B. immer nur 100 Zeilen) und das ganze über einen internal timer asyncron laufen zu lassen.
Dann wird FHEM zwar in Summe ebenso lange blockiert, aber eben nicht kontinuierlich.

Versuche aber den Sinn dahinter zu finden,
entweder einmal 10 Minuten Events verpassen,
oder 5 mal 2 Minuten Events verpassen,
...
dazwischen 1ne Minute warten,
um eine Aktion zu starten von der ich in den nächsten 5 Minuten keine Ahnung mehr habe ob da noch was passiert oder nicht

[genatic]

Moin Sunny,

ja eingefallen schon, nur leider zeitlich noch keine Möglichkeit gehabt... 

Denke wird leider auch noch ein bissi dauern, stehn davor noch paar andere Sachen auf der ToDo zu denen ich leider genausowenig komme, aber vergessen hab ichs nicht 

Gruß
  Claudiu

Hi,
gibt es zum Thema der einstellbaren Intervalle schon was neues?
Ich wäre ebenfalls v.a. an einem 15min-Intervall interessiert.
Grüße

[rapster]

Vergessen hab ichs immer noch nicht, aber das wird wohl trotzdem ein Projekt für ruhige Abende 2017

[Sidey]

Versuche aber den Sinn dahinter zu finden,
entweder einmal 10 Minuten Events verpassen,
oder 5 mal 2 Minuten Events verpassen,
...
dazwischen 1ne Minute warten,
um eine Aktion zu starten von der ich in den nächsten 5 Minuten keine Ahnung mehr habe ob da noch was passiert oder nicht

Ok, ich sehe es ein. Mein Ansatz war zu kurz gedacht.

Ich habe bestimmt noch nicht alle Programmteile von Fhem verstanden.
Mein Stand ist, dass Fhem periodisch die IO Schnittstellen bedient.
Sozusagen ist Fhem immer blockiert, wenn eine Funktion eines Modules aufgerufen wird. In der Regel benötigen diese Funktionen wohl wenig CPU Zeit, so dass weder der Anwender noch die IO Schnittstellen davon in Mitleidenschaft gezogen werden.

Umgangssprachlich spricht man von blockieren wohl immer dann, wenn FHEM beeinträchtigt wird.

Der Programmcode macht wohl zwei Dinge im Moment:
Eine DB Abfrage stellen und auf die Antwort warten.
Je nachdem wie lange die Abfrage dauert, kann man hier von einem Blocking reden.

Eine relativ einfache Option um langlaufende Abfragen auf non blocking zu migrieren, kann sein, auf die Antwort nicht zu aktiv zu warten, sondern immer periodisch über einen Timer prüfen, ob eine Antwort bereits vorliegt.

Im Falle einer Zusammenfassung von Datensätzen:

Danach werden in Perl die erhaltenen Datensätze verarbeitet. Was da passiert habe ich noch nicht durchdrungen.
Ich nehme an, es wird ein Durchschnitt für eine definierte Zeitperiode errechnet.
Ein Datensatz erhält dann via Update diesen Mittelwert und die anderen werden gelöscht.

Ich bin nicht der absolute Datenbank oder FHEM Spezialist, jedoch nehem ich an, dass man überhaupt keine Messwerte verliert, wenn man die CPU Zeit die bei einem Funktionsaufruf verbraucht wird, drastisch reduziert.

Dazu gibt es zwei Ansätze die mir einfallen:
Berechnungen in die Datenbank verlagern und auf die Antwort ansynchron warten.

Berechnungen in FHEM in kleine Transaktionen unterteilen, die nur wenige ms Andauern.


Wie seht ihr das?
Viele Grüße

[chris1284]

ich verstehe ehrlich das problem nicht.
ich fahre jede nacht um 00:10 reducelog 1 ( ca. 6 sek) und danach vaccum (ca 3sek) . meine db ist somit seit geraumer zeit unter ca 50mb groß und nachts stört das blocking nicht. die regelmäßigkeits machts halt (und esparsames loggen)

[rapster]

Ok, ich sehe es ein. Mein Ansatz war zu kurz gedacht.

Ich habe bestimmt noch nicht alle Programmteile von Fhem verstanden.
Mein Stand ist, dass Fhem periodisch die IO Schnittstellen bedient.
Sozusagen ist Fhem immer blockiert, wenn eine Funktion eines Modules aufgerufen wird. In der Regel benötigen diese Funktionen wohl wenig CPU Zeit, so dass weder der Anwender noch die IO Schnittstellen davon in Mitleidenschaft gezogen werden.

Umgangssprachlich spricht man von blockieren wohl immer dann, wenn FHEM beeinträchtigt wird.

Der Programmcode macht wohl zwei Dinge im Moment:
Eine DB Abfrage stellen und auf die Antwort warten.
Je nachdem wie lange die Abfrage dauert, kann man hier von einem Blocking reden.

Eine relativ einfache Option um langlaufende Abfragen auf non blocking zu migrieren, kann sein, auf die Antwort nicht zu aktiv zu warten, sondern immer periodisch über einen Timer prüfen, ob eine Antwort bereits vorliegt.

Im Falle einer Zusammenfassung von Datensätzen:

Danach werden in Perl die erhaltenen Datensätze verarbeitet. Was da passiert habe ich noch nicht durchdrungen.
Ich nehme an, es wird ein Durchschnitt für eine definierte Zeitperiode errechnet.
Ein Datensatz erhält dann via Update diesen Mittelwert und die anderen werden gelöscht.

Ich bin nicht der absolute Datenbank oder FHEM Spezialist, jedoch nehem ich an, dass man überhaupt keine Messwerte verliert, wenn man die CPU Zeit die bei einem Funktionsaufruf verbraucht wird, drastisch reduziert.

Dazu gibt es zwei Ansätze die mir einfallen:
Berechnungen in die Datenbank verlagern und auf die Antwort ansynchron warten.

Berechnungen in FHEM in kleine Transaktionen unterteilen, die nur wenige ms Andauern.


Wie seht ihr das?
Viele Grüße

Ja, es hört sich gut an,
nur mir fällt kein Weg ein es irgendwie zu implementieren,

- ohne das am Ende fhem doch durch die DB-Aktion blockiert wird,
- oder das mehrere Verbindungen zur DB geöffnet werden (sqlite)

Evtl. abfragen ob sqlite oder mysql ..., und dementsprechend in eigenem Process starten und eigene DB-Verbindung öffnen?

EDIT, Den Weg sollte mysql Anwender jetzt schon haben, einfach eine zweite fhem Instanz mit der selbe db-conf starten, und in dieser reduceLog aufrufen.