Autor Thema: Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)  (Gelesen 200489 mal)

Offline DS_Starter

  • Developer
  • Hero Member
  • ****
  • Beiträge: 7614
Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
« Antwort #285 am: 14 Dezember 2016, 18:00:11 »
Hallo zusammen,

ich muß mich auch mal präzisieren .... ich verwende  ebenfalls MariaDB in der Version 5.5.47. Dies ist das DB-System welches derzeit auf Synology DSM als Paket ausgeliefert wird.

@Joe:

Zitat
Ist das "lenth" hier eventuell ein Vertipper und sollte length heißen?

Richtig. Korrigiere ich.

Zitat
könnte man das (irgendwann mal) noch erweitern um Parameter wie "delete-readings, all " oder eben eine separierte Liste an Readings, die mich interessieren?

Das kannst du jetzt schon eingrenzen. Dafür gibt es je nach get-Befehl ein Attribut showStatus, showVariables, showSvrInfo, showTableInfo.
Wenn du also nach dem "get ... tableinfo" nur Informationen über history sehen möchtest, setzt du in dem DbRep-Device:

attr <DbRep-Dev> showTableInfo  %history%  (oder nur history)

Dann werden nur Infos zu dieser Tabelle generiert. Das ist dann schon sehr übersichtlich.

Und wenn du NUR die Info für "INFO_history.data_index_length_MB" sehen möchtest könntest du das Attribut suppressReading  verwenden:

attr <DbRep-Dev> suppressReading  ^(?!.*INFO_history.data_index_length_MB).*$

siehe auch: http://fhem.de/commandref_DE.html#DbRepattr

@Frickler

Zitat
Angenommen das Problem des "Konfigurationszerschiessen" beim FHEM Update lässt sich lösen.... was wäre performancetechnisch optimaler? 2 DBs mit jeweils einem deleteOldDays oder 1 DB mit 1 einem deleteOldDay und 15 delEntries?

Ergänzend zu Joes Ausführungen würde ich diese Frage konkret so beantworten, dass ich unter Performanceaspekten zu 1 DB und der enstprechenden Anzahl DbRep's mit delEntries raten würde.
Mein Hauptargument wäre, dass DbLog nach wie vor blockierend arbeitet, also bei allen Lese- oder auch Schreibaktivitäten dein FHEM enstprechend lange/kurz anhält bis die Aktion abgeschlossen ist.
Die Löschaktivitäten von den DbRep-Devices stören deine FHEM-Schleife nicht, brauchen natürlich auch CPU-Power, das ist klar. Aber die Löschläufe mußt du ja nicht alle zur gleichen Zeit einplanen. MySQL/MariaDB kann aber gut mit gleichzeitigen Lese- bzw. Löschzugriffen umgehen, kein Problem.

« Letzte Änderung: 14 Dezember 2016, 19:03:48 von DS_Starter »
ESXi 6.5 @NUC6i5SYH mit FHEM auf Debian 10, DbLog/DbRep mit MariaDB auf VM
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

Offline JoeALLb

  • Hero Member
  • *****
  • Beiträge: 1614
Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
« Antwort #286 am: 15 Dezember 2016, 11:47:46 »
Wollte noch einen Workaround kurz mit euch teilen:
Vor größeren Löschaktionen mache ich folgendes:

0. Erzeuge eine leere History-Tabelle
1. Ich benenne die aktuelle histopry-tabelle um und platziere eine neue, leere Tabelle dort. Dies funktioniert ohne Unterbrechung.
2. Ich lösche die Einträge in der Umbenannten Tabelle: FHEM kann somit völlig ungestört weiterarbeiten.
3. Ich benenne die Tabellen zurück um:
4. Ich kopiere die neuen Werte aus der "Temporären leeren History-Tabelle" wiede rzurück in die Haupttabelle
5. Ich lösche die Einträge de rtemporären History-Tabelle.

