Hallo,
ich habe heute das 1. Mal einen "DBLog configcheck" gemacht und folgendes Ergebnis bei "Collation" bekommen:
Result of collation check
Collation used by Client (connection): LATIN1_SWEDISH_CI
Collation used by DB fhem: UTF8_GENERAL_CI
Rating:
Recommendation: Both encodings should be identical. You can adjust the usage of UTF8 connection by setting the UTF8 parameter in file '/opt/fhem/db.conf' to the right value.
Kann mir jemand erklären, welcher Client hier gemeint ist?
Blueberry63
ZitatKann mir jemand erklären, welcher Client hier gemeint ist?
Gemeint ist hier die Applikation, also FHEM bzw. das DbLog Device oder vllt. als die Perl-Applikation im Allgemeinen besser beschrieben.
Bei dieser Information geht es um die Collation der Verbindung die zwischen dem Client (der Perl-Applikation) und der Datenbank aufgebaut wurde.
Ok, ich gehe davon aus, dass UTF8 auf der DB nicht geändert werden sollte. Aber wie kann ich denn FHEM von LATIN1_SWEDISH_CI (was macht überhaupt SWEDISH hier?) auf UTF8 umstellen?
You can adjust the usage of UTF8 connection by setting the UTF8 parameter in file '/opt/fhem/db.conf'...
D.h. du setzt in deiner db.conf den Parameter
utf8 => 1
Der Parameter ist auch in der Hilfe zu DbLog beschrieben.
Wenn wir schon mal dabei sind empfehle ich dir deine Datenbank auf utf8mb4_bin umzustellen.
Damit werden auch Zeichen mit 4Byte Länge (Smileys etc.) gespeichert.
Das geht sehr einfach mit einem DbRep-Device mit set
migrateCollation <Collation>
Der Setter setzt dir alles auf der DB und den Tabellen entsprechend um.
Danke für die klaren Informationen, das hat mir sehr geholfen!!!
Gruß
Blueberry63
@DS_Starter: Nebenbei noch eine Frage zum Abschluss: kennst Du eine gute Anleitung zum "shrinken" der FHEM-DB (Maria-DB)?
Du meinst mit "shrinken" bestimmt die Verkleinerung der Datenbankfiles wenn Daten gelöscht wurden.
Auch das geht sehr einfach mit einem DbRep Device.
Für MariaDB gibt es den Setter "optimizeTables". Bei mir lasse ich optimizeTables einmal im Monat laufen.
Das reicht mir aus um freien Platz in der DB freizugeben.
Einfach per at-Device einplanen ein:
set <DbRep-Device> optimizeTables execute
Je nach DB Größe läuft das einige Zeit. Es stört aber nicht da die Funktion non-blocking im Hintergrund ausgeführt wird.
LG
Danke für den Tipp, aber "optimizeTable" hilft nur "ein bißchen". Meines Wissens wachsen die Dateien der (Inno-) DB viel zu stark im Verhältnis zur eigentlichen Datenmenge (bei mir 1.3 GB für die History-Table: obwohl ich regelmässig ältere Daten lösche, werden die DB-Dateien nicht kleiner.
Gruß
Blueberry63
Der Index ist auch nicht zu verachten und wächst mit der Datenmenge.
Du könntest versuchen den Index nach dem Datenlöschen ebenfalls zu löschen und neu aufzubauen.
Geht auch mit DbRep:
1. set ... optimizeTable
2. set ... recreate_Search_Idx
Damit erschöpfen sich m.M. nach die Möglichkeiten.
Um die DB noch effizienter zu machen müßte ein anderes Datenmodell eingeführt werden. Aber das wäre eine umfangreiche Entwicklungsaufgabe mit allen Facetten und auch nicht kompatibel zum Bestand.
Alles klar. Nochmal Danke für die Hilfe.
Gruß
Blueberry63