FHEM Probleme...

[CoolTux]

Code Auswählen Erweitern


-----------------------------------------------------------------
configDB Database Information
-----------------------------------------------------------------
# $Id: configDB.pm 11560 2016-05-29 19:46:13Z betateilchen $
-----------------------------------------------------------------
dbconn: mysql:database=fhemConfigDB;host=localhost;port=3306
dbuser:
dbpass:
dbtype: MYSQL
-----------------------------------------------------------------
config: 36866 entries

Ver 0 saved: Tue Jun 14 07:19:31 2016 def: 501 attr: 2849
Ver 1 saved: Mon Jun 13 06:31:27 2016 def: 501 attr: 2849
Ver 2 saved: Mon Jun 13 06:24:53 2016 def: 501 attr: 2849
Ver 3 saved: Sun Jun 12 21:54:30 2016 def: 501 attr: 2849
Ver 4 saved: Sat Jun 11 14:28:49 2016 def: 501 attr: 2849
Ver 5 saved: Sat Jun 11 13:33:11 2016 def: 501 attr: 2849
Ver 6 saved: Sat Jun 11 13:32:10 2016 def: 502 attr: 2849
Ver 7 saved: Sat Jun 11 13:27:25 2016 def: 502 attr: 2849
Ver 8 saved: Sat Jun 11 13:24:24 2016 def: 502 attr: 2849
Ver 9 saved: Sat Jun 11 13:20:46 2016 def: 502 attr: 2849
Ver 10 saved: Sat Jun 11 13:15:03 2016 def: 502 attr: 2849
-----------------------------------------------------------------
state: 5900 entries saved: Tue Jun 14 07:19:25 2016
-----------------------------------------------------------------
filesave: 31 files stored in database
-----------------------------------------------------------------


Code Auswählen Erweitern


232M Jun 14 20:50 fhemconfig.ibd


[Benni]

Code Auswählen Erweitern


-----------------------------------------------------------------
configDB Database Information
-----------------------------------------------------------------
# $Id: configDB.pm 11560 2016-05-29 19:46:13Z betateilchen $
-----------------------------------------------------------------
dbconn: SQLite:dbname=/opt/fhem/configDB.db
dbtype: SQLITE
-----------------------------------------------------------------
max Versions: 25
config: 149877 entries

Ver 0 saved: Sat Jun 11 05:17:33 2016 def: 773 attr: 5019
Ver 1 saved: Fri Jun 10 22:50:04 2016 def: 773 attr: 5012
Ver 2 saved: Tue Jun  7 08:47:36 2016 def: 772 attr: 5008
Ver 3 saved: Tue Jun  7 08:45:56 2016 def: 772 attr: 5007
Ver 4 saved: Tue Jun  7 07:05:06 2016 def: 772 attr: 5006
Ver 5 saved: Mon Jun  6 09:45:47 2016 def: 771 attr: 5002
Ver 6 saved: Mon Jun  6 09:35:51 2016 def: 771 attr: 5002
Ver 7 saved: Mon Jun  6 09:32:28 2016 def: 771 attr: 5002
Ver 8 saved: Mon Jun  6 08:29:34 2016 def: 771 attr: 5002
Ver 9 saved: Mon Jun  6 08:28:36 2016 def: 771 attr: 5002
Ver 10 saved: Mon Jun  6 08:22:43 2016 def: 771 attr: 5001
Ver 11 saved: Mon Jun  6 08:08:10 2016 def: 771 attr: 5000
Ver 12 saved: Mon Jun  6 07:52:29 2016 def: 771 attr: 4999
Ver 13 saved: Fri Jun  3 23:18:18 2016 def: 770 attr: 4992
Ver 14 saved: Fri Jun  3 22:45:50 2016 def: 769 attr: 4990
Ver 15 saved: Fri Jun  3 16:31:38 2016 def: 769 attr: 4990
Ver 16 saved: Thu Jun  2 18:40:03 2016 def: 767 attr: 4986
Ver 17 saved: Thu Jun  2 10:24:37 2016 def: 767 attr: 4986
Ver 18 saved: Tue May 31 22:33:16 2016 def: 767 attr: 4986
Ver 19 saved: Tue May 31 17:59:18 2016 def: 767 attr: 4985
Ver 20 saved: Wed May 25 14:57:15 2016 def: 766 attr: 4981
Ver 21 saved: Tue May 24 21:50:08 2016 def: 766 attr: 4979
Ver 22 saved: Mon May 23 22:08:38 2016 def: 766 attr: 4979
Ver 23 saved: Mon May 23 22:01:35 2016 def: 766 attr: 4978
Ver 24 saved: Mon May 23 22:00:16 2016 def: 766 attr: 4978
Ver 25 saved: Mon May 23 21:55:37 2016 def: 766 attr: 4977
-----------------------------------------------------------------
state: 8916 entries saved: Sat Jun 11 05:17:33 2016
-----------------------------------------------------------------
filesave: 72 files stored in database
-----------------------------------------------------------------


Code Auswählen Erweitern


200M Jun 14 11:38 configDB.db