Die SQL Codes dazu lauten:
create table history3 like history;
rename table history to history2; rename history3 to history;
[...] Bereinige die history-tabelle, die nun history2 heißt. zB delete from history2 where reading="XY";
rename history to history3; rename history2 to history;
insert into history select * from history3;
drop table history;

FHEM-Server auf IntelAtom+Debian (8.1 Watt), KNX,
RasPi-2 Sonos-FHEM per FHEM2FHEM,RasPi-3 Versuchs-RasPi für WLAN-Tests
Gateways: DuoFern Stick, CUL866 PCA301, CUL HM, HMLan, JeeLink, LaCrosse,VCO2
Synology. Ardurino UNO für 1-Wire Tests, FB7270

Offline DerFrickler

  • Sr. Member
  • ****
  • Beiträge: 587
Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
« Antwort #287 am: 15 Dezember 2016, 23:37:38 »
Hallo zusammen,

die meisten der Anmerkungen von Euch (die ich verstanden habe) habe ich umgesetzt. Vielen Dank dafür! Mal sehen wie die DB in ein paar Tagen aussieht und was es noch so zu optimieren gibt.

die Version 4.8.4 sollte die Fehlermeldung

DBD::mysql::st execute failed: Expression #2 of SELECT list is not in GROUP BY clause and contains nonaggregated column 'information_schema.tables.TABLE_SCHEMA' which is not functionally dependent on columns in GROUP BY clause; this is incompatible with sql_mode=only_full_group_by at ./FHEM/93_DbRep.pm line 3161.
eliminieren.

leider immer noch
DBD::mysql::st execute failed: Expression #2 of SELECT list is not in GROUP BY clause and contains nonaggregated column 'information_schema.tables.TABLE_SCHEMA' which is not functionally dependent on columns in GROUP BY clause; this is incompatible with sql_mode=only_full_group_by at ./FHEM/93_DbRep.pm line 3190.

Jetzt halt in Zeile 3190

Gruß!

Offline DS_Starter

  • Developer
  • Hero Member
  • ****
  • Beiträge: 7614
Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
« Antwort #288 am: 16 Dezember 2016, 09:28:47 »
Zitat
leider immer noch

Neuer Versuch mit der Version 4.8.5.  Leider kann ich es bei mir nicht testen.
MariaDB bringt mit der bisherigen Abfrage keinen Fehler.
So wie ich im Netz gelesen habe, hat man mit MySQL 5.7 einen schon länger existierenden Industriestandard umgesetzt.

Man kann auch im Server Profil eine Anpassung vornehmen um diesen Fehler generell zu vermeiden. Hier ein Auszug aus https://blog.gabriela.io/2016/03/03/group-by-are-you-sure-you-know-it/

Zitat
Change permanently

If you want to disable it permanently, add/edit the following in your my.cnf file:

sql_mode = "STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION"

For this change a service restart is required:
 $ mysql service restart

Aber versuche es erst einmal mit der neuen Version.

Grüße
Heiko
ESXi 6.5 @NUC6i5SYH mit FHEM auf Debian 10, DbLog/DbRep mit MariaDB auf VM
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

Offline DerFrickler

  • Sr. Member
  • ****
  • Beiträge: 587
Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
« Antwort #289 am: 16 Dezember 2016, 22:34:51 »
Hallo,

auch mit der 4.8.5 tritt der Fehler auf:

DBD::mysql::st execute failed: Expression #2 of SELECT list is not in GROUP BY clause and contains nonaggregated column 'information_schema.tables.TABLE_SCHEMA' which is not functionally dependent on columns in GROUP BY clause; this is incompatible with sql_mode=only_full_group_by at ./FHEM/93_DbRep.pm line 3193.

Demnach gibt es halt die Optionen
1. Den SQL Mode umsetzen
sql_mode = "STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION"
2. Migration nach MariaDB... das sollte laut ubuntuusers.de wie folgt möglich sein:

MySQL Deinstallieren:
sudo apt-get purge mysql-server mysql-common mysql*
## Aufräumen:
sudo apt-get autoclean; sudo apt-get clean; sudo apt-get autoremove;
## Prüfen auf sql Reste:
dpkg -l | grep -i -e "sql\|maria"

MariaDB Installieren:
sudo apt-get install mariadb-server
Insbesondere bei der Migration auf MariaDB... gibt es da noch mehr zu beachten? Welche der 2 Varianten ist mit mehr Risiken behaftet?

Gruß!

Offline DS_Starter

  • Developer
  • Hero Member
  • ****
  • Beiträge: 7614
Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
« Antwort #290 am: 16 Dezember 2016, 22:44:43 »
Ich würde erstmal nur den SQL_Mode setzen in der my.cnf.
Das ist schnell gemacht.

Ich habe evtl. noch eine Idee den SQL-Mode in der Datenbanksession über das DBI-Interface im Modul zu setzen.
Das muß ich aber erst (morgen) im Modul einbauen. Dann testen wir erneut.

Versuche zunächst den Workaround über die my.cnf damit du vorankommst.

Grüße
Heiko
ESXi 6.5 @NUC6i5SYH mit FHEM auf Debian 10, DbLog/DbRep mit MariaDB auf VM
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

Offline DerFrickler

  • Sr. Member
  • ****
  • Beiträge: 587
Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
« Antwort #291 am: 16 Dezember 2016, 22:58:28 »
Ich würde erstmal nur den SQL_Mode setzen in der my.cnf.
Das ist schnell gemacht.

über ein set global oder direkt editieren?

Offline DS_Starter

  • Developer
  • Hero Member
  • ****
  • Beiträge: 7614
Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
« Antwort #292 am: 16 Dezember 2016, 23:03:05 »
my.cnf editieren und mysql restarten wie ich es in dem Ausschnitt weiter oben gefunden hatte.
Das halte ich für eine gute Methode die Änderung permanent zu machen.
Die ursprüngliche Zeile natürlich nur auskommentieren damit man sie wieder aktivieren kann bei Bedarf.
Kann man jederzeit wieder umeditieren wenn ich das Modul angepasst habe und es klappt.
ESXi 6.5 @NUC6i5SYH mit FHEM auf Debian 10, DbLog/DbRep mit MariaDB auf VM
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

Offline DS_Starter

  • Developer
  • Hero Member
  • ****
  • Beiträge: 7614
Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
« Antwort #293 am: 17 Dezember 2016, 08:54:47 »
Guten Morgen,

in der V 4.8.6 wird ONLY_FULL_GROUP_BY temporär für die Dauer der Session durch das Modul gehändelt.

@Frickler bitte testen ob das nun zieht. Falls du die my.cnf schon geändert hast bitte wieder in der ursprünglichen Zustand bringen, mysql restarten und dann testen.

Grüße
Heiko
ESXi 6.5 @NUC6i5SYH mit FHEM auf Debian 10, DbLog/DbRep mit MariaDB auf VM
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

Offline DerFrickler

  • Sr. Member
  • ****
  • Beiträge: 587
Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
« Antwort #294 am: 17 Dezember 2016, 11:42:18 »
Guten Morgen,

mit der 4.8.6 funktioniert es!

Gruß!
Karsten

Offline DS_Starter

  • Developer
  • Hero Member
  • ****
  • Beiträge: 7614
Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
« Antwort #295 am: 17 Dezember 2016, 11:46:21 »
Danke Karsten !

Dann checke ich es auch ein.

Grüße
Heiko
ESXi 6.5 @NUC6i5SYH mit FHEM auf Debian 10, DbLog/DbRep mit MariaDB auf VM
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

Offline DerFrickler

  • Sr. Member
  • ****
  • Beiträge: 587
Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
« Antwort #296 am: 17 Dezember 2016, 14:32:12 »
jetzt konnte ich aber folgendes beobachten....

das Reading INFO_history.data_index_length_MB schreibe ich auch in die DB. Kann es sein dass ein tableInfo die DB eine Zeit lang blockiert?

Im Logfile kann ich dann folgendes erkennen (unmittelbar nach dem get DbRep.Info tableinfo):

2016.12.17 14:30:24 2: DbLog: Failed to insert new readings into database: DBD::mysql::st execute failed: Data too long for column 'READING' at row 1 at ./FHEM/93_DbLog.pm line 613.

2016.12.17 14:30:24 3: Connecting to database mysql:database=fhem;host=127.0.0.1;port=3306 with user fhem
2016.12.17 14:30:24 3: Connection to db mysql:database=fhem;host=127.0.0.1;port=3306 established for pid 4279
2016.12.17 14:30:24 3: Connection to db mysql:database=fhem;host=127.0.0.1;port=3306 established

Offline DS_Starter

  • Developer
  • Hero Member
  • ****
  • Beiträge: 7614
Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
« Antwort #297 am: 17 Dezember 2016, 14:59:44 »
Zitat
Kann es sein dass ein tableInfo die DB eine Zeit lang blockiert?
Nein.

Zitat
DbLog: Failed to insert new readings into database: DBD::mysql::st execute failed: Data too long for column 'READING' at row 1 at ./FHEM/93_DbLog.pm line 613.

Das Reading "INFO_history.data_index_length_MB" ist 33 Zeichen lang.
Die ALTE Feldlänge von DbLOg war 32 ! Zeichen. Im neueren DbLog-Releases ist die Feldlänge auf 64 angepasst.

Hast du deine Tabellen history / current mit diesen Statements angelegt ? (aus ../contrib/dblog/db_create_mysql.sql):

CREATE DATABASE `fhem` DEFAULT CHARACTER SET utf8 COLLATE utf8_bin;
CREATE USER 'fhemuser'@'%' IDENTIFIED BY 'fhempassword';
CREATE TABLE `fhem`.`history` (TIMESTAMP TIMESTAMP, DEVICE varchar(64), TYPE varchar(64), EVENT varchar(512), READING varchar(64), VALUE varchar(128), UNIT varchar(32));
CREATE TABLE `fhem`.`current` (TIMESTAMP TIMESTAMP, DEVICE varchar(64), TYPE varchar(64), EVENT varchar(512), READING varchar(64), VALUE varchar(128), UNIT varchar(32));
GRANT SELECT, INSERT, DELETE, UPDATE ON `fhem`.* TO 'fhemuser'@'%';
CREATE INDEX Search_Idx ON `fhem`.`history` (DEVICE, READING, TIMESTAMP);

Wenn nicht kannst du die Feldlänge nachträglich z.B. ändern mit:

ALTER TABLE `history` CHANGE `READING` `READING` VARCHAR(64) CHARACTER SET utf8 COLLATE utf8_bin NULL DEFAULT NULL;

Für die anderen Felder DEVICE; TYPE usw. gilt ähnliches.

ESXi 6.5 @NUC6i5SYH mit FHEM auf Debian 10, DbLog/DbRep mit MariaDB auf VM
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

Offline DerFrickler

  • Sr. Member
  • ****
  • Beiträge: 587
Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
« Antwort #298 am: 17 Dezember 2016, 16:29:59 »
und da dachte ich doch dass die alle schon angepasst waren... wie man sich irren kann. Jetzt sollte aber alles soweit korrekt sein.

Danke!
Karsten

Offline DS_Starter

  • Developer
  • Hero Member
  • ****
  • Beiträge: 7614
Antw:Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)
« Antwort #299 am: 17 Dezember 2016, 16:35:08 »
Prima  :)

Andre Baustelle .. bin gerade dabei die Log-Funktion von DbLog  auf non-blocking umzustellen. Läuft schon richtig gut.
Zu gegebener Zeit mache ich eine Diskussionsthread auf um dort dem DbLog-Maintainer und interessierten Testern das geänderte Modul bereitzustellen.

Ich mache euch darauf aufmerksam wenn es soweit ist.

Grüße
Heiko

ESXi 6.5 @NUC6i5SYH mit FHEM auf Debian 10, DbLog/DbRep mit MariaDB auf VM
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter
Gefällt mir Gefällt mir x 1 Liste anzeigen

 

decade-submarginal