DBlog Error

[DS_Starter]

Guten Morgen,

Wette gewonnen 

commitMode  kannst du löschen um den Default wieder zu verwenden. cacheLimit  kannst du auch reduzieren. Du hast ja das Logging von cacheUsage. Da siehst du wie der Füllgrad im Durchschnitt aussieht.
Ein Ansatz wäre das Limit auf das vllt. 20-fache des Normalwertes zu setzen. User haben sich dann noch ein Notify auf den cacheUsage-Event gesetzt um bei Überschreitung eines Schwellenwertes, z.B. das 10-fache des Normalwertes, den cache mit "set ... exportCAche purge" zu exportieren und sich gleichzeitig eine Email, Telegram über den Sachverhalt zu senden. Dann kann man sich um die Sache kümmern und das File später wieder importieren um die Daten nicht zu verlieren.

Aber sonst würde ich es so lassen. Kannst vielleicht noch etwas experimientieren und schauen wie der Betrieb am Besten für dich funktioniert. Aber wirst sehen, am Ende merkst du nicht mal mehr dass du eine DB hast 
Das Schöne an dem Fall ist ja auch, dass du/wir ein Beispiel erarbeiten konnten, wie man solche Situationen strukturiert mit den vorhandenen Hilfsmitteln analysieren kann, um letztlich das Problem zu erkennen und zu lösen.
Das hilft hoffentlich auch anderen Usern für ähnliche Fälle.

schönen Start in die Woche ! und LG,
Heiko

[Kai-Alfonso]

Guten Morgen,

Wette gewonnen 

Ich hab nicht dagegen gewettet - dafür war die Einstellung in der DB und der Fehler dazu zu passend 

commitMode  kannst du löschen um den Default wieder zu verwenden. cacheLimit  kannst du auch reduzieren. Du hast ja das Logging von cacheUsage. Da siehst du wie der Füllgrad im Durchschnitt aussieht.

Somit getan...

Ein Ansatz wäre das Limit auf das vllt. 20-fache des Normalwertes zu setzen. User haben sich dann noch ein Notify auf den cacheUsage-Event gesetzt um bei Überschreitung eines Schwellenwertes, z.B. das 10-fache des Normalwertes, den cache mit "set ... exportCAche purge" zu exportieren und sich gleichzeitig eine Email, Telegram über den Sachverhalt zu senden. Dann kann man sich um die Sache kümmern und das File später wieder importieren um die Daten nicht zu verlieren.

Gute Idee - werde ich gleich mal umsetzen - hab auch die exportierenCaches wieder importiert - ist ja echt komfortabel mit dem Dropdown

Das Schöne an dem Fall ist ja auch, dass du/wir ein Beispiel erarbeiten konnten, wie man solche Situationen strukturiert mit den vorhandenen Hilfsmitteln analysieren kann, um letztlich das Problem zu erkennen und zu lösen.
Das hilft hoffentlich auch anderen Usern für ähnliche Fälle.

Das ist sowieso der beste Fall, wenn alle was dabei lernen und es noch einen Mehrwert hat.

Noch was anderes. Hab mal ein set DbRep delSeqDoubletes adviceDelete gemacht und er hat 125573(!) Doubletten gefunden? Kann das sein? Andererseits hab ich beobachtet, das die DB sich vom 11 auf den 13 verdoppelt hat (von 40 auf 80 MB)

[DS_Starter]

Ich hab nicht dagegen gewettet

Na, wir beide haben doch gewonnen 

Noch was anderes. Hab mal ein set DbRep delSeqDoubletes adviceDelete gemacht und er hat 125573(!) Doubletten gefunden? Kann das sein?

Ja, aber Achtung !  Commandref lesen. Hier geht es nicht um doppelte Datensätze, sondern Datensaätze die mit gleichen Werten aufeinanderfolgen. Also zum Beispiel Temperaturwerte die sich nicht ändern aber geloggt werden usw. Deswegen delSeq.. (sequentielle Dubletten)
Du kannst die zu betrachtenden Daten eingrenzen über Attribute device/reading, um nur Datensätze eines bestimmten devices/readings auszuwerten -> Commandref.
Musst du schauen, ob du dir jetzt nicht unbedacht Daten gelöscht hast, was du garnicht wolltest.

Vergiss es, adviceDelete löscht nichts !!!

Andererseits hab ich beobachtet, das die DB sich vom 11 auf den 13 verdoppelt hat

Auch möglich durch die Erstellung des Index. Das du später einen anderen Index sowie Daten gelöscht hast, führt nicht automatisch wieder zur Verkleinerung der DB. Dazu kannst du ein "set ... optimizeTables" im DbRep verwenden. Das lässt dann die DB wieder schrumpfen wenn Freiplatz ist.

[kumue]

Ja, da ist die Ursache für das Problem:

Result of table 'history' check

Column width set in DB fhem.history: 'DEVICE' = 32, 'TYPE' = 32, 'EVENT' = 512, 'READING' = 32, 'VALUE' = 32, 'UNIT' = 32
Column width used by logdb: 'DEVICE' = 64, 'TYPE' = 64, 'EVENT' = 512, 'READING' = 64, 'VALUE' = 128, 'UNIT' = 32
Recommendation: The relation between column width in table history and the field width used in device logdb don't meet the requirements. Please make sure that the width of database field definition is equal or larger than the field width used by the module. Compare the given results.
Currently the default values for field width are:

DEVICE: 64
TYPE: 64
EVENT: 512
READING: 64
VALUE: 128
UNIT: 32

You can change the column width in database by a statement like 'alter table history modify VALUE varchar(128);' (example for changing field 'VALUE'). You can do it for example by executing 'sqlCMD' in DbRep or in a SQL-Editor of your choice. (switch logdb to asynchron mode for non-blocking).
The field width used by the module can be adjusted by attributes 'colEvent', 'colReading', 'colValue',


Deine Datenbankfelder sind noch nach den alten Größen von vor 12 ? Monaten eingestellt. Das hat man irgendwann mal erweitert. Deswegen kam auch der Stringfehler weil DbLog davon ausgegangen ist: "Column width used by logdb" . Du musst also die Feldgrößen in der DB für history, current anpassen.
Alternativ kann eine Anpassung über die in der Auswertung angegebenen Attribute geschehen indem du darin deine tatsächlichen (kürzeren) Feldgrößen der DB angibst (schlechtere Lösung).

Dann fehlen noch die Standardindexe. Das hat Performanceauswirkungen.
Gehe alles Schritt für Schritt durch. Am Ende soll der Check überall o.k. zeigen.

Das ist des Rätsels Lösung !

Grüße
Heiko

Ich klink mich mal ein...
Habe gestern von sqlite auf MariaDB umgestellt, sowet OK
Wollte heute einen Dump (server side) machen und bekomme die gleiche Fehlermeldung wie wuast94 (siehe Seite2)

Code Auswählen Erweitern

2018.01.17 09:00:35 2: DbRep myDbRep - DBD::mysql::st execute failed: Access denied for user 'fhemuser'@'%' (using password: YES) at ./FHEM/93_DbRep.pm line 5960.
2018.01.17 09:00:35 3: DbRep myDbRep - Starting dump of database 'fhem', table 'history'
2018.01.17 09:00:35 3: DbRep myDbRep - Searching for tables inside database fhem....
2018.01.17 09:00:35 3: DbRep myDbRep - ################################################################
2018.01.17 09:00:35 3: DbRep myDbRep - ###             New database serverSide dump                 ###
2018.01.17 09:00:35 3: DbRep myDbRep - ################################################################
2018.01.17 09:00:07 2: DbLog myMariaDB: Connection closed until 09:30:07 (1800 seconds).

Die Feldlängen hatte ich vorher schon angepasst.
Hier der configcheck

Code Auswählen Erweitern

Result of connection check

Connection to database fhem successfully done.
Recommendation: settings o.k.

Result of encoding check

Encoding used by Client (connection): LATIN1
Encoding used by DB fhem: UTF8
Recommendation: Both encodings should be identical. You can adjust the usage of UTF8 connection by setting the UTF8 parameter in file './db_mysql.conf' to the right value.

Result of logmode check

Logmode of DbLog-device myMariaDB is: asynchronous
Recommendation: settings o.k.

Result of table 'history' check

Column width set in DB fhem.history: 'DEVICE' = 64, 'TYPE' = 64, 'EVENT' = 512, 'READING' = 64, 'VALUE' = 128, 'UNIT' = 32
Column width used by myMariaDB: 'DEVICE' = 64, 'TYPE' = 64, 'EVENT' = 512, 'READING' = 64, 'VALUE' = 128, 'UNIT' = 32
Recommendation: settings o.k.

Result of table 'current' check

Column width set in DB fhem.current: 'DEVICE' = 64, 'TYPE' = 64, 'EVENT' = 512, 'READING' = 64, 'VALUE' = 128, 'UNIT' = 32
Column width used by myMariaDB: 'DEVICE' = 64, 'TYPE' = 64, 'EVENT' = 512, 'READING' = 64, 'VALUE' = 128, 'UNIT' = 32
Recommendation: settings o.k.

Result of check 'Search_Idx' availability

Index 'Search_Idx' exists and contains recommended fields 'DEVICE', 'READING', 'TIMESTAMP'.
Recommendation: settings o.k.

Result of check 'Report_Idx' availability for DbRep-devices

You use at least one DbRep-device assigned to myMariaDB, but the recommended index 'Report_Idx' is missing.
Recommendation: You can create the index by executing statement 'CREATE INDEX Report_Idx ON `history` (TIMESTAMP, READING) USING BTREE;'
Depending on your database size this command may running a long time.
Please make sure the device 'myMariaDB' is operating in asynchronous mode to avoid FHEM from blocking when creating the index.
Note: If you have just created another index which covers the same fields and order as suggested (e.g. a primary key) you don't need to create the 'Report_Idx' as well !

utf-8 hatte ich in die db_mysql.conf eingetragen, wir aber anscheinend nicht angezogen... auch nicht nach System-Neustart

Code Auswählen Erweitern

################################################################
%dbconfig= (
        connection => "mysql:database=fhem;host=localhost;port=3306",
        user => "fhemuser",
        password => "fhempassword",
        utf8 => 1
);
################################################################


Woran könnte es noch liegen, daß der Dump nicht will ?

[DS_Starter]

Hi kumue,
hier werden zwei Dinge vermischt, DbLog und DbRep Problematiken.

Erstmal utf8 ... wie ist denn das Internal UTF8 im DbLog gesetzt ?

Die andere Sache ist DbRep. Hier stört mich zunächst der Logeintrag "access denied ....".  Schau mal ob du in der MySQL userverwaltung etwas auffälliges findest, wie Rechte gesetzt sind.

Dann hätte gerne mal gesehen wie das Log vom Dump weitergeht. Du hast ja nur den Anfang gepostet.

LG
Heiko

[kumue]

habe es eben laufen lassen... mehr steht nicht im log... geht gleich auf error

Code Auswählen Erweitern

2018.01.17 10:53:32 2: DbRep myDbRep - DBD::mysql::st execute failed: Access denied for user 'fhemuser'@'%' (using password: YES) at ./FHEM/93_DbRep.pm line 5961.
2018.01.17 10:53:32 3: DbRep myDbRep - Starting dump of database 'fhem', table 'history'
2018.01.17 10:53:32 3: DbRep myDbRep - Searching for tables inside database fhem....
2018.01.17 10:53:32 3: DbRep myDbRep - ################################################################
2018.01.17 10:53:32 3: DbRep myDbRep - ###             New database serverSide dump                 ###
2018.01.17 10:53:32 3: DbRep myDbRep - ################################################################

wegen dem rest schaue ich mal.
danke schonmal

[DS_Starter]

poste mal noch die versionsnummern (internal) von dblog / dbrep.

[kumue]

heute update gemacht

Code Auswählen Erweitern

fhem> version DbLog
File        Rev   Last Change

93_DbLog.pm 15893 2018-01-14 19:08:51Z DS_Starter
fhem> version DbRep
File        Rev   Last Change

93_DbRep.pm 15888 2018-01-14 17:18:34Z DS_Starter




Internat UTF bei DbLog

Code Auswählen Erweitern

UTF8 0

[DS_Starter]

Hast Recht, utf8 zieht nicht.
Das ist dann wahrscheinlich ein Proble! in der conf-Datei. wir hatten schon den Fall dass nicht sichtbare Steuerzeichen im File waren die die ordentliche verarbeitung des files verhinderten. Am besten das file nochmal mit zb. vi erstellen und neu einlesen.

Dein logfile ist von unten nach oben zu lesen .... ich war irritiert 

[DS_Starter]

Ich weiss nicht ob du den Hinweis aus der commandref für die serverside option gelesen hast:

.Der verwendete Datenbankuser benötigt das "FILE"-Privileg. 

Grüsse,
Heiko

[kumue]

utf8 keine chance

die datei nochmals aus contrib kopiert, mit vi und auch mit nano bearbeitet.
verschiedene variationen durchgespielt.... DB connected sicher immer, aber das Internal UTF8 blieb auf 0

Code Auswählen Erweitern


utf8 => 1
utf8 => "1"
utf8 => 1,


[kumue]

Ich weiss nicht ob du den Hinweis aus der commandref für die serverside option gelesen hast:

Grüsse,
Heiko

show grants liefert

Code Auswählen Erweitern

GRANT SELECT, INSERT, UPDATE, DELETE ON `fhem`.* TO 'fhemuser'@'%'

dann google ich mal, wie ich FILE noch hinzubekomme...

danke

[kumue]

wegen FILE Priv.
bin wiefolgt vorgegangen...

Code Auswählen Erweitern


phpmyadmin
anmeldung mit root
DB mysql ausgewählt => users => fhemuser
File_priv => Y
gespeichert


Dump angeschuppst...

Code Auswählen Erweitern

DBD::mysql::st execute failed: Access denied for user 'fhemuser'@'%' (using password: YES) at ./FHEM/93_DbRep.pm line 5961.

[DS_Starter]

das utf8 ist ja hartnäckig. Wenn du fhem neu startest achte mal auf diese Ausschriften im log

.
2018.01.17 12:39:34.179 3: DbLog LogDB: Creating Push-Handle to database mysql:database=fhemtest;host=192.168.2.10;port=3307 with user fhemtest
2018.01.17 12:39:34.198 3: DbLog LogDB: Push-Handle to db mysql:database=fhemtest;host=192.168.2.10;port=3307 created
2018.01.17 12:39:34.198 3: DbLog LogDB: UTF8 support enabled
2018.01.17 12:39:34.211 3: DbLog LogDB1: Creating Push-Handle to database mysql:database=fhemtest1;host=192.168.2.10;port=3307 with user fhemtest1
2018.01.17 12:39:34.212 3: DbLog LogDB1: Push-Handle to db mysql:database=fhemtest1;host=192.168.2.10;port=3307 created
2018.01.17 12:39:34.212 3: DbLog LogDB1: UTF8 support enabled 2018.01.17 12:39:34.234 3: DbLog LogSQLITE: Creating Push-Handle to database SQLite:dbname=/opt/fhem/fhem.db with user

oder gibt es Fehlermeldungen ?
Bei mir, wie siehst, wird der utf8 key in der conf erkannt. Also irgendwas ist da noch mit dem File nicht ok.
Der aufbau ist ok, ist bei mir genauso.

was sagt denn "show grants" jetzt ?

wenn du nicht weiter kommst können wir heute abend noch vergleichen, habe jetzt erstmal keine Zeit mehr ...

Lg,
Heiko

[kumue]

show grants ist unverändert, also bzgl. FILE wird da nichts angezeigt
aber im screenshot als globales recht


nach Neustart finde ich nur zwei Zeilen bzgl. DbLog

Code Auswählen Erweitern

2018.01.17 13:33:42 3: DbLog myMariaDB: Push-Handle to db mysql:database=fhem;host=localhost;port=3306 created
2018.01.17 13:33:42 3: DbLog myMariaDB: Creating Push-Handle to database mysql:database=fhem;host=localhost;port=3306 with user fhemuser

gruß und kein stress