Modul 93_DbRep - Reporting und Management von Datenbankinhalten (DbLog)

[tatu123]

Stimmt da war ja noch was. *verdammt* Danach hatte ich (natürlich) nicht geschaut.

Vielen Dank. Wie immer sitzt das Problem vor dem Monitor.

VG
Heiko

[300P]

PS:
Ahhhh....ich stoppe bei mir bei der Zeitumstellung im Herbst der Einfachheit halber immer automatisch "myDBLog" in der Umstellung von 2-3 Uhr Nachts um allen Übel aus dem Weg zu gehen......

....daher hab ich schon garnicht mehr daran gedacht das dort doppelte Datensätze mit vor- zurückspringen entstehen.....

Code Auswählen Erweitern

define di_ZeitumstellungStop at *01:55:00 { if ((localtime)[4] == 9 && (localtime)[3] >= 25 && (localtime)[6] == 0) { fhem("attr myDbLog disable 1");; Log 3, "DbLog: Wegen Zeitumstellung Logging deaktiviert.";; } }
attr di_ZeitumstellungStop room Dienste->Allgemein

define di_ZeitumstellungStart at *03:05:00 { if ((localtime)[4] == 9 && (localtime)[3] >= 25 && (localtime)[6] == 0) { fhem("attr myDbLog disable 0");; Log 3, "DbLog: Zeitumstellung vorbei, Logging aktiviert.";; } }
attr di_ZeitumstellungStart room Dienste->Allgemein



[DS_Starter]

Ahhhh....ich stoppe bei mir bei der Zeitumstellung im Herbst der Einfachheit halber immer automatisch "myDBLog" in der Umstellung von 2-3 Uhr Nachts um allen Übel aus dem Weg zu gehen......

Das ist natürlich auch eine Option. 

[DS_Starter]

@Parallix,

die Warnung kann nur bei einem "leeren" SQL-Statement auftreten.
Kannst du die Situation reproduizieren?

[Parallix]

Meine SQLite-Datenbank ist relativ groß (>10GB). Da einige Abfragen nicht so schnell laufen, wie ich mir dies wünsche, habe ich u.a. via DbLog einen configCheck gemacht. Das Ergebnis:

Code Auswählen Erweitern

Result of table 'history' check
...
Result of check 'Report_Idx' availability for DbRep-devices

Index 'Report_Idx' exists and contains recommended fields 'TIMESTAMP', 'READING'.
Rating:
Recommendation: settings o.k.Das Ergebnis für Report_Idx ist aber offensichtlich falsch, denn eine manuelle Abfrage via RepDb liefert mir mit READING, TIMESTAMP eine andere Reihenfolge der Felder.

Darüber hinaus sollte (TIMESTAMP, DEVICE, READING) insb. bei größeren Datenbanken die empfohlene Konfiguration sein, oder?

[DS_Starter]

Das Ergebnis für Report_Idx ist aber offensichtlich falsch, denn eine manuelle Abfrage via RepDb liefert mir mit READING, TIMESTAMP eine andere Reihenfolge der Felder.

DbLog sagt dir, dass es den Report Index mit den empfohlenen Feldern 'TIMESTAMP', 'READING' gibt, mehr nicht.
Die Reihenfolge der Felder im Index ist nicht zwingend gleich mit der Reihenfolge im Text.

Darüber hinaus sollte (TIMESTAMP, DEVICE, READING) insb. bei größeren Datenbanken die empfohlene Konfiguration sein, oder?

Das ist der 'Search_Idx', der Standardindex in DbLog. Der sollte auf jeden Fall sowieso vorhanden sein. Der 'Report_Idx' deckt einige spezifische SQL's in DbRep ab.

Ist 'Report_Idx' angelegt (ist ja optional), hat der DB Optimizer die Wahl 'Search_Idx' oder 'Report_Idx' zu nutzen je nach Kosten des SQL's.

Index brauchen viel Platz. Wenn deine DB so groß ist (meine ebenso), lösche den 'Report_Idx' und nutze nur
den 'Search_Idx' mit der Feldreihenfolge DEVICE, READING, TIMESTAMP. Bei meinen DB's ist noch ein Primary Key angelegt um doppelte Einträge in der DB zu verhindern. Er hat eine andere Reihenfolge, TIMESTAMP first.

[Parallix]

Das Ergebnis für Report_Idx ist aber offensichtlich falsch, denn eine manuelle Abfrage via RepDb liefert mir mit READING, TIMESTAMP eine andere Reihenfolge der Felder.

DbLog sagt dir, dass es den Report Index mit den empfohlenen Feldern 'TIMESTAMP', 'READING' gibt, mehr nicht.
Die Reihenfolge der Felder im Index ist nicht zwingend gleich mit der Reihenfolge im Text.

Das ist aber ungünstig, denn die Reihenfolge hat ja mitunter erhebliche Auswirkungen auf die Performance.

PS: Aktuell untersuche ich, wie der passive Balancer meiner Speicher arbeitet und insb. ob es Zellen gibt, bei denen im Vergleich zu den anderen über einen langen Zeitraum immer wieder balanciert wird. Auch interessiert mich, wie ich das Balancing-Verhalten durch meine Ladetechnik positiv beeinflussen kann. In diesem Kontext muss ich mir Zusammenhänge ansehen, was natürlichch bei einer hierfür optimal eingerichteten Datenbank schneller geht. Daher meine Fragen und die o.g. Anmerkung.

[DS_Starter]

Das ist aber ungünstig, denn die Reihenfolge hat ja mitunter erhebliche Auswirkungen auf die Performance.

Ja, in der Hilfe zu DbLog steht aber genau drin wie der Index angelegt werden muß bzw. wird automatisch mit den bereitgestellten Helperscripten gemacht.
Vllt. überarbeite ich den Check diesbezüglich nochmal ... wenn ich mal Zeit habe und DbLog wieder im Fokus steht.

[300P]

@Parallix:

Hier mal mein Check:

Code Auswählen Erweitern

Available Drivers in your system

DBD::DBM, DBD::ExampleP, DBD::File, DBD::Gofer, DBD::MariaDB, DBD::Mem, DBD::Proxy, DBD::SQLite, DBD::Sponge, DBD::mysql

Result of version check

Used Perl version: 5.36.0
Used DBI (Database independent interface) version: 1.643
Used DBD (Database driver) version mysql:
Used DbLog version: 5.12.0
Your local DbLog module is up to date.
Rating:
Recommendation: Update of DbLog is not needed.
Caution: Your DBD version doesn't support UTF8.

Result of configuration read check

Connection parameter store type: file
Connection parameter: Connection -> mysql:database=fhem;host=192.168.121.199;port=3306, User -> fhemuser, Password -> read o.k.
Rating:

Result of connection check

Connection to database fhem successfully done.
The time required to establish the connection was 0.0210 seconds.
Communication Compression between Client and Server: off
Rating:
Recommendation: settings o.k.

Result of Character Sets and Collation check

Character Set used by Client (connection): UTF8MB4
Collation used by Client (connection): UTF8MB4_BIN
Character Set used by DB fhem: UTF8MB4
Collation used by DB fhem: UTF8MB4_BIN
Rating:
Recommendation: settings o.k. Caution: Your DBD version doesn't support UTF8. If you want use UTF8 database option, you must update DBD (Database driver) to at least version 4.032.

Result of insert mode check

Insert mode of DbLog-device myDbLog is: Array
Rating:
Recommendation: settings o.k.

Result of plot generation method check

Attribute 'plotCacheLifetime' on myDbLog is not set (disabled).

WEB: plotfork=1 / plotEmbed=2 / longpollSVG=0

Rating:
Recommendation: settings o.k. - using classic 'plotfork = 1' for non-blocking plot generation.

Result of table 'history' check

Column width set in table history: 'DEVICE' = 64, 'TYPE' = 64, 'EVENT' = 512, 'READING' = 64, 'VALUE' = 128, 'UNIT' = 32
Column width used by device myDbLog: 'DEVICE' = 64, 'TYPE' = 64, 'EVENT' = 512, 'READING' = 64, 'VALUE' = 128, 'UNIT' = 32
Rating:
Recommendation: settings o.k.

Result of table 'current' check

Column width set in table current: 'DEVICE' = 64, 'TYPE' = 64, 'EVENT' = 512, 'READING' = 64, 'VALUE' = 128, 'UNIT' = 32
Column width used by device myDbLog: 'DEVICE' = 64, 'TYPE' = 64, 'EVENT' = 512, 'READING' = 64, 'VALUE' = 128, 'UNIT' = 32
Rating:
Recommendation: settings o.k.

Result of check 'Search_Idx' availability

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

Result of check 'Report_Idx' availability for DbRep-devices

At least one DbRep-device assigned to myDbLog is used. Index 'Report_Idx' exists and contains recommended fields 'TIMESTAMP', 'READING'.
Rating:
Recommendation: settings o.k.

Datensätze :
__COUNT_history__no_aggregation    46.690.741             2026-11-10 11:26:37

weitere Info - screenshot


Ich habe keinerlei Probleme.... bei ca 47 Millionen Datensätzen auf einer SSD

[Parallix]

@Parallix:

Hier mal mein Check:

Code Auswählen Erweitern

...
Result of check 'Search_Idx' availability

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

Result of check 'Report_Idx' availability for DbRep-devices

At least one DbRep-device assigned to myDbLog is used. Index 'Report_Idx' exists and contains recommended fields 'TIMESTAMP', 'READING'.
Rating:
Recommendation: settings o.k.


Also werden (vermutlich) auch bei Dir die Tabelleneinträge im Check nicht in der von der Datenbanksystem berücksichtigen Reihenfolge Form (von links nach rechts) angegeben. Oder aber die angezeigte Reihenfolge ('DEVICE', 'TIMESTAMP', 'READING') bei Search_Idx wurde bewusst höchst ungewöhnlich gewählt.

Ich habe keinerlei Probleme.... bei ca 47 Millionen Datensätzen auf einer SSD

Das zu hören ist gut. Vermutlich liegt's an recht performanten CPU Deines QNAP-NAS-Systems.  Fragst Du denn die Datensätze auch zu anderen Zwecken, als nur zur Konservierung und unmittelbaren Darstellung ab?