[Marie]

Bei mir sind es nur 9212 Entries und max 6 Versionen...dafür aber 182 MB...

[Wernieman]

Kenn mich jetzt nicht sooo mit SQL-Light aus, aber auffällig ist:

Code Auswählen Erweitern


User                Einträge    DB-Größe
------------------------------------------------
betateilchen     8768          7,5M
CoolTux           36866      232M
Benni             149877     200M
Marie                  9212     182M


Meines Wissens sollte man "hin und wieder" bei SQL-light die DB "optimieren", vor allem nach größeren "Löschvorgängen".  Fragt mich bitte jetzt nur nicht wie ...

[CoolTux]

Naja, ganz so einfach ist das nicht. Du weisst ja nicht was noch alles mit in der DB an binär Files drin steckt.   

[betateilchen]

Doch, es ist eigentlich ganz einfach, wenn man sich an die Vorschläge hält, die in der commandref stehen.
Und mit gespeicherten Binärdateien in der Datenbank hat das überhaupt nichts zu tun.

Code Auswählen Erweitern



Create an empty database, e.g. with sqlite3:

mba:fhem udo$ sqlite3 configDB.db

SQLite version 3.7.13 2012-07-17 17:46:21
Enter ".help" for instructions
Enter SQL statements terminated with a ";"
sqlite> pragma auto_vacuum=2;
sqlite> .quit

mba:fhem udo$



Das Entscheidendene ist das pragma auto_vacuum=2, das dafür sorgt, dass die Datenbank durch eine Löschung auch tatsächlich kleiner wird. Das Beispiel bezieht sich auf sqlite wo das extrem wichtig ist. Denn ansonsten wird die Datenbank einfach weitergeschrieben und das sqlite-File dadurch immer größer (übrigens nicht nur für configDB relevant, sondern auch bei DbLog)

Wie andere Datenbanksysteme das handhaben, weiß ich nicht so genau.

[rudolfkoenig]

Ich habe keine Erfahrung mit auto_vacuum, aber interessiert (nicht wg. FHEM, da setze ich weiterhin auf fhem.cfg), und wuerde gerne wissen, welche der beiden Aussagen richtig ist:

Das Entscheidendene ist das pragma auto_vacuum=2, das dafür sorgt, dass die Datenbank durch eine Löschung auch tatsächlich kleiner wird.

https://www.sqlite.org/pragma.html#pragma_auto_vacuum

When the value of auto-vacuum is 2 or "incremental" then the additional information needed to do auto-vacuuming is stored in the database file but auto-vacuuming does not occur automatically at each commit as it does with auto_vacuum=full.  In incremental mode, the separate incremental_vacuum pragma must be invoked to cause the auto-vacuum to occur.

[betateilchen]

Aller guten Dinge sind drei:

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.

Und dass die Datenbank tatsächlich klein bleibt, ist ja in der vorangegangenen Tabelle von Werniemann eindeutig belegt.

(auto_vacuum=2 und auto_vacuum=full sind in diesem Zusammenhang äquivalent)

nicht wg. FHEM, da setze ich weiterhin auf fhem.cfg

ach Rudi...

[rudolfkoenig]

auto_vacuum=2 und auto_vacuum=full sind in diesem Zusammenhang äquivalent

Laut sqlite Doku ist 2=incremental, und 1=full
Deswegen meine Verwirrung.

[betateilchen]

Komm, jetzt verwirren wir die Anwender endgültig...

Du hast völlig recht: 1 = FULL, 2 =  INCREMENTAL

Aber: mit "äquivalent" meinte ich, dass es im "Einsatzfall" der configDB egal ist, ob man das mit 1 oder 2 setzt, da configDB nicht mit einer permanent geöffneten Datenbank arbeitet und es deshalb egal ist, ob eine auto_vacuum (also das Verschieben von leerem Speicherplatz an das Ende der Datenbank) nach jedem commit (auto_vacuum=1) ausgeführt wird oder nicht (auto_vacuum=2). Ein gesetztes auto_vacuum findet auf jeden Fall beim Schließen der Datenbankverbindung statt.

Sorry für die Verwirrung, ich hatte mich wirklich unglücklich ausgedrückt. Vielleicht hätte ich statt "äquivalent" besser "egal" schreiben sollen.

[Wernieman]

Bei anderen Datenbnken wird es im "Prinzip" ähnlich gemacht. Allerdings kümmert sich der Server (meistens) um das automatische Aufräumen. Nur in Extremfällen wie z.B. löschen vieler Daten (oder Platzmangel auf der HDD) macht man ein optimieren der Datenbankfiles.

Allerdings kann es bei mysql unter Umständen besser sein, nicht zu optimieren ... allerdings nur für (für fhem uninteressante) Havy-Load-DBs

Aber als Kurzfasung:
Wenn ich mir betateilchens DB-Daten und die der anderen ansehe (und anderer Informationen), würe ich auf jedem Falle die DBs optimieren. Und wenn, wie CoolTux angedeutet, mehr in der DB steht, sollte man erst recht optimieren ...