Autor Thema: 93_DbLog - Überlegungen zur Optimierung (RPI und andere Systeme)  (Gelesen 71635 mal)

Offline DS_Starter

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3972
Antw:93_DbLog - Überlegungen zur Optimierung (RPI und andere Systeme)
« Antwort #765 am: 08 Oktober 2018, 19:04:16 »
Hi Joe,

die Aufteilung in mehrere Tabellen hatte ich auch schon mal kurz auf dem Schirm.
Aber ich habe das ganz schnell wieder verworfen als ich an die Arbeit gedacht habe, die mir das im DbRep bescheren würde wenn ich sowohl die Tabellenstruktur des bisherigen DbLog UND die Struktur über mehrere Tabellen in einem neuen Modul unterstützen müsste, und das noch für verschiedene Datenbanksysteme.
Das wäre mir momentan echt zuviel  ;)

LG,
Heiko
ESXi 6.5 auf NUC6i5SYH mit FHEM auf Debian 9/64 Bit  (Stretch), DbLog/DbRep mit MariaDB auf Synology 415+
Maintainer: SSCam, DbLog/DbRep, Log2Syslog, SMAPortal, Watches
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

Offline Bond246

  • Jr. Member
  • **
  • Beiträge: 76
Antw:93_DbLog - Überlegungen zur Optimierung (RPI und andere Systeme)
« Antwort #766 am: 12 Oktober 2018, 00:14:40 »
Hallo zusammen,

ich würde in meiner bestehenden Datenbank (Synology mit mariadb10) gerne einen Primary Key hinzufügen.
Leider werden dabei die ein oder anderen doppelten Einträge gefunden, was das Vorhaben verhindert.

Im anderen Thread ist es schon kurz angesprochen. https://forum.fhem.de/index.php/topic,68646.30.html
Mit dem Hinweis von DS_Starter hab ichs auch probiert, ohne Erfolg:
ALTER IGNORE TABLE `history` ADD PRIMARY KEY(TIMESTAMP, DEVICE, READING);
delSeqDoublets hab ich in einem kurzen Zeitraum ausprobiert, mit dem Ergebnis das nahezu alle Daten aus dem Zeitraum gelöscht wurden, vermutlich weil delSeqDoublets nur auf Device,Reading and Value prüft, nicht aber auf den Timestamp. Und gerade bei Value-States eines Thermostats gibt es ja über längere Zeiträume auch gleiche Zustände. Solange pro Zeitstempler ein Wert ist, ist das ja auch OK.

Meine gelöschten Daten muss ich jetzt aus einem Backup wiederherstellen. Aber anderes Thema.

Wäre es ein Lösungsweg, die Datenbank zu sichern, dann komplett zu löschen, mit Primary Key neu anzulegen und dann die alten Daten wieder rückwärts zu importieren?

Wie könnte ich in der Zwischenzeit dafür sorgen, dass die anfallenden Daten irgendwo zwischengespeichert werden um währen des Prozederes keine Daten zu verlieren?

Besten Dank,
Bond

Offline DS_Starter

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3972
Antw:93_DbLog - Überlegungen zur Optimierung (RPI und andere Systeme)
« Antwort #767 am: 12 Oktober 2018, 10:50:49 »
Hallo Bond,

Zitat
delSeqDoublets hab ich in einem kurzen Zeitraum ausprobiert, mit dem Ergebnis das nahezu alle Daten aus dem Zeitraum gelöscht wurden, vermutlich weil delSeqDoublets nur auf Device,Reading and Value prüft, nicht aber auf den Timestamp. Und gerade bei Value-States eines Thermostats gibt es ja über längere Zeiträume auch gleiche Zustände. Solange pro Zeitstempler ein Wert ist, ist das ja auch OK.
Die Funktion delSeqDoublets macht etwas mehr als "nur" doppelte Datensätze löschen. Wie genau es wirkt, ist in der commandref detailliert beschrieben. Es gibt auch einen Testlauf vorher mit "delSeqDoublets adviceDelete".  Ich hätte dich vermutlich explizit nochmal darauf hinweisen sollen vorher die commandref zu lesen und das dort beschriebene Beipiel anzuschauen. Sorry ... mein Fehler.

Werde wohl noch eine Funktion ins DbRep einbauen, die ausschließlich doppelte (mehrfache) Datensätze bereinigt.

Zu deinem eigentlichen Thema.

Ich würde mit einer Standby-Datenbank arbeiten.

1. Neue DB (z.B. fhempk) anlegen und dort den PK wie beschrieben mit anlegen für die history.
2. ein DbLog-Device Log.fhempk für diese DB anlegen was einsatzbereit ist, aber so einstellen das nichts geloggt wird (Regex im DEF z.B. aaaaaa:bbbbbbb).
3. ein Dbrep-Device anlegen was mit produktiven Datenbank verbunden ist.
4. mit dem Befehl "syncStandby Log.fhempk" alle Datensätze in die Standby-DB übertragen. Doppelte Datensätze werden durch den PK
   automatisch ignoriert. Der produktive Betrieb wird nicht behindert und kann weiter laufen.
   Je nach Größe der DB kann das einige Zeit in Anspruch nehmen. Vorher Commandref lesen !
5. vermutlich wird es dann noch einen Datengap geben, der zwischen Start und Ende des syncStandby-Befehls liegt. Dann einfach diesen Zeitraum nochmal mit syncStandby und gesetzten Zeitattributen nachfahren
6. Sind alle Daten übertragen, das Device Log.fhempk disabled setzen und das bisherige produktive DbLog mit der neuen DB fhempk verbinden (db.cfg editieren).

Dann hättest du deine Daten relativ stressfrei umgezogen und fortan einen PK der doppelte Einträge in der DB verhindert.

Edit: Das Verfahren hat auch den Vorteil, dass man üben kann. Die Standby-DB aufbauen, schauen wie alles gelaufen ist, die Tabellen droppen und nochmal beginnen. Das kann man so oft wiederholen wie man es wünscht. Die produktive DB läuft in der Zeit munter weiter.

Grüße,
Heiko


« Letzte Änderung: 13 Oktober 2018, 19:54:58 von DS_Starter »
ESXi 6.5 auf NUC6i5SYH mit FHEM auf Debian 9/64 Bit  (Stretch), DbLog/DbRep mit MariaDB auf Synology 415+
Maintainer: SSCam, DbLog/DbRep, Log2Syslog, SMAPortal, Watches
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

Offline JoeALLb

  • Hero Member
  • *****
  • Beiträge: 1549
Antw:93_DbLog - Überlegungen zur Optimierung (RPI und andere Systeme)
« Antwort #768 am: 12 Oktober 2018, 11:36:10 »
So wie hier beschrieben würde es natürlich auch gehen, mit eventuell etwas weniger aufwand....

https://forum.fhem.de/index.php/topic,65860.msg571050/topicseen.html#msg571050

In Punkt 1 kannst Du dann die Tabelle vorab ja noch anpassen und den PK setzen.

sG Joe
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 Bond246

  • Jr. Member
  • **
  • Beiträge: 76
Antw:93_DbLog - Überlegungen zur Optimierung (RPI und andere Systeme)
« Antwort #769 am: 14 Oktober 2018, 15:35:09 »
So wie hier beschrieben würde es natürlich auch gehen, mit eventuell etwas weniger aufwand....

https://forum.fhem.de/index.php/topic,65860.msg571050/topicseen.html#msg571050

In Punkt 1 kannst Du dann die Tabelle vorab ja noch anpassen und den PK setzen.

sG Joe

Danke, so hab ich es jetzt gemacht.
Zuerst eine neue historyNEW angelegt, dann die aktuelle in historyOLD umgebannt und dann hab ich alle Daten von OLD zur neuen umgezogen mit dem aktiven privateKey.

Besten Dank.

Offline DS_Starter

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3972
Antw:93_DbLog - Überlegungen zur Optimierung (RPI und andere Systeme)
« Antwort #770 am: 09 November 2018, 21:32:24 »
Hallo zusammen,

zur Beseitigung von doppelten Datensätzen gibt es nun eine einfache Möglichkeit mit DbRep.

Im contrib Verzeichnis

https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

gibt es eine neue DbRep-Version die den Befehl

set <name> delDoublets [adviceDelete | delete]


enthält. Mit der "delete" Option werden die doppelt oder mehrfach vorhandenen Datensätze gelöscht.
Wenn man noch keinen PK gesetzt hat und sich doppelte Records in der DB befinden, kann man folgendermaßen vorgehen um einen PK setzen zu können.

Erstmal die DB für das Logging (genügend lange) schließen:

set <DbLog> reopen 86000

Wie bekannt, gehen die Daten während dieser Zeit nicht verloren und werden nachgebucht, wenn DbLog im asynchronen Modus betrieben wird.
Dann die doppelten Datensätze entfernen:

set <DbRep> delDoublets

Das dauert nun je nach Größe und Performance eine gewissse Zeit.
Dann den PK setzen, für MySQL/MariaDB:

set <DbRep> sqlCmd ALTER TABLE 'history' ADD PRIMARY KEY(TIMESTAMP, DEVICE, READING);

DbLog wieder zum Logging öffnen:

set <DbLog> reopen

Jetzt wird die DB von doppelten Datensätzen verschont.
Die delDoublets-Funktion kann man natürlich auch zum regelmäßigen Pflegen des Datenbestandes nutzen.
Wenn ich genügend getestet habe, checke ich die Version auch ein.
Siehe auch hier: https://forum.fhem.de/index.php/topic,53584.msg856008.html#msg856008

Grüße
Heiko
ESXi 6.5 auf NUC6i5SYH mit FHEM auf Debian 9/64 Bit  (Stretch), DbLog/DbRep mit MariaDB auf Synology 415+
Maintainer: SSCam, DbLog/DbRep, Log2Syslog, SMAPortal, Watches
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: 3972
Antw:93_DbLog - Überlegungen zur Optimierung (RPI und andere Systeme)
« Antwort #771 am: 10 November 2018, 07:57:51 »
Guten Morgen,

Im contrib-Verzeichnis:

https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

liegt eine DbLog-Version die DbLogInclude mit berücksichtigt. Die Anforderung geht zurück auf diesen Thread:
https://forum.fhem.de/index.php/topic,92854.msg854173.html#new

set <name> addLog <devspec>:<Reading> [Value] [CN=<caller name>] [!useExcludes]

 Fügt einen zusätzlichen Logeintrag einer Device/Reading-Kombination in die Datenbank ein. Die eventuell in den Attributen "DbLogExclude" spezifizierten Readings (im Quelldevice) werden nicht nicht geloggt, es sei denn sie sind im Attribut "DbLogInclude" enthalten bzw. der addLog-Aufruf erfolgte mit der Option "!useExcludes".
....

Bitte testet die Erweiterung auch mal bei euch.

Grüße
Heiko

ESXi 6.5 auf NUC6i5SYH mit FHEM auf Debian 9/64 Bit  (Stretch), DbLog/DbRep mit MariaDB auf Synology 415+
Maintainer: SSCam, DbLog/DbRep, Log2Syslog, SMAPortal, Watches
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: 3972
Antw:93_DbLog - Überlegungen zur Optimierung (RPI und andere Systeme)
« Antwort #772 am: 06 April 2019, 13:14:31 »
Hallo DbLog Team  :),

nach längerer Zeit beginne ich nun wieder DbLog auf aktuelle Entwicklungen in FHEM anzupassen und verschiedene Dinge einzupflegen. Auf meiner ToDo haben sich ein paar Sachen angesammelt.
In der Version 3.14.0 habe ich erst einmal folgendes umgesetzt:

* Support für Meta.pm und Installer ist eingebaut (Meta.pm muss aber nicht zwingend vorhanden sein -> Rücksicht auf
   nicht Top aktuelle Installationen)
* die neue DelayedShutdownFn-Funktion ist eingebaut. Dadurch ist ein besseres Shutdown-Management möglich geworden.
   Der configCheck ist entsprechend angepasst.
* das Attribut "shutdownWait" wurde durch den voherigen Punkt obsolet.
   Achtung:  ist das Attribut gesetzt, wird es beim nächsten Restart entfernt und im Log gibt eine entsprechende
   Meldung. Das ist gewollt und nach speichern der Konfig ok.
* die direkte Attribut-Hilfe innerhalb des FHEMWEB ist eingebaut

Zunächst bitte aus meinem contrib laden:

https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter  (Downloadbutton benutzen)

Danach ist ein Restart notwendig !

Ich hoffe es finden sich ein paar Tester  :D

viele Grüße,
Heiko
« Letzte Änderung: 06 April 2019, 14:19:58 von DS_Starter »
ESXi 6.5 auf NUC6i5SYH mit FHEM auf Debian 9/64 Bit  (Stretch), DbLog/DbRep mit MariaDB auf Synology 415+
Maintainer: SSCam, DbLog/DbRep, Log2Syslog, SMAPortal, Watches
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

Offline Pyromane

  • Full Member
  • ***
  • Beiträge: 225
Antw:93_DbLog - Überlegungen zur Optimierung (RPI und andere Systeme)
« Antwort #773 am: 06 April 2019, 13:58:21 »
Mahlzeit Heiko,

nachdem ich gerade ein wenig Zeit habe vermelde ich: Testsystem auf den aktuellen Stand gebracht und DbLog vom Contri Link eingespielt. Ich werde Mo/Di kurze Rückmeldung geben.

Grüße
Pyro
Gefällt mir Gefällt mir x 1 Liste anzeigen

Offline DS_Starter

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3972
Antw:93_DbLog - Überlegungen zur Optimierung (RPI und andere Systeme)
« Antwort #774 am: 06 April 2019, 14:19:26 »
Danke Pyro  :)
ESXi 6.5 auf NUC6i5SYH mit FHEM auf Debian 9/64 Bit  (Stretch), DbLog/DbRep mit MariaDB auf Synology 415+
Maintainer: SSCam, DbLog/DbRep, Log2Syslog, SMAPortal, Watches
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: 3972
Antw:93_DbLog - Überlegungen zur Optimierung (RPI und andere Systeme)
« Antwort #775 am: 11 April 2019, 13:25:52 »
Gibt es evtl. schon erste Testergebnisse ?
Keine Fehlermitteilungen sind ja auch ein gutes Zeichen  ;)

VG
ESXi 6.5 auf NUC6i5SYH mit FHEM auf Debian 9/64 Bit  (Stretch), DbLog/DbRep mit MariaDB auf Synology 415+
Maintainer: SSCam, DbLog/DbRep, Log2Syslog, SMAPortal, Watches
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

Offline Pyromane

  • Full Member
  • ***
  • Beiträge: 225
Antw:93_DbLog - Überlegungen zur Optimierung (RPI und andere Systeme)
« Antwort #776 am: 12 April 2019, 13:01:36 »
Mahlzeit Heiko,

da war ja was... Schande über mein Haupt  :(
Aber wie du bereits richtig erkannt hast, gab es keine Auffälligkeiten.

Grüße
Pyro

Offline DS_Starter

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3972
Antw:93_DbLog - Überlegungen zur Optimierung (RPI und andere Systeme)
« Antwort #777 am: 12 April 2019, 13:24:36 »
Hi Pyro,

na schäm dich  :D

Dann sieht das doch gut aus. Werde diese Version dann einchecken.
Ich habe noch ein bisschen was auf meiner ToDo ...

LG,
Heiko
ESXi 6.5 auf NUC6i5SYH mit FHEM auf Debian 9/64 Bit  (Stretch), DbLog/DbRep mit MariaDB auf Synology 415+
Maintainer: SSCam, DbLog/DbRep, Log2Syslog, SMAPortal, Watches
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

Offline DS_Starter

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3972
Antw:93_DbLog - Überlegungen zur Optimierung (RPI und andere Systeme)
« Antwort #778 am: 12 April 2019, 22:49:53 »
Hallo Pyro, @all,

nachdem die aktuellste Version eingecheckt ist, habe ich mich dem gemeldeten Problem: https://forum.fhem.de/index.php/topic,99280.0.html mit MySQL und der SVG-Darstellung von Differenzwerten beschäftigt. Das Problem tritt nur in dem speziellen Fall auf, wenn VALUE kein Zahlenwert ist, sondern durch ein im SVG mitgegebenen Regex aus VALUE extrahiert wird. Und nur bei MySQL.
Ich konnte das Problem hoffentlich ohne Nebeneffekte lösen.
Kurioserweise existiert diese für MySQL spezielle Selektion bereits seit der ganz alten Version vom Juli 2016 (sicherlich noch früher) und erst jetzt wurde solch ein (mir bekannter) Fall geschildert.  :o

Also meine Bitte wieder diese Version zu testen. Diesmal sind vor allem MySQL User gefragt.

Bitte aus meinem contrib laden:

https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter  (Downloadbutton benutzen)

Reload danach wäre ausreichend.

Danke und Grüße,
Heiko

« Letzte Änderung: 13 April 2019, 00:05:46 von DS_Starter »
ESXi 6.5 auf NUC6i5SYH mit FHEM auf Debian 9/64 Bit  (Stretch), DbLog/DbRep mit MariaDB auf Synology 415+
Maintainer: SSCam, DbLog/DbRep, Log2Syslog, SMAPortal, Watches
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

Offline frober

  • Full Member
  • ***
  • Beiträge: 146
Antw:93_DbLog - Überlegungen zur Optimierung (RPI und andere Systeme)
« Antwort #779 am: 13 April 2019, 09:46:58 »
Ist das attr shutdownWait nicht mehr aktiv?
Fhem meldete dies beim Neustart.

Hatte ich vergessen zu erwähnen ;-)

Gruß Bernd
Raspi 3b mit Raspbian Jessie und Fhem,  einiges umgesetzt, vieles in Planung :-)

 

decade-submarginal