Größe der configDB

[Prof. Dr. Peter Henning]

Ich benutze nun schon seit langer Zeit die configDB, kann auch darüber nicht meckern.

Allerdings frage ich mich, warum die SQLite-Datei bei gerade mal 18377 config entries und 2548 saved entries sagenhafte 60 MByte groß ist.

Nein, es liegt nicht an fehlenden Re-Organisationen.

Könnte mir mal jemand sagen, wie groß seine SQLite-Datei ist ?

LG

pah

[mahowi]

Meine ist 6,5 MB bei 3686 saved entries.

configdb info:

Code Auswählen Erweitern

-----------------------------------------------------------------
configDB Database Information
-----------------------------------------------------------------
# $Id: configDB.pm 12120 2016-09-05 19:06:04Z betateilchen $
-----------------------------------------------------------------
dbconn: SQLite:dbname=/opt/fhem/configDB.db
dbuser:
dbpass:
dbtype: SQLITE
-----------------------------------------------------------------
config: 9336 entries

Ver 0 saved: Mon Feb  6 18:51:06 2017 def: 272 attr: 1273
Ver 1 saved: Wed Feb  1 17:42:02 2017 def: 272 attr: 1275
Ver 2 saved: Wed Feb  1 16:57:11 2017 def: 272 attr: 1274
Ver 3 saved: Wed Feb  1 16:53:02 2017 def: 276 attr: 1282
Ver 4 saved: Wed Feb  1 16:50:29 2017 def: 280 attr: 1290
Ver 5 saved: Wed Feb  1 16:42:37 2017 def: 278 attr: 1286
-----------------------------------------------------------------
state: 3686 entries saved: Tue Feb  7 09:09:52 2017
-----------------------------------------------------------------
filesave: 50 files stored in database
-----------------------------------------------------------------

Code Auswählen Erweitern

pi@raspberrypi:~ $ ls -lah /opt/fhem/configDB.db
-rw-r--r-- 1 fhem dialout 6,5M Feb  7 09:10 /opt/fhem/configDB.db

[Benni]

Code Auswählen Erweitern


-----------------------------------------------------------------
configDB Database Information
-----------------------------------------------------------------
# $Id: configDB.pm 12120 2016-09-05 19:06:04Z betateilchen $
-----------------------------------------------------------------
dbconn: SQLite:dbname=/opt/fhem/configDB.db
dbuser:
dbpass:
dbtype: SQLITE
-----------------------------------------------------------------
max Versions: 25
config: 150812 entries


Code Auswählen Erweitern


-rw-rw-rw- 1 fhem dialout 200M Feb  7 08:01 configDB.db


[arne.dien]

23 MB bei 15269 entries

Code Auswählen Erweitern

-----------------------------------------------------------------
configDB Database Information
-----------------------------------------------------------------
# $Id: configDB.pm 12120 2016-09-05 19:06:04Z betateilchen $
-----------------------------------------------------------------
dbconn: SQLite:dbname=/opt/fhem/configDB.db
dbuser:
dbpass:
dbtype: SQLITE
-----------------------------------------------------------------
config: 14992 entries

Ver 0 saved: Tue Feb  7 10:56:07 2017 def: 613 attr: 3138
Ver 1 saved: Wed Jan 25 20:27:41 2017 def: 613 attr: 3134
Ver 2 saved: Wed Jan 25 19:56:14 2017 def: 613 attr: 3134
Ver 3 saved: Wed Jan 25 19:49:04 2017 def: 613 attr: 3130
-----------------------------------------------------------------
state: 15269 entries saved: Tue Feb  7 10:56:00 2017
-----------------------------------------------------------------
filesave: 18 files stored in database
-----------------------------------------------------------------

[Prof. Dr. Peter Henning]

Na sieh mal einer an. Wenn ich die meine dumpe, ist der (ungezippte) dump auch nur 2,5 MByte groß.

Scheint also ein SQLite-Problem zu sein, dass die Datei immer wieder überschrieben wird, aber nicht schrumpft, weil die ganzen gelöschten Entries darinnen behalten werden.

Muss man also manuell machen. In einer Kommandozeile eingeben:

Code Auswählen Erweitern


cd /opt/fhem
cp configDb.db configDB.bak
sqlite3 configDB.db
vacuum;
.quit


Neue configDB.db nur noch 1,8 MByte

LG

pah

Note added in Proof:
Betateilchen, wie wäre es denn, in Deinen Code eine Option zur Bereinigung der Datenbank einzubauen ? Sieht zwar für jede DB anders aus, wäre aber sehr nützlich.

[betateilchen]

Ich benutze nun schon seit langer Zeit die configDB, kann auch darüber nicht meckern.

Sehr vorbildlich 

Vorsicht mit dem Dump! In der configDB liegen ggf. auch Binärdateien, die sich nicht so einfach dumpen lassen.

Muss man also manuell machen. In einer Kommandozeile eingeben:

Man kann das Pragma auto_vacuum auch direkt in der Datenbank setzen, so wie es in der commandref beschrieben steht.

Code Auswählen Erweitern


-----------------------------------------------------------------
configDB Database Information
-----------------------------------------------------------------
# $Id: configDB.pm 12120 2016-09-05 19:06:04Z betateilchen $
-----------------------------------------------------------------
dbconn: SQLite:dbname=/opt/fhem/sqldb/configDBprodfhem.db
dbtype: SQLITE
-----------------------------------------------------------------
config: 7532 entries

Ver 0 saved: Sun Jan 29 19:22:49 2017 def: 251 attr: 1633
Ver 1 saved: Sun Jan 29 17:13:13 2017 def: 251 attr: 1633
Ver 2 saved: Sun Jan 29 16:28:43 2017 def: 251 attr: 1631
Ver 3 saved: Sun Jan 29 14:46:07 2017 def: 251 attr: 1627
-----------------------------------------------------------------
state: 1918 entries saved: Tue Feb  7 16:00:00 2017
-----------------------------------------------------------------
filesave: 82 files stored in database
-----------------------------------------------------------------


Code Auswählen Erweitern


-rw-r--r--  1 fhem dialout 7,0M Feb  7 16:00 configDBprodfhem.db


Note added in Proof:
Betateilchen, wie wäre es denn, in Deinen Code eine Option zur Bereinigung der Datenbank einzubauen ? Sieht zwar für jede DB anders aus, wäre aber sehr nützlich.

Erübrigt sich, wenn man auto_vacuum gesetzt hat - genau deshalb steht es ja in der Doku.

[betateilchen]

Das ist hier übrigens der falsche Forumbereich für die configDB - nur so am Rande angemerkt.

[Prof. Dr. Peter Henning]

Man kann das Pragma auto_vacuum auch direkt in der Datenbank setzen, so wie es in der commandref beschrieben steht.

Dazu sagt aber sqlite:

An alternative to using the VACUUM command to reclaim space after data has been deleted is auto-vacuum mode, enabled using the auto_vacuum pragma. When auto_vacuum is enabled for a database free pages may be reclaimed after deleting data, causing the file to shrink, without rebuilding the entire database using VACUUM. However, using auto_vacuum can lead to extra database file fragmentation. And auto_vacuum does not compact partially filled pages of the database as VACUUM does.

Das ist hier übrigens der falsche Forumbereich für die configDB - nur so am Rande angemerkt.

Mag sein - dann sollte das aber irgendwo vermerkt sein. Ich hatte nicht die Geduld, länger als 2 Minuten zu suchen, ich gebs ja zu.

LG

pah

[betateilchen]

Mag sein - dann sollte das aber irgendwo vermerkt sein. Ich hatte nicht die Geduld, länger als 2 Minuten zu suchen, ich gebs ja zu.

Das steht - wie für alle anderen (hoffentlich auch Deine) Module - in der MAINTAINER.txt und  muss nicht lange gesucht werden.

Die Diskussion zu auto_vacuum gab es vor einigen Monaten schon einmal mit Rudi. Die Doku zu SQLITE ist da etwas verwirrend und ungenau.
Wenn Du das Komprimieren unbedingt manuell machen willst, habe ich trotzdem noch einen Tipp für Dich:

Das hier:

Code Auswählen Erweitern


sqlite3 configDB.db
vacuum;
.quit


kannst Du auf Betriebssystemebene auch einfach so machen:

Code Auswählen Erweitern


sqlite3 configDB.db vacuum


und läßt sich damit auch völlig simpel per cronjob einplanen.

[Benni]

Und wenn man auto_vacuum verwenden will ist folgende Information wichtig:

auto-vacuuming must be turned on before any tables are created

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

[n0bbi]

Was spricht eigentlich gegen Autovacuum? Könnte man das nicht im Wiki/Commandref beim Anlegen der DB mit berücksichtigen? (Lässt sich ja nachträglich leider nicht mehr ändern)
Ich habe ein ähnliches Problem bei meiner dblog und das jetzt erstmal mit einem Cronjob gelöst.

[Benni]

Was spricht eigentlich gegen Autovacuum? Könnte man das nicht im Wiki/Commandref beim Anlegen der DB mit berücksichtigen? (Lässt sich ja nachträglich leider nicht mehr ändern)
Ich habe ein ähnliches Problem bei meiner dblog und das jetzt erstmal mit einem Cronjob gelöst.

Doch das geht auch nachträglich, ist halt etwas aufwändiger:
Dump der Db machen -> Leere Db neu anlegen -> auto_vacuum aktivieren -> Dump wieder einspielen

[betateilchen]

Was spricht eigentlich gegen Autovacuum?

Nichts.

Könnte man das nicht im Wiki/Commandref beim Anlegen der DB mit berücksichtigen?

Es steht in der commandref, seit es eine commandref zu configDB gibt.

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$
         
The database tables will be created automatically.

[n0bbi]

Ah sorry, nehme alles zurück und behaupte das Gegenteil

Gesendet von meinem Nexus 5X mit Tapatalk

[Amenophis86]

@Betateilchen: Macht es nicht vielleicht auch Sinn, dass du das mit auto_vaccum in deinem Workshop (https://forum.fhem.de/index.php/topic,54055.0.html) einbaust? Da kann ich es nicht sehen.

[betateilchen]

Macht es nicht vielleicht auch Sinn, dass du das mit auto_vaccum in deinem Workshop einbaust?

Nein.

[Amenophis86]

Ich liebe deine Antworten Und sagst du mir auch wieso? Hätte ich direkt dazu sagen sollen, habe ich vergessen. Sry

[Hauswart]

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.

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

Dazu habe ich eine Verständisfrage, auto_vacuum=2 aktiviert nur das Verkleinern, aber das aktive Verkleinern muss ich danach mit sqlite2 fhem.db vacuum ausführen?

@betateilchen wieso macht es keinen Sinn dies in den Workshop einzubauen? Bzw. oder ins Wiki (https://wiki.fhem.de/wiki/DbLog#Beispiel:_Anlegen_und_Nutzung_einer_SQLite-Datenbank).



Gruss

PS: Immer noch unschlüssig ob MySQL oder sqlite

[betateilchen]

Vielleicht könnten die Leute, die mir hier permanent versuchen, gute Tipps zu meinem Workshop zu geben, diesen erst einmal selbst absolvieren, dann erledigen sich viele Vorschläge von ganz alleine.

• der Workshop hat das Bestreben, für den Teilnehmer so einfach wie möglich verständlich zu sein.
• in dem Workshop wird überhaupt keine Datenbank neu angelegt.
• das Datenbankverhalten und die Zugriffsverfahren von DbLog und configDB sind grundsätzlich unterschiedlich und sollten nicht dauernd durcheinander geworfen werden.
• WIKI Einträge zu meinen Modulen mag ich genauso sehr wie Fußpilz. Unsinn, der aus gefährlichem Halbwissen resultiert, weil irgendjemand meint, meine Module besser beschreiben zu können als ich in der commandref, ist unglaublich schwer wieder aus den Köpfen derjenigen rauszukriegen, die ihn einmal gelesen haben. Und ich selbst werde nicht zwei Dokumentationen pflegen - für mich ist das verbindlich, was in der commandref steht.

PS: Immer noch unschlüssig ob MySQL oder sqlite

Völlig egal.

Meine produktive configDB liegt aktuell in einer SAP HANA Datenbank, ich wollte einfach wissen, ob/wie das geht.

[Hauswart]

Mmh eine Frage habe ich dazu aber noch, die configDB.db im Contrib-Ordner hat diese das Attribut schon gesetzt oder würdest du zum Manuellen anlegen der DB raten (siehe Commandref) und das Setzen empfehlen?

Die Unterschiede bei Dblog und configDB sind mir ehrlich gesagt nicht ganz klar (bin bisher nur mit Files für Konfig & Logs unterwegs), da ich in der Commandref bei dblog (und auch im Contrib bei dblog) nichts gefunden habe, auto_vacuum auch bei dblog aktivieren?

Meine produktive configDB liegt aktuell in einer SAP HANA Datenbank, ich wollte einfach wissen, ob/wie das geht.

Das finde ich nun sehr interessant. Leider liegt unser SAP auf einem MySQL und wird es wohl auch noch länger... Völlig egal - naja. Eine Migration von sqlite zu MySQL bzw. andersherum ist leider kaum machbar, d.h. es ist quasi mehr oder weniger eine Grundsatzentscheidung (Thematik: Dblog und configDB).

[Prof. Dr. Peter Henning]

WIKI Einträge zu meinen Modulen mag ich genauso sehr wie Fußpilz

Das Vorhandensein von Fußpilz richtet sich aber nicht nach dem "Mögen" oder "Nichtmögen".

LG

pah

[Beta-User]

Eine Migration von sqlite zu MySQL bzw. andersherum ist leider kaum machbar, d.h. es ist quasi mehr oder weniger eine Grundsatzentscheidung.

Na ja, man kann immer noch hergehen und den Umweg über die Speicherung einer aktuellen fhem.cfg machen (attr. global, im Wiki verlinkt). Diese kann man dann wieder in das nächste DB-System einspeisen. Andere Files kann man über die Export-Funktion rausspeichern, sofern erforderlich (nutze nur fhem.cfg@sqlite).

Kann also Interessierten nur empfehlen, configDB mal auszutesten. Der Vorteil, den ich als normaler User sehe ist der, dass die fhem.cfg-Variante sehr empfindlich ist, wenn Devices, die fhem als "hart" vorhanden voraussetzt (z.B. 1-wire@OWX) löscht, wenn sie nicht erreichbar sind. Speichert man dann die config, ist das Device weg und man muss es über Sicherungskopien reparieren.

Nachteil (bitte nicht verhauen, wenn es nicht stimmt): Die Reihenfolge zu ändern, in der Devices gespeichert werden, ist unmittelbar in der DB kaum möglich. Ob das erforderlich wäre, kann ich nicht sagen, ich bräuchte mal eine ruhige Minute, um z.B. eine VCCU einzurichten und dann das IO/device von CUL (zu löschen) auf serielles PI-Modul umzustellen. Aber auch configDB scheint nichts daran zu ändern, dass die Devices in einer sinnvollen Abfolge geladen werden müssen.

Just m2ct.

@pah und die anderen Kritiker von betateilchens klarer Kante:
Man muß diese Position nicht mögen, aber die Dinge sind in sich konsistent und entsprechen den Vorgaben (verpflichtend ist NUR eine englische Commandref)! M.E. weisen wir nur zu selten auf diesen Umstand hin .

[Prof. Dr. Peter Henning]

Das ist ein Missverständnis - keineswegs kritisiere ich seine "klare Kante" (ausgerechnet ich ...).
Man muss nur immer aufpassen, dass man das Kind nicht mit dem Bade ausschüttet - und das scheint mir der Fall zu sein, wenn man komplett auf eine erläuternde Dokumentation verzichtet.

Ist eine Frage der pädagogischen Erfahrung sozusagen.

LG

pah

[Amenophis86]

Hab jetzt noch keinen Grund gehört, wieso der Vaccum Befehl nicht in den Workshop sollte, außer, dass er einfach sein soll. Sehe ich jetzt nicht als komplizierten Schritt an, besonders, wenn er in der Commandref drin steht und im Workshop nicht. Das ist für mich nicht verständlich. Und versucht dir zu erklären, wie es besser geht, habe ich auch nicht, lediglich nachgefragt. Aber gut, habe verstanden, dass du es nicht willst und damit soll es für mich auch gut sein. Mehr als Fragen kann und will ich nicht

@Beta-User: Sehe nicht wo ich seine Kante kritisiert habe. Im Gegenteil:

Ich liebe deine Antworten Und sagst du mir auch wieso? Hätte ich direkt dazu sagen sollen, habe ich vergessen. Sry

[Beta-User]

@pah und wer auch immer sich potentiell angesprochen fühlt:
...das mit "Kritik" war nicht böse gemeint, ich wollte nur zum Ausdruck bringen, dass ich diese Haltung nach meinem ersten (zugegebenermaßen sehr irritierenten) Kontakt damit nunmehr für ok halte, zumal die Doku in der Commandref m.E. vollständig zu sein scheint und der Wiki-Artikel exisitert, wenn auch im Wesentlichen nur mit dem Hinweis, dass die Commandref zu Rate zu ziehen ist. So landet man wenigstens zielgerichtet beim aktuellen "Stand der Dinge" (allerdings nicht bei dem die Einrichtung für DAU's vereinfachenden workshop, warum auch immer...).

Dass das deutlich werbewirksamer geht, ist wohl wahr, andererseits verhindert diese sehr technische Darstellung, dass sich die falschen Leute auf configDB einlassen und erfüllt gerade damit möglicherweise den beabsichtigten Zweck (oder ist doch eine flächendeckende Einführung von configDB angestrebt?).

Eine Anmerkung noch zum workshop (und zum Beitrag von Amenophis86): kaum ein minderbegabter Normaluser wie ich wäre darauf gekommen, dass die Vorlage für sqlite einem schon das Einrichten von auto_vacuum abnimmt (so habe ich den Beitrag vn Hauswart verstanden). Insoweit wäre vielleicht ein Hinweis auf diesem Umstand im workshop eine Anregung, nur für den Fall, dass jemand sich die Mühe macht, parallel den workshop durchzuarbeiten und in die commandref zu schauen .

Unbedarfte Grüße,

Beta-User

[Amenophis86]

Eine Anmerkung noch zum workshop (und zum Beitrag von Amenophis86): kaum ein minderbegabter Normaluser wie ich wäre darauf gekommen, dass die Vorlage für sqlite einem schon das Einrichten von auto_vacuum abnimmt (so habe ich den Beitrag vn Hauswart verstanden).

Wenn dem so sein sollte, was ich leider nicht nachvollziehen kann, da ich keine Editor für die db Datei habe, dann wäre es natürlich schön. Dann wiederum verstehe ich auch, wieso es nicht im Workshop steht, weil es schon dabei ist und eh nicht jede Funktion erklärt wird und warum es in der CommandRef steht, wo quasi die komplette DB angelegt wird. Und ich sage mal so, wenn man vielleicht diesen Halbsatz zum "Nein" noch dazu geschrieben hätte, wäre die komplette Diskussion hinfällig. So hatten wir wenigstens alle ein bisschen Spaß

[Hauswart]

Eine Anmerkung noch zum workshop (und zum Beitrag von Amenophis86): kaum ein minderbegabter Normaluser wie ich wäre darauf gekommen, dass die Vorlage für sqlite einem schon das Einrichten von auto_vacuum abnimmt (so habe ich den Beitrag vn Hauswart verstanden). Insoweit wäre vielleicht ein Hinweis auf diesem Umstand im workshop eine Anregung, nur für den Fall, dass jemand sich die Mühe macht, parallel den workshop durchzuarbeiten und in die commandref zu schauen .

Das war bisher nur eine unbestätigte Vermutung.

Die Konfig kann ich aus sqlite wieder exportieren und danach in z.B. MySQL importieren, aber wenn ich sqlite für die Konfig einsetze, dann auch für die Logs von daher muss ich es mir vorher schon überlegen Wenn sqlite dann alles, wenn MySQL dann alles

Gruss

[mahowi]

Gibt es eigentlich Vor-/Nachteile von sqlite bzw. MySQL, die einem die Entscheidung für das eine oder andere erleichtern?

[Beta-User]

Das war bisher nur eine unbestätigte Vermutung.

Hoffentlich bekommen wir dazu eine fachkundige Antwort, ebenso zu Deiner Frage, ob man das dann jeweils auch gesondert anstoßen muß...

aber wenn ich sqlite für die Konfig einsetze, dann auch für die Logs von daher muss ich es mir vorher schon überlegen Wenn sqlite dann alles, wenn MySQL dann alles

Einerseits nachvollziehbar (war auch mal mein Ansatz), andererseits ist das nicht zwingend. Man kann durchaus sqlite für configDB nehmen und MySQL für die logs (macht u.U. schon deswegen Sinn, weil eine "lokale" config fhem jendefalls starten läßt und (@mahowi) MySQL auf einem PI eher wenig Spaß zu machen scheint). So man die logs überhaupt umstellt (scheint entgegen den Werbeaussagen eher zu einem trägen System zu führen bzw. geführt zu haben ). Nicht jeder hat schließlich einen performanten MySQL-Server zuhause .

Richtig ist jedenfalls, dass dblog und configDB zwei unterschiedliche Paar Schuhe sind.

[n0bbi]

Also auf meinem PI hat die Umstellung auf logdb einen enormen Geschwindigkeitszuwachs gebracht.

Was mir allerdings noch nicht ganz klar ist, ist was mir die Configdb für Vorteile bringt? Geschwindigkeit kann es ja eigentlich kaum sein, gibt es andere Gründe umzustellen?

Danke

Gesendet von meinem Nexus 5X mit Tapatalk

[betateilchen]

Gibt es eigentlich Vor-/Nachteile von sqlite bzw. MySQL, die einem die Entscheidung für das eine oder andere erleichtern?

Der größte Vorteil von sqlite ist, dass die komplette Datenbank in einem einzigen File enthalten ist, was den Transfer auf neue Installationen und die Datensicherung erheblich vereinfacht, weil man einfach nur eine Datei kopieren muss.

Um auf die im Workshop verwendete sqlite-Vorlage zurückzukommen:

Code Auswählen Erweitern


MBA:~ fhem$ cd ./contrib/configDB/
MBA:configDB udo$ ls
README configDB.conf configDB.db
MBA:configDB udo$ sqlite3 configDB.db
SQLite version 3.16.0 2016-11-04 19:09:39
Enter ".help" for usage hints.
sqlite> pragma auto_vacuum;
2
sqlite> .quit


Wie man eindeutig und ohne großen Aufwand sieht, ist das auto_vacuum in der Vorlage bereits gesetzt. Deshalb gibt es auch keinen Grund, warum ich auf den Umstand dieses Parameters im Workshop explizit hinweisen sollte. Der Workshop ist einfach dazu gedacht, zu zeigen, wie einfach ein Umstieg auf die Datenbank sein kann und dass der Anwender keine Angst wegen "von Datenbanken habe ich keine Ahnung" haben muss.

In der commandref sind die Details enthalten, dort steht auch, wie man die Einrichtung manuell und ohne Vorlage vornehmen kann.

Was mir allerdings noch nicht ganz klar ist, ist was mir die Configdb für Vorteile bringt? Geschwindigkeit kann es ja eigentlich kaum sein, gibt es andere Gründe umzustellen?

Ja, es gibt durchaus noch andere Gründe. Das wurde auch in der Vergangenheit schon mehrfach im Forum diskutiert.

[Amenophis86]

Danke für die ausführliche Antwort und der Bestätigung, dass Vaccum schon drin ist

[Invers]

Wie wurde denn hier

Code Auswählen Erweitern

max Versions: 25
erzeugt? in der Commandref habe ich nichts dazu gefunden

Code Auswählen Erweitern


-----------------------------------------------------------------
configDB Database Information
-----------------------------------------------------------------
# $Id: configDB.pm 12120 2016-09-05 19:06:04Z betateilchen $
-----------------------------------------------------------------
dbconn: SQLite:dbname=/opt/fhem/configDB.db
dbuser:
dbpass:
dbtype: SQLITE
-----------------------------------------------------------------
max Versions: 25
config: 150812 entries


Code Auswählen Erweitern


-rw-rw-rw- 1 fhem dialout 200M Feb  7 08:01 configDB.db


[betateilchen]

Wie wurde denn hier

Code Auswählen Erweitern

max Versions: 25
erzeugt?

Code Auswählen Erweitern

configdb attr maxversions 25

Danke für den Hinweis, das steht tatsächlich noch nicht in der commandref, was ich komisch finde. Wird schnellstens korrigiert

[Benni]

das steht tatsächlich noch nicht in der commandref, was ich komisch finde

Die configdb kennt übrigens schon sehr lange ein eigenes (nicht dokumentiertes) Attribut "maxversions"

[Invers]

Hatte ich probiert, aber leider keine Auswirkungen festgestellt, da die überzähligen Versionen dadurch nicht gelöscht wurden.
Habe ich nun gemacht und nun läuft es auch mit der Begrenzung.
Danke.

[betateilchen]

Hatte ich probiert, aber leider keine Auswirkungen festgestellt, da die überzähligen Versionen dadurch nicht gelöscht wurden.

Das Löschen überzähliger Versionen passiert erst beim nächsten "save config", nicht direkt nach dem Setzen des Attributes.

Technisch gesehen passiert dann beim Speichern nix Anderes als bei einem "configdb reorg 25" mit dem man tatsächlich den vorhandenen Bestand auf 25 Versionen bringen kann. Bei mir läuft das nachts per "at" mit einer Begrenzung auf 5.

[Prof. Dr. Peter Henning]

was ich komisch finde

Meine Familie behauptet immer, ich hätte einen schrägen Humor. Der ist aber gar nichts gegen Deinen.

LG

pah

[betateilchen]

Als Ergebnis dieser Diskussion habe ich heute zwei Änderungen bezüglich der Datenbankgröße in die configDB eingebaut

1. Ausgabe der Datenbankgröße (nur bei Verwendung von sqlite) in "configdb info"

-----------------------------------------------------------------
configDB Database Information
-----------------------------------------------------------------
# $Id: configDB.pm 13382 2017-02-10 20:48:14Z betateilchen $
-----------------------------------------------------------------
dbconn: SQLite:dbname=/opt/fhem/sqldb/configDBprodfhem.db
dbtype: SQLITE
dbsize: 1.69 MB
-----------------------------------------------------------------
config: 7538 entries

Ver 0 saved: Thu Feb  9 20:43:27 2017 def: 251 attr: 1633
Ver 1 saved: Sun Jan 29 19:22:49 2017 def: 251 attr: 1633
Ver 2 saved: Sun Jan 29 17:13:13 2017 def: 251 attr: 1633
Ver 3 saved: Sun Jan 29 16:28:43 2017 def: 251 attr: 1631
-----------------------------------------------------------------
state: 1989 entries saved: Fri Feb 10 22:00:00 2017
-----------------------------------------------------------------
filesave: 82 files stored in database
-----------------------------------------------------------------

2. explizites vacuum (nur bei Verwendung von sqlite) bei Ausführung von "configdb reorg"


Diese Änderungen kommen morgen per update, sie sind jetzt schon in svn verfügbar.

[Beta-User]

Wegen Mobbingleistenblocker: Thumbs up!

Könntest Du auch noch was zum Thema Reihenfolge der Geräte innerhalb der configDB sagen?
Wäre nett, denn morgen war der Plan, ein 2. MySensors-GW (RS485) in Betrieb zu nehmen und darüber nach und nach einige meiner bisherigen Nodes zu betreiben (aber eben nicht alle, sonst hätte es gereicht, die Definitionen entsprechend zu tauschen).

Und das Thema mit der VCCU wäre iVm. dem Einsatz eines USB-HMUART dran...

[Benni]

Als Ergebnis dieser Diskussion habe ich heute zwei Änderungen bezüglich der Datenbankgröße in die configDB eingebaut

Nett!  Danke!

Update 13.02.2017:

Nach Aufräumarbeiten in FHEM, update und reorg nun statt 200MB nur noch 17MB

Code Auswählen Erweitern


-----------------------------------------------------------------
configDB Database Information
-----------------------------------------------------------------
# $Id: configDB.pm 13382 2017-02-10 20:48:14Z betateilchen $
-----------------------------------------------------------------
dbconn: SQLite:dbname=/opt/fhem/configDB.db
dbuser:
dbpass:
dbtype: SQLITE
dbsize: 17.01 MB
-----------------------------------------------------------------
max Versions: 25
config: 150757 entries


[betateilchen]

Könntest Du auch noch was zum Thema Reihenfolge der Geräte innerhalb der configDB sagen?

Eigentlich sollten Deine geplanten Änderungen problemlos funktionieren.