Hi,
ich habe fhem neu installiert auf Debian, und habe anschließend mein letztes Backup zurückgespielt, soweit läuft auch alles, alllerdings stürzt Fhem von zeit zu zeit ab mit diesem Fehler im Log
DBD::SQLite::db prepare failed: no such table: history at ./FHEM/93_DbLog.pm line 2567.
Scheint irgendwas beim Backup zurückspielen nicht funktioniert zu haben, wie kann ich diesen Fehler beseitigen?
Danke
ich kenne DBlog jetzt nicht,
aber in der commandref https://fhem.de/commandref_DE.html#DbLog steht
ZitatVorbereitungen
Zunächst muss die Datenbank angelegt werden.
Beispielcode bzw. Scripts zum Erstellen einer MySQL/PostgreSQL/SQLite Datenbank ist in contrib/dblog/<DBType>_create.sql enthalten. Die Datenbank beinhaltet 2 Tabellen: current und history.
und ich vermute mal das in deiner datenbank keine tabelle history vorhanden ist (jedenfalls sagt das deine fehlermeldung :) )
also script ausführen zum anlegen der tabellen!
Guten Morgen,
Mach mal bitte einen "set ... configCheck" und poste mal was da rauskommt.
Die Meldung besagt ja dass die Tabelle history nicht da ist wie nils_ schon schrieb. Wie hast du denn das Backup zurück gespielt ?
Damit dein FHEM nicht abstürzt, kannst in den asynchronen Modus umschalten. Das beseitigt zwar den Fehler nicht, wird aber (wahrscheinlich) dein FHEM nicht in Mitleidenschaft ziehen.
Grüße
Heiko
Zitat von: DS_Starter am 10 Januar 2018, 08:40:55
Guten Morgen,
Mach mal bitte einen "set ... configCheck" und poste mal was da rauskommt.
Die Meldung besagt ja dass die Tabelle history nicht da ist wie nils_ schon schrieb. Wie hast du denn das Backup zurück gespielt ?
Damit dein FHEM nicht abstürzt, kannst in den asynchronen Modus umschalten. Das beseitigt zwar den Fehler nicht, wird aber (wahrscheinlich) dein FHEM nicht in Mitleidenschaft ziehen.
Grüße
Heiko
Hi,
der config Check sagt
Result of connection check
Connection to database was not successful.
Recommendation: Plese check logfile for further information.
Ich hab mal asyncMode eingeschaltet, mal sehen ob der absturz noch kommt
Das Backup habe ich zurück gespielt in dem ich das vorher über Fhem angelegte Backup in der neuen Fhem installation entpackt habe und alle vorhanden Dateien überschrieben habe
im Fhem verzeichniss scheinen auch alle benötigten Daten dazu sein!?
ls -l
total 728
-rw-r--r-- 1 fhem dialout 1 Jan 10 05:56 AlarmFILE
drwxr-xr-x 2 fhem dialout 4096 Jan 10 05:53 backup
drwxr-xr-x 2 fhem dialout 4096 Dec 18 2014 cache
drwx--x--x 2 fhem dialout 4096 Jan 10 06:32 certs
-rw-r--r-- 1 fhem dialout 225412 Jan 10 05:56 CHANGED
-rw-r--r-- 1 fhem dialout 39189 Jan 10 05:56 configDB.pm
drwxr-xr-x 41 fhem dialout 4096 Sep 3 2016 contrib
-rw-r--r-- 1 fhem dialout 93 Jan 10 05:56 db.conf
drwxr-xr-x 3 fhem dialout 4096 Feb 22 2015 demolog
drwxr-xr-x 4 fhem dialout 4096 Jul 29 02:30 docs
drwxr-xr-x 6 fhem dialout 28672 Dec 26 20:17 FHEM
-rw-r--r-- 1 fhem dialout 124035 Jan 10 06:48 fhem.cfg
-rw-r--r-- 1 fhem dialout 15740 Jan 10 05:56 fhem.cfg.demo
-rw-r--r-- 1 fhem dialout 4096 Jan 10 06:05 fhem.db
-rw-r--r-- 1 fhem dialout 32768 Jan 10 07:15 fhem.db-shm
-rw-r--r-- 1 fhem dialout 0 Jan 10 07:15 fhem.db-wal
-rwxr-xr-x 1 fhem dialout 142055 Jan 10 05:56 fhem.pl
Die db.con sieht auch sauber aus!?
%dbconfig= (
connection => "SQLite:dbname=/opt/fhem/fhem.db",
user => "",
password => ""
);
ZitatDas Backup habe ich zurück gespielt in dem ich das vorher über Fhem angelegte Backup in der neuen Fhem installation entpackt habe und alle vorhanden Dateien überschrieben habe
Das über FHEM angelegte Backup enthält nicht dein SQLite-Datenbankfile.
So wie dein Check ausgibt, hast du momentan keine DB in die irgendwas geloggt werden kann. DbLog kannst du erstmal disablen, kannst du so nicht nutzen.
Ich hoffe du hast Filebackups deiner vormaligen Installation gemacht. Dort ist dein SQLite File mit drin (meist fhem.db)
Spiele das wieder an die richtige Stelle zurück und enable DbLog dann wieder. Danach wieder configCheck.
Edit: achte auch darauf dass dein Konfigurationsfile vorhanden ist, siehst du im DEF von DbLog welches das ist. Dort steht ja auch deine verwendete DB drin
Hi, hab oben noch mal Editiert, also ein fhem.db File ist da!?
Ja, aber schau mal auf die Größe. Es ist ganz klein und wurde automatisch durch den DB-Treiber beim Start angelegt. Da sind keine Tabellen drin, deswegen auch die Fehlermeldung.
Vergleiche mal mit dem fhem.db File des (hoffentlich) vorhandenen Filebackup.
Zitat von: DS_Starter am 10 Januar 2018, 20:13:19
Ja, aber schau mal auf die Größe. Es ist ganz klein und wurde automatisch durch den DB-Treiber beim Start angelegt. Da sind keine Tabellen drin, deswegen auch die Fehlermeldung.
Vergleiche mal mit dem fhem.db File des (hoffentlich) vorhandenen Filebackup.
Ok hast recht, da liegt das Problem die Original Datei ist rund 10GB groß....... Da ist beim übertragen etwas Fehlgelaufen. Spricht etwas dagegen die original Datei z.b. DB Browser für SQL zu bearbeiten/verkleinern und dann wieder aufs System zu schieben?
Das kannst du machen, sollte kein Problem sein.
Aber es gibt doch in DbLog bzw. DbRep integrierte Tools zur Verkleinerung (z.B. reduceLogNbl) die deine Datenbank ausdünnen.
Wenn du die DB im asynchronen Modus betreibst gibt es bei der wahrscheinlich sehr langen Laufzeit auch keine Blockierungen. Während der Laufzeit solcher Operationen die Attr syncInterval, cacheLimit auf relativ hohe Werte setzen damit nicht ständig versucht wird Daten in die DB zu schreiben.
Grüße
Heiko
Hi,
ich hab jetzt mal die DB aus dem Backup zurückgeschrieben, ist jetzt auch ca. 10 GB groß (hab sie doch nicht bearbeitet), liegt jetzt hier
/media/Platte/home > ls -l
total 10423704
drwxrwxr-x 6 fhem root 4096 Jan 8 19:41 Downloads
drwxr-xr-x 3 root root 4096 Dec 28 20:17 fhem
-rw-r--r-- 1 fhem dialout 10673849344 Jan 10 21:27 fhem.db
hab auch die d.conf entsprechend abgeändert:
%dbconfig= (
connection => "SQLite:dbname=/media/Platte/home/fhem.db",
user => "",
password => ""
);
allerdings bekomme ich die db in Fhem trotzdem nicht ans laufen, bzw. bereinigt
Internals:
COLUMNS field length used for Device: 64, Type: 64, Event: 512, Reading: 64, Value: 128, Unit: 32
CONFIGURATION /opt/fhem/db.conf
DEF /opt/fhem/db.conf .*:.*
MODE synchronous
MODEL SQLITE
NAME myDbLog
NR 251
NTFY_ORDER 50-myDbLog
PID 24745
REGEXP .*:.*
STATE DBD::SQLite::db prepare failed: unable to open database file at ./FHEM/93_DbLog.pm line 1437.
TYPE DbLog
VERSION 3.6.0
dbconn SQLite:dbname=/media/Platte/home/fhem.db
dbuser
HELPER:
COLSET 1
DEVICECOL 64
EVENTCOL 512
OLDSTATE DBD::SQLite::db prepare failed: unable to open database file at ./FHEM/93_DbLog.pm line 1437.
READINGCOL 64
TYPECOL 64
UNITCOL 32
VALUECOL 128
Helper:
DBLOG:
lastRowsDeleted:
myDbLog:
TIME 1515616560.02425
VALUE 0
state:
myDbLog:
TIME 1515617103.75121
VALUE DBD::SQLite::db prepare failed
READINGS:
2017-01-14 20:59:42 countCurrent 547
2017-01-14 20:59:42 countHistory 638989
2016-03-02 18:45:47 lastReduceLogResult Rows processed: 1028663, deleted: 978048, time: 528.78sec
2018-01-10 21:36:00 lastRowsDeleted 0
2018-01-10 21:50:24 state DBD::SQLite::db prepare failed: unable to open database file at ./FHEM/93_DbLog.pm line 1437.
cache:
index 457882
Attributes:
DbLogType Current/History
asyncMode 0
group Info
room Zentral
Im fhem log gibts jede Menge dieser Meldungen
2018.01.10 21:43:09.349 2: DbLog myDbLog - Error: DBD::SQLite::db prepare failed: unable to open database file at ./FHEM/93_DbLog.pm line 1842.
Hab jetzt mal einen integritäts check laufen lassen
sudo sqlite3 fhem.db
SQLite version 3.16.2 2017-01-06 16:32:41
Enter ".help" for usage hints.
sqlite> pragma integrity_check;
*** in database main ***
Main freelist: freelist leaf count too big on page 9569943
Main freelist: invalid page number 218103808
Page 8174552: btreeInitPage() returns error code 11
On tree page 10423681 cell 12: 2nd reference to page 9569943
Page 404179: btreeInitPage() returns error code 11
Page 7 is never used
Page 10 is never used
Page 11 is never used
Page 12 is never used
Page 13 is never used
Page 14 is never used
Page 15 is never used
Page 16 is never used
Page 17 is never used
Page 18 is never used
Page 19 is never used
Page 20 is never used
Page 21 is never used
Page 22 is never used
Page 23 is never used
Page 24 is never used
Page 25 is never used
Page 26 is never used
Page 27 is never used
Page 28 is never used
Page 29 is never used
Page 30 is never used
Page 31 is never used
Page 32 is never used
Page 33 is never used
Page 34 is never used
Page 35 is never used
Page 36 is never used
Page 37 is never used
Page 38 is never used
Page 39 is never used
Page 40 is never used
Page 41 is never used
Page 42 is never used
Page 43 is never used
Page 44 is never used
Page 45 is never used
Page 46 is never used
Page 47 is never used
Page 48 is never used
Page 49 is never used
Page 52 is never used
Page 53 is never used
Page 54 is never used
Page 55 is never used
Page 56 is never used
Page 59 is never used
Page 60 is never used
Page 61 is never used
Page 62 is never used
Page 63 is never used
Page 64 is never used
Page 66 is never used
Page 67 is never used
Page 68 is never used
Page 70 is never used
Page 71 is never used
Page 72 is never used
Page 73 is never used
Page 74 is never used
Page 75 is never used
Page 76 is never used
Page 77 is never used
Page 78 is never used
Page 79 is never used
Page 80 is never used
Page 81 is never used
Page 82 is never used
Page 83 is never used
Page 84 is never used
Page 85 is never used
Page 86 is never used
Page 87 is never used
Page 88 is never used
Page 89 is never used
Page 90 is never used
Page 91 is never used
Page 92 is never used
Page 93 is never used
Page 94 is never used
Page 95 is never used
Page 96 is never used
Page 97 is never used
Page 98 is never used
Page 99 is never used
Page 100 is never used
Page 101 is never used
Page 102 is never used
Page 103 is never used
Page 104 is never used
Page 105 is never used
Page 106 is never used
Page 107 is never used
Page 108 is never used
Page 109 is never used
Hab dann die DB wie hier beschreiben https://wiki.fhem.de/wiki/DbLog#Datenbank_reparieren die Datenbank repariert, allerdings gibt es immer noch Fehler:
rnals:
COLUMNS field length used for Device: 64, Type: 64, Event: 512, Reading: 64, Value: 128, Unit: 32
CONFIGURATION /opt/fhem/db.conf
DEF /opt/fhem/db.conf .*:.*
MODE synchronous
MODEL SQLITE
NAME myDbLog
NR 251
NTFY_ORDER 50-myDbLog
PID 12219
REGEXP .*:.*
STATE DBD::SQLite::st execute_array failed: unable to open database file [err was 14 now 2000000000]
executing 2 generated 2 errors at ./FHEM/93_DbLog.pm line 1520.
TYPE DbLog
VERSION 3.6.0
dbconn SQLite:dbname=/media/Platte/home/fhem.db
dbuser
HELPER:
COLSET 1
DEVICECOL 64
EVENTCOL 512
OLDSTATE DBD::SQLite::st execute_array failed: unable to open database file [err was 14 now 2000000000]
executing 2 generated 2 errors at ./FHEM/93_DbLog.pm line 1520.
READINGCOL 64
TYPECOL 64
UNITCOL 32
VALUECOL 128
REDUCELOG:
myDbLog
reduceLogNbl
2
REDUCELOG_PID:
abortArg
abortFn
arg myDbLog
bc_pid 15
finishFn DbLog_reduceLogNbl_finished
fn DbLog_reduceLogNbl
pid 15690
timeout
Helper:
DBLOG:
countCurrent:
myDbLog:
TIME 1515619004.56605
VALUE 1674
countHistory:
myDbLog:
TIME 1515619004.52745
VALUE 412327
lastRowsDeleted:
myDbLog:
TIME 1515619055.55178
VALUE 0
reduceLogState:
myDbLog:
TIME 1515619171.5935
VALUE reduceLogNbl 2 started
state:
myDbLog:
TIME 1515618943.34791
VALUE connected
READINGS:
2018-01-10 22:12:29 CacheUsage 33
2018-01-10 22:12:29 NextSync 2018-01-10 22:12:59 or if CacheUsage 500 reached
2018-01-10 22:16:44 countCurrent 1674
2018-01-10 22:16:44 countHistory 412327
2016-03-02 18:45:47 lastReduceLogResult Rows processed: 1028663, deleted: 978048, time: 528.78sec
2018-01-10 22:17:35 lastRowsDeleted 0
2018-01-10 22:19:31 reduceLogState reduceLogNbl 2 started
2018-01-10 22:20:04 state DBD::SQLite::st execute_array failed: unable to open database file [err was 14 now 2000000000]
executing 2 generated 2 errors at ./FHEM/93_DbLog.pm line 1520.
cache:
index 0
Attributes:
DbLogType Current/History
asyncMode 0
group Info
room Zentral
Result of connection check
Connection to database /media/Platte/home/fhem.db successfully done.
Recommendation: settings o.k.
Result of encoding check
Encoding used by DB /media/Platte/home/fhem.db: UTF-8
Recommendation: This is only an information about text encoding used by the main database.
Result of logmode check
Logmode of DbLog-device myDbLog is: synchronous
Recommendation: Switch myDbLog to the asynchronous logmode by setting the 'asyncMode' attribute. The advantage of this mode is to log events non-blocking.
There are attributes 'syncInterval' and 'cacheLimit' relevant for this working mode.
Please refer to commandref for further informations about these attributes.
Result of table 'history' check
Column width set in DB /media/Platte/home/fhem.db.history: 'DEVICE' = 32, 'TYPE' = 32, 'EVENT' = 512, 'READING' = 32, 'VALUE' = 32, 'UNIT' = 32
Column width used by myDbLog: 'DEVICE' = 64, 'TYPE' = 64, 'EVENT' = 512, 'READING' = 64, 'VALUE' = 128, 'UNIT' = 32
Recommendation: WARNING - The relation between column width in table history and the field width used by device myDbLog should be equal but it differs. The field width used by the module can be adjusted by attributes 'colEvent', 'colReading', 'colValue'. Because you use SQLite this is only a warning. Normally the database can handle these differences.
Result of table 'current' check
Column width set in DB /media/Platte/home/fhem.db.current: 'DEVICE' = 32, 'TYPE' = 32, 'EVENT' = 512, 'READING' = 32, 'VALUE' = 32, 'UNIT' = 32
Column width used by myDbLog: 'DEVICE' = 64, 'TYPE' = 64, 'EVENT' = 512, 'READING' = 64, 'VALUE' = 128, 'UNIT' = 32
Recommendation: WARNING - The relation between column width in table current and the field width used by device myDbLog should be equal but it differs. The field width used by the module can be adjusted by attributes 'colEvent', 'colReading', 'colValue'. Because you use SQLite this is only a warning. Normally the database can handle these differences.
Result of check 'Search_Idx' availability
Index 'Search_Idx' exists and contains the recommended fields 'DEVICE', 'READING', 'TIMESTAMP'.
Recommendation: settings o.k.
Result of check 'Report_Idx' availability for DbRep-devices
You don't use any DbRep-device assigned to myDbLog. Hence an index for DbRep isn't needed.
Recommendation: settings o.k.
Kann denn dein FHEM-User auch auf das File /media/Platte/home/fhem.db zugeifen ?
Sieht nicht so aus.
Gab es denn beim Start von fhem irgendwelche Fehler im Logfile das ein Databasehandle (dbh) nicht angelegt werden konnte ?
Kannst nochmal configCheck ausführen, aber da wird das gleiche rauskommen.
Ich würde erstmal den Zustand so herstellen wie es per default war , also nach /opt/fhem/fhem.db, schauen ob alles funktioniert und wenn ja kann man optimieren, verschieben , what else ...
EDIT: fhem läuft auch unter user fhem ?
Hi, hab oben mal ein update eingefügt,
Fhem läuft unter dem user fhem, und der darf auf die db zugreifen
Hast du denn mal ein "set...rereadcfg" + "set ... reopen" gemacht ?
richtig ...?
- user fhem - bestätigt
- ordner "fhem" liegt auf /media/Platte/home und ist dein Rootverzeichnis für FHEM?
Warum hat der Ordner als Eigentümer "root"
drwxr-xr-x 3 root root 4096 Dec 28 20:17 fhem
schau mal im Verzeichnis "fhem" ob die alle Dateien user fhem und nicht root gehören.
Zitat von: kadettilac89 am 10 Januar 2018, 22:28:36
richtig ...?
- user fhem - bestätigt
- ordner "fhem" liegt auf /media/Platte/home und ist dein Rootverzeichnis für FHEM?
Warum hat der Ordner als Eigentümer "root"
drwxr-xr-x 3 root root 4096 Dec 28 20:17 fhem
schau mal im Verzeichnis "fhem" ob die alle Dateien user fhem und nicht root gehören.
Hi, sieht falsch aus, ist es aber nicht, da der fhem ordner den du meinst ,nicht meine aktuelle fhem installation beinhaltet, sondern nur ein ordner mit alt Daten ist.
Die aktive Fhem installation ist diese
ls -l
total 12
drwxr-xr-x 13 fhem dialout 4096 Jan 10 22:12 fhem
ZitatHast du denn mal ein "set...rereadcfg" + "set ... reopen" gemacht ?
Ja habe ich, trotzdem gibt es die Fehler, allerdings hat reduceLogNblndie fhem.db verkleinert, also der Zugriff auf die DB an sich scheint wieder zu funktionieren
-rw-r--r-- 1 fhem dialout 193935321 Jan 10 22:07 dump_all_20180110_2206.sql
-rw-r--r-- 1 fhem dialout 215425024 Jan 11 05:59 fhem.db
-rwxrwxrwx 1 fhem dialout 10673849344 Jan 10 21:27 fhem.db.sv_20180110
Aber der state bleibt weiter
DBD::SQLite::st execute_array failed: unable to open database file [err was 14 now 2000000000] executing 1 generated 1 errors at ./FHEM/93_DbLog.pm line 1520
und im Fhem log gibt es jede Menge
2018.01.11 00:00:00.556 2: DbLog myDbLog -> Error table history - DBD::SQLite::st execute_array failed: unable to open database file [err was 14 now 2000000000]
executing 1 generated 1 errors at ./FHEM/93_DbLog.pm line 1520.
ZitatJa habe ich, trotzdem gibt es die Fehler, allerdings hat reduceLogNblndie fhem.db verkleinert, also der Zugriff auf die DB an sich scheint wieder zu funktionieren
Ja, gebe dir recht weil auch auch der configCheck weiter oben funktioniert hat.
Da fehlt mir momentan eine Idee was noch stören könnte.
Stelle mal bitte auf asynchronen Betrieb um.
Setzt mal bitte verbose 3 und führe ein FHEM-Restart durch.
Beim Start solltest du im Log diese Meldung, oder aber diesbezügliche Fehlermeldungen sehen:
2018.01.11 18:35:59.035 3: DbLog LogSQLITE: Creating Push-Handle to database SQLite:dbname=/opt/fhem/fhem.db with user
2018.01.11 18:35:59.044 3: DbLog LogSQLITE: Push-Handle to db SQLite:dbname=/opt/fhem/fhem.db created
VG
Guten Morgen,
ich hatte gestern keine Zeit mich um Fhem zu kümmern, aber es scheint auch so als ob sich sachen von alleine lösen, heute Morgen habe ich nicht einen Log eintrag, und die DBLOG scheint Problemlos zu laufen.
Internals:
COLUMNS field length used for Device: 64, Type: 64, Event: 512, Reading: 64, Value: 128, Unit: 32
CONFIGURATION /opt/fhem/db.conf
DEF /opt/fhem/db.conf .*:.*
MODE synchronous
MODEL SQLITE
NAME myDbLog
NR 251
NTFY_ORDER 50-myDbLog
PID 15496
REGEXP .*:.*
STATE connected
TYPE DbLog
VERSION 3.6.0
dbconn SQLite:dbname=/media/Platte/home/fhem.db
dbuser
HELPER:
COLSET 1
DEVICECOL 64
EVENTCOL 512
OLDSTATE connected
READINGCOL 64
TYPECOL 64
UNITCOL 32
VALUECOL 128
Helper:
DBLOG:
countCurrent:
myDbLog:
TIME 1515732605.50288
VALUE 1677
countHistory:
myDbLog:
TIME 1515732605.4518
VALUE 159724
lastRowsDeleted:
myDbLog:
TIME 1515718920.31242
VALUE 0
state:
myDbLog:
TIME 1515705070.97567
VALUE connected
READINGS:
2018-01-10 22:12:29 CacheUsage 33
2018-01-10 22:12:29 NextSync 2018-01-10 22:12:59 or if CacheUsage 500 reached
2018-01-12 05:50:05 countCurrent 1677
2018-01-12 05:50:05 countHistory 159724
2016-03-02 18:45:47 lastReduceLogResult Rows processed: 1028663, deleted: 978048, time: 528.78sec
2018-01-12 02:02:00 lastRowsDeleted 0
2018-01-11 06:07:47 reduceLogState Rows processed: 0, deleted: 0, time: 0.01sec
2018-01-12 05:50:34 state connected
cache:
index 0
Attributes:
DbLogType Current/History
asyncMode 0
group Info
room Zentral
Beim configCheck gibt es diese 2 Warnungen, sollte ich die Attribute entsprechend Setzen oder kann ich das ignorieren?
Result of logmode check
Logmode of DbLog-device myDbLog is: synchronous
Recommendation: Switch myDbLog to the asynchronous logmode by setting the 'asyncMode' attribute. The advantage of this mode is to log events non-blocking.
There are attributes 'syncInterval' and 'cacheLimit' relevant for this working mode.
Please refer to commandref for further informations about these attributes.
Result of table 'history' check
Column width set in DB /media/Platte/home/fhem.db.history: 'DEVICE' = 32, 'TYPE' = 32, 'EVENT' = 512, 'READING' = 32, 'VALUE' = 32, 'UNIT' = 32
Column width used by myDbLog: 'DEVICE' = 64, 'TYPE' = 64, 'EVENT' = 512, 'READING' = 64, 'VALUE' = 128, 'UNIT' = 32
Recommendation: WARNING - The relation between column width in table history and the field width used by device myDbLog should be equal but it differs. The field width used by the module can be adjusted by attributes 'colEvent', 'colReading', 'colValue'. Because you use SQLite this is only a warning. Normally the database can handle these differences.
Was mich im nachhinein noch wundert ist wieso die fhem.db so groß geworden ist, ich lasse jede nacht ein at laufen, welches die DB bereinigen sollte
Internals:
COMMAND set myDbLog deleteOldDays 2
DEF *02:02:00 set myDbLog deleteOldDays 2
NAME DbLog_aufrauumen
NR 325
PERIODIC yes
RELATIVE no
REP -1
STATE Next: 02:02:00
TIMESPEC 02:02:00
TRIGGERTIME 1515805320
TRIGGERTIME_FMT 2018-01-13 02:02:00
TYPE at
READINGS:
2018-01-12 02:02:00 state Next: 02:02:00
Attributes:
group Info
room Zentral
Danke für eure Hilfe
Guten Morgen,
na das sieht doch gut aus. Hatte mich auch stark gewundert nachdem die Checks und Aktionen erfolgreich waren.
Die Warnungen sind nur als Info gedacht, dass der Nutzer aufmerksam wird. Wenn es keine Probleme mit der Speicherung längerer Daten als der Spaltenbreite gibt (gibt es bei dir nicht) musst du auch nichts tun.
Wegen der Grösse....auch wenn du Daten aus der DB löscht bleibt die einmal erreichte Grösse solange erhalten bis ein VACUUM Lauf erfolgte. Es gibt auch eine Einstellung autovacuum, aber die ist meines Wissens nicht per default aktiv.
Schau dir doch dazu mal die Funktionen von DbRep an. Ganz aktuell habe ich eine Online-Backup/Restore Funktion implementiert, vielleicht magst du das mal testen. (Forum Sonstiges).
schönen Tag,
Heiko
Zitat von: Tommy82 am 12 Januar 2018, 05:54:17
Was mich im nachhinein noch wundert ist wieso die fhem.db so groß geworden ist, ich lasse jede nacht ein at laufen, welches die DB bereinigen sollte
laut
2018-01-12 02:02:00 lastRowsDeleted 0
hat er nix gelöscht. :o
//edit:
überschnitten mit DS_Starter :)
Zitat von: nils_ am 12 Januar 2018, 08:38:47
laut
2018-01-12 02:02:00 lastRowsDeleted 0
hat er nix gelöscht. [emoji50]
//edit:
überschnitten mit DS_Starter [emoji4]
Hi, ja das ist richtig, liegt aber daran das ich gestern mal alles bis auf 1 Tag Manuel gelöscht habe, daher gab es heute nacht nichts zu löschen, sollte morgen wieder anders sein:-)
@DS_Starter, werde ich mir am WE mal ansehen, Danke für den tip
Gesendet von iPhone mit Tapatalk
Zitat von: DS_Starter am 12 Januar 2018, 08:38:22
Wegen der Grösse....auch wenn du Daten aus der DB löscht bleibt die einmal erreichte Grösse solange erhalten bis ein VACUUM Lauf erfolgte. Es gibt auch eine Einstellung autovacuum, aber die ist meines Wissens nicht per default aktiv.
Schau dir doch dazu mal die Funktionen von DbRep an. Ganz aktuell habe ich eine Online-Backup/Restore Funktion implementiert, vielleicht magst du das mal testen. (Forum Sonstiges).
schönen Tag,
Heiko
Hi, also in meinem dblog finde ich keine VACUUM welches ich aktivieren könnte, oder ich gucke falsch!?
Dein Modul guck ich mir die Tage an.
Danke
Zitat von: Tommy82 am 12 Januar 2018, 18:43:47
Hi, also in meinem dblog finde ich keine VACUUM welches ich aktivieren könnte, oder ich gucke falsch!?
Dein Modul guck ich mir die Tage an.
Danke
Vacuum ist im dbrep modul unter set zu finden.
Grüße
Schnitzelbrain
Ja ok, aber weil @DS_Startet schrieb
ZitatWegen der Grösse....auch wenn du Daten aus der DB löscht bleibt die einmal erreichte Grösse solange erhalten bis ein VACUUM Lauf erfolgte. Es gibt auch eine Einstellung autovacuum, aber die ist meines Wissens nicht per default aktiv.
hörte sich das für mich so an, das das in der DBLOG ginge, oder wie bekomme ich diese reduziert wenn nicht durch löschen der Daten?
Zitat von: Tommy82 am 12 Januar 2018, 20:58:40
Ja ok, aber weil @DS_Startet schrieb
hörte sich das für mich so an, das das in der DBLOG ginge, oder wie bekomme ich diese reduziert wenn nicht durch löschen der Daten?
Naja, mit dem löschen der Daten wird anscheinend nur die Tabellenfelder gelehrt (oder vielleicht auch nur der Inhalt markiert als nicht benutzbar).
Die Struktur (Speicherplatz) bleibt.
Beim vaccum wird die Größe tatsächlich reduziert.
Grüße
Schnitzelbrain
JA aber sowas muss es doch auch in DBLOG geben!?
Zitathörte sich das für mich so an, das das in der DBLOG ginge, oder wie bekomme ich diese reduziert wenn nicht durch löschen der Daten?
Sorry für die Verwirrung, die Pflegefunktion(en) sind im DbRep. Löschen der Daten ist natürlich richtig. Dafür gibt es im DbLog reduceLog(Nbl), deleteOldDays(Nbl) und im DbRep delEntries, delSeqDoublets. Diese Funktionen unterscheiden sich hinsichtlich ihrer Eigenschaften sowie Einstellbarkeit/Mächtigkeit -> Commandref.
Aber allen gemeinsam ist, dass sie Daten löschen, jedoch das File an sich nicht verkleinern. Dazu gibt es "set ... vacuum" im DbRep wie Schnitzelbrain schon schrieb.
ZitatJA aber sowas muss es doch auch in DBLOG geben!?
Nicht wirklich, DbLog ist ein Logging-Device. DbRep ist ein Device zum Management/Auswertung und zur Pflege. Das sich verschiedene Löschfunktionen in DBLog finden ist historisch bedingt.
EDIT: DbLog und DbRep sind zwar zwei getrennte Module, arbeiten jedoch SEHR eng zusammen, ohne DbLog-Device kann es auch kein DbRep-Device geben. Man könnte sie als Familie bezeichnen.