SQL.Adpter: Insert-Befehle innerhalb von 40ms
-
da stehen zwei mal die values angaben hintereinander.
INSERT INTO table_name (column1, column2, column3, ...) VALUES (value1, value2, value3, ...),(value1, value2, value3, ...);das geht so nicht. einen datensatz auf einmal nur. wenn man mehrere datensätze auf einmal schreiben möchte, dann muss man mehrere insert intos hintereinandergeschrieben mit ; getrennt senden.
die db optimiert das dann selbst.INSERT INTO table_name (column1, column2, column3, ...) VALUES (value1, value2, value3, ...); INSERT INTO table_name (column1, column2, column3, ...) VALUES (value1, value2, value3, ...);https://www.w3schools.com/sql/sql_insert.asp
hast du das sql selber geschrieben? oder kommt das vom adapter?
warum nutzt du nicht die historisierung des sql-adapters?
der macht genau das für dich vollautomatisch. -
@oliverio sagte in SQL.Adpter: Insert-Befehle innerhalb von 40ms:
das geht so nicht. einen datensatz auf einmal nur. wenn man mehrere datensätze auf einmal schreiben möchte, dann muss man mehrere insert intos hintereinandergeschrieben mit ; getrennt senden.
Das ist nicht richtig und das funktioniert so. Siehe z.B. https://mariadb.com/kb/en/insert/
Inserting more than 1 row at a time:
INSERT INTO tbl_name VALUES (1, "row 1"), (2, "row 2");Ich gehe eh davon aus, dass das Statements sind, welche der SQL-Adapter für das logging zusammenbaut. Der Fehler muss also wo anders liegen.
-
@nettekov sagte in SQL.Adpter: Insert-Befehle innerhalb von 40ms:
Den Iobroker, bzw. das Linux habe ich aktualisiert , was kein Erfolg brachte.
- Welche MariaDB version?
- Welche sql Adapter Version?
-
Oh danke, ist mir entgangen. Früher gabs das nicht.
-
@oliverio sagte in SQL.Adpter: Insert-Befehle innerhalb von 40ms:
Oh danke, ist mir entgangen. Früher gabs das nicht.
Seit wann genau weiß ich nicht. Aber mindestens seit mysql 5.7 (also ~2015). Ich meine aber, das geht sogar noch deutlich länger.
EDIT: mySQL 5.5 geht auch. Also eher so 13 Jahre
-
tja, wenn man das mal kann, liest man nicht regelmäßig die Referenz nach.
-
Sorry für der Verzug:
IOBroker läuft auf einer DS718+ in einem virtuellen Linux
MariaDB läuft ebenfalls auf der DS718+MariaDB : 10.3.29-0070
SQL-Adapter: v1.16.1Ich habe auch mal die Datapoint aufgeräumt, da durch die Umbenennung der Alias -ID jedes Mal eine neue angelegt.
a
Auffällig hier auch , da die meistens Fehlermeldung bei ID >32 entstehen
Tabelle datapoints
Zuerst alle Datenpunkten mit ID >32 deaktiviert
Dann in allen Tabellen (datapoints, TS_counter, ts_number) alle Datensätze mit ID >32 gelöscht.
Danach die Datenpunkte wieder Aktiviert
Nachher: Tabelle datapoints:
Aber es gab keine Verbesserung.
Ich verstehe die Fehlermeldung des Datenbank-Server nicht.
Er sagt, dass es ein Syntax-Fehler gibt.
Wenn ich aber den Insert-Befehl aus der Fehlermeldung im php-Admin ausführe, dann ist alles in Ordnung.
Gibt so erstmal keinen Sinn.
Zusätzlich zum eigentlichen Insert-Befehl muss was zum DB-Server geschickt werden, was ihn aus dem Tritt bringt.Gruss Nettekov
-
@nettekov sagte in SQL.Adpter: Insert-Befehle innerhalb von 40ms:
SQL-Adapter: v1.16.1
2.2.0 ist stable. Bitte aktualisieren. Deine Version ist ja uralt. Da steige ich gar nicht erst in die Fehlersuche ein
@nettekov sagte in SQL.Adpter: Insert-Befehle innerhalb von 40ms:
IOBroker läuft auf einer DS718+ in einem virtuellen Linux
Du meinst einen Docker Container? Und die MariaDB läuft auch in einem Container? 10.3 läuft jetzt bald aus dem Support. Eventuell auch da mal ein Update machen (wird aber nichts mit dem Fehler zu tun haben).
-
@haus-automatisierung
Ich bin noch nicht so affin im Iobroker.
Ich hatte in der Hitze des Gefechtes in den Instanzen nachgeschaut, dort stand v1.16.1 (Was das auch immer für eine Version das ist)
Bei den Adapter steht aber 2.2.0
Ich hatte auch, bevor ich dieses Thread erstellt habe, erstmal eine Rundrum Aktualiserung durchgeführt:
sudo apt update sudo apt full-upgrade iob repo unset beta iob update iob upgrade iob stop iob upgrade self iob startDa bin ich bei dir.
Bevor ich schreibt, sollte erstmal alles aktuell sein!@haus-automatisierung sagte:
- Du meinst einen Docker Container? Und die MariaDB läuft auch in einem Container? 10.3 läuft jetzt bald aus dem Support. Eventuell auch da mal ein Update machen (wird aber nichts mit dem Fehler zu tun haben).
Nee das virtuelle Linux läuft nicht im Docker Container, sondern Synology stellt auf der DS718+ zwei Virtuelle Maschinen zur Verfügung, wo Eine davon als virtuelles Linux mit ioBroker agiert.
Der Mariadb-Server läuft auch nicht im Container, sondern ist von Synology ein Paket, was von Synology selber Aktuell gehalten wird.
Bei Synology wird z.Z. als akuelle Version die 10.3.29-0070, ob wohl wir bei MariaDB schon bei 10.10.2; (17. November 2022)
sind.
Ich habe hier leider keine Einfluss, welche MariaDB-Version wird.Generell glaube ich mehr daran, das die Ursache am DB-Server liegt, weil Diese trotz korrekter Syntax , dem Insert-Befehl als fehlerhaft anzeigt.
Sollten sie kein anderen Idee haben, würde ich vorschlagen, das ich die IObroker -DB exportieren und bei mir auf eine lokalen MYSQL-Server(XAMPP) importiere und laufen lasse . Hier habe ich dann auch die Möglichkeit über Wireshark den Datenverkehr zu analysieren.
@haus-automatisierung : Wie ist deine Meinung?
Gruss Nettekov
-
@nettekov sagte in SQL.Adpter: Insert-Befehle innerhalb von 40ms:
Bei Synology wird z.Z. als akuelle Version die 10.3.29-0070, ob wohl wir bei MariaDB schon bei 10.10.2; (17. November 2022)
Stimmt, wird mir auch nur angeboten. Denke mal die werden das Paket dann vor EOL auch aktualisieren. Glaube aber wie gesagt nicht, dass das das Problem ist und würde erstmal dabei bleiben. Ist ja nun ein ganz einfacher INSERT, welcher seit 20+ Jahren so funktioniert
Hast Du den SQL-Adapter denn jetzt auf Version 2.2.0? Besteht damit nach wie vor das gleiche Problem?
-
@nettekov
Just for info:
Ich betreibe das Ganze mit so ziemlich dem gleichen Setup. ioBroker im Container und MariaDB 10.3.7-0051 als natives Synology-Paket.Diesen seltsamen Effekt konnte ich aber bislang noch nie beobachten.
-
Hallo zusammen,
Der SQL-Adapter ist laut der Versionsamgabe in Adapterbereich auf 2.2.0
Ein wichtiges Detail habe ich aber vergessen zu erwähnen, die Fehlermeldung fingen an, als ich die zwei neugekauufen Temperatur - Sensoren von Aquara ins Zigee-Netz einsetze und das Dazenloggon dort aktiviert habe.
- [Aqara Smart Luftdruck Temperatur Feuchtigkeit Umwelt Aqara Sensor] (https://a.aliexpress.com/_mLSqnrG)
Die Fehlermeldung bleiben aber weitgehenst bei den beiden Sensoren.
Vorher lief das Loggen monatelang ohne ProblemeGruß Nettekov
-
@nettekov sagte in SQL.Adpter: Insert-Befehle innerhalb von 40ms:
die Fehlermeldung fingen an, als ich die zwei neugekauufen Temperatur - Sensoren von Aquara ins Zigee-Netz einsetze und das Dazenloggon dort aktiviert habe
Das dürften die sein die ich auch einsetze.
Ich logge aber nicht direkt deren DP, sondern die Alias-DP die ich für alle meine Temperatur-/Feuchte-Sensoren angelegt habe. -
@codierknecht said in SQL.Adpter: Insert-Befehle innerhalb von 40ms:
Das dürften die sein die ich auch einsetze.
Jepp , ich habe die selben Sensoren. Ich verwenden auch Alias-ID
ich habe auch beim DP die Entprellzeit auf 5Sec und die Blockzeit auf 6sec, mit dem Gedank, das er zuviel Datensätze bekommen, was aber für ein DB-Server eigentlich kein Problem darstellt.
Die Frage ist, warum der DB-Server bei einem korrekten Insert -Befehl die Syntax als Fehler mukiert.
Wenn ich denn komplette Insert-Befehl aus der Fehlermeldung über PHP-ADMIN einspiele, ist alles OK.@haus-automatisierung Ich stimmt dir zu , das der DB-Server wahrscheinlich keine Fehler hat, aber entweder wir irgendwas mit gesendet, was die Fehlermeldung nicht anzeigt oder vielleicht es wir durch zu eine geringen Eingangsbuffer, was weggeschnitten, wenn zuviel Befehle in einer Transaktion gesendet werden.
Aber das ist alles nur eine Spekulation.
Gruss Nettekov
-
@nettekov Eventuell ist auch das
@im Alias ein Problem. Mit solchen Sonderzeichen bin ich bei Datenbanken immer vorsichtig
Wobei das ja eigentlich über Fremschlüssel gelöst wird und in dem Insert gar nicht enthalten ist. -
Hallo zusammen,
@haus-automatisierung Habe ich auch gedacht, aber 5 weitere Sensor verwenden auch in der Alias-ID den@und hier gib es bis jetzt die Probleme nicht.
Ich habe mir gestern mit Wireshark die Netzwerk-Protokolle angeschaut und habe einen kleinen Anhaltspunkt gefunden.
ich bin wie folgt vorgegangen:- Ich habe die IOBROKER-DB aus der Synology exportiert
- Auf meine lokalen MYSQL-Server(XAMPP) importiert und mit den SQL-Adapter verbunden.
- Gleichzeitig lasse ich Wireshark parallel laufen
- Die DP-ID 47,48,49 ist einer von den neue Aquara_Sensoren, der hauptsächlich die Probleme macht
Ergebnis:
Die selben Probleme treten auf mit dem MYSQL Server auf. Also kann es ein DB-Server spezifisches Problem nicht seinAuffällig hier, alle INSERT-Statements von den anderen DP (<>ID47-49) haben eine typische Protokolllänge ca.160Bytes
Wenn von den DP47-49 INSERT-Statements, dann haben Diese ein Länge von 250-400 Bytes, teils werden die SQL-Statement TRUNCATED
Witzigerweise, wenn ich diese INSERT-Sequenzen aus den Protokoll kopieren und lasse Diese mit PHP-Admin oder HeidiSQL ausführen, gehen sie alle als OK durch und werden gespeichert.
Ich packe mal ein paar Screenshots dazu, vielleicht habt ihr eine Idee, bzw wie ist eure Meinung dazu
Gruss Nettekov
1.Iobroker-Protokoll:
-
Normaler DP mit ID 9 , der keine Probleme machen und eine Länge von 160 Byte hat.
-
Fehler A: ID 48 mit Länge von 387 und ist truncated
-
Fehler B: ID 47 mit Länge von 340 und ist truncated
-
Hier ist die ID 49 mal ohne Fehler durchgegangen
-
Generell kann sagen, die meisten DP kommen mit eine Protokolllänge von unter 200Byte.
Nur die AQuara -Sensor fassen anscheinend mehrere Messwert zusammen, so das in den meinsten Fälle dann die Protokolllänge über 250Byte.
-
Kannst du bitte mal prüfen, ob bei diesen datenpunkten in den sql Einstellungen ein Kreuzchen bei Zähler gesetzt ist? Und bei den anderen nicht?
Mir ist aufgefallen, das manchmal noch ein weiteres insert für die Tabelle Counter mit drin steht. Das könnte die größere Länge erklären.
Allerdings nicht den Syntax Fehler.
Auch im Code des Adapters ist da nicht viel spannendes drin.https://github.com/ioBroker/ioBroker.sql/blob/64606a7c897adc741499572c7fbefb1af42f5063/main.js#L1524
In der Fehleranmeldung wird erst die query die versendet wird ausgegeben und dann die Fehlermeldung die von der dB zurückkommt.
Die ist allerdings nicht immer vollständig im log ausgegeben.Da bitte mal noch in die Iobroker log Datei auf der Festplatte nachschauen, nicht das die Iobroker Oberfläche hier was abschneidet was man dann nicht sieht.
Wenn das nichts ergibt, dann noch das logging auf db Seite erweitern um zu schauen was da tatsächlich ankommt.
-
@OliverIO Beiden DI-ID 47-49 (neuer Aquara-Sensor) ist der Haken Zähler gesetzt. Bei den anderen DP nicht durchgängig gesetzt , aber die Meisten.
Die Fehlermeldung wird vom SQL-Server abgeschnitten:
Gruss Nettekov
-
Hallo zusammen,
nach dem ich eine Nacht darüber geschlafen habe, haben sich die Dinge im Kopf mal zusammengefasst.
Das Auslösen des Problems sind zwar die neuen Aquara-Sensor, weil Diese anscheinend mehrere Werte gleichzeitig schicken und somit der SQL-Adapter in eine INSERT-Befehl mehrere (3-5) Datensätze zusammenfasst, was zu der Fehlermeldung führt.
Allerdings sollte das jeder SQL-Server Händeln können und zu keinem Fehler führen.Ich denke auch, das die Syntax-Fehlermeldung von beiden Server richtig sond, allerdings nicht ihm SQL-Statement , sondern in der Parametrierung der MySQL-Protokoll-Frames, das Diese z.B. auf eine kurzes SQL-Statement einstellen, was dann zu lange ist.
Ich werden heute oder morgen , den INSERT-Befehl aus einen fehlerhaften Protokoll kopieren und in HeidiSQL nochmal ausführen und dann beide MySql-Protokolle vergleichen
Da muss es ja einen Unterschied geben.Wie ist eure Meinung.
Gruss Nettekov
-
@nettekov sagte in SQL.Adpter: Insert-Befehle innerhalb von 40ms:
Ich werden heute oder morgen , den INSERT-Befehl aus einen fehlerhaften Protokoll kopieren und in HeidiSQL nochmal ausführen und dann beide MySql-Protokolle vergleichen
Da muss es ja einen Unterschied geben.Bevor Du das machst, würde ich an Deiner Stelle eher ein kurzes nodejs script schreiben, welches genau die gleiche Library verwendet wie der Adapter und einfach mal das Statement von dort senden. Tritt der Fehler dann auch auf, kann man das viel einfacher eingrenzen.
