Wie kann ich überprüfen, ob der “Recorder” auf die HA-interne DB SQLite noch arbeitet/läuft bzw. mit welchen Befehlen kann ich den recorder stoppen/starten?
Ich habe das Phänomen, das meine SQLiteDB seit dem 1 Woche keine Veränderung in der Dateigröße mehr zeigt:
Hilft das?
Aber ob der recorder arbeitet, siehst doch an den Verläufen, der einzelnen Entitäten, die Du per recorder erfassen tust.
Gruß
Osorkon
Aber sowas von (manchmal fallen einem die einfachsten Dinge nicht ein)!
Ich mache das Thema hier nochmals auf, denn die oben geposteten Werte meiner SQLiteDB bleiben seit dem 12.09. unverändert.
Ich habe zwischenzeitlich Geräte hinzugefügt, andere entfernt und auch einen kompletten Neustart der gesamten Hardware durchgeführt, aber der Wert ändert sich 0,0.
Die Werte der Vergangenheit sind bis zur Migration von MariaDB zur SQLite da:
Es kann doch eigentlich nicht sein, dass sich die DB überhaupt nicht ändert, oder?
Wie ermittelst Du die db Größe?
Über ein SQL Sensor?
Wennja, hast Du die SQL Abfrage auf die SQLite geändert?
Gruß
Osorkon
Hab ich oben im 1. Post geschrieben.
Klar, sonst hätte ich ja nach der Migration am 17.08.2024 gar keine Werte und auch keine Wertsteigerung gesehen!
Aber Du hast Verläufe von bestehenden Sensoren und auch neue Sensoren werden per Recorder aufgezeichnet, richtig?
Also funktioniert der Recorder korrekt nur der SQL Sensor scheint eigefrorren zu sein.
Schon mal einen neuen SQL Sensor angelegt, zeigt dieser den gleichen Wert an wie der alte und bewegt sich dieser auch nicht?
Gruß
Osorkon
Moin,
wir zwei hatten uns in anderen Beiträgen dazu ja schon mal kurz ausgetauscht 
und ich hatte leider bisher noch keine Zeit mich wieder um das Thema zu kümmern, aber ich kann Dir zumindest bestätigen das dieses Verhalten bei meiner HA DB auch noch so besteht. Warum auch immer. 
Seit 15.09. keinerlei Veränderung bei der DB-Größe.
VG Jim
Habe mir grad den Verlauf meinen DB (mariaDB) mal angeschaut.
Fällt auch auf, dass ab ca. den 15.9, die Größe sehr konstant bleibt und nicht mehr stetig ansteigt bis zum nächsten purge?! Wie es eigentlich sonst immer war.
Gruß
Osorkon
Nein, zumal der Wert im Filemaker-Explorer ungefähr den gleichen Wert zeigt.
Okay, dann warte ich noch mal ein paar Tage ab. Früher bei MariaDB gab es diesen Effekt m.M.n. nicht. 
Okay, dann ist es ja evtl. kein Bug sondern ein Feature!
Wie in den anderen Postings zu dem Thema ja schon mal von mir erwähnt war das früher (bei mir) bei HA auf jeden Fall anders und das hat sich erst irgendwann in diesem Jahr (oder vielleicht auch schon Ende letzten Jahres) durch die div. HA-Updates, die auch die DB betrafen, geändert.
Nachvollziehen kann ich dieses Verhalten (bisher) irgendwie immer noch nicht, 
denn ich sehe ja das z.B. bei Sensoren mit measurement, die per Long-therm statistic in der DB erfasst werden, die Werte weiterhin in der DB erfasst werden und wie auch schon mal in einem anderen Beitrag erwähnt kann das m.M.n. eigentlich nur dann funktionieren wenn zeitgleich andere Daten aus der DB gelöscht und/oder überschrieben werden. Anders wäre es halt gar nicht möglich das sich die DB-Größe um 0 % ändert.
Im Moment habe ich aber wenig Zeit für HA und ehrlich gesagt auch nicht wirklich Lust mir über dieses Verhalten weiter Gedanken zu machen. Solange ich die Daten über die DB geliefert bekomme die ich haben möchte kann HA und die DB da machen was sie möchte, auch wenn ich (aktuell) nicht verstehe was da wie gemacht wird.
VG Jim
Ich komme eher aus dem MS Umfeld. Dort ist es so, dass Plattenplatz, welchen der MS-SQL Server einmal genutzt hatte, nicht automatisch wieder freigegeben wird, sondern von neuen Daten aufgefüllt wird.
So kann es im MS Umfeld ohne weiteres passieren, dass z.B. durch eine DB Umstellung oder auch löschen von Datensätzen logischer Platz in der DB entstanden ist, ohne dass sich die Größe der DB auf der Platte verkleinert hätte.
Neue Daten haben dann erst einmal diesen logisch freien Platz belegt - von außen sah es dann so aus, als wenn Daten in die DB geschrieben werden, ohne dass diese zu einer Vergrößerung der DB auf der Festplatte geführt hätte.
Also der von Dir beschriebene Effekt.
Wie gesagt - bezieht sich alles auf den MS-SQL-Server und ich habe von der HA DB zu weinig Ahnung, um sagen zu können, ob es dieses Verhalten dort auch gibt.
Klingt logisch, aber dann dürfte es auch keinen Abfall der DB-Größe zum Zeitpunkt von „purge“ geben, oder?
Auch hier kann ich nur wieder meinem MS-SQL Wissen einbringen: Es gibt entsprechende TSQL Befehle, um den logischen freien Platz in der DB auch auf die Dateien zu übertragen und damit dann auch die eigentliche DB-Datei zu verkleinern. Ähnliches könnte auch der “purge” im HA Umfeld bewirken.
Moin,
doch, wenn gleichzeitig ein Vacuum gemacht wird, dann werden die Datenblöcke wieder zusammengeführt und neu im/auf dem Speicher geschrieben.
Wenn Du das Add-on SQLite Web installiert hast, dann kannst Du in der Datenbank ja so einiges nachschauen.
Wenn man frisch in die Web UI kommt, kann man auch den Befehl im Query Block eingeben und ausführen.
VG
Bernd
Logischer Platz schön und gut, aber das erklärt das aktuelle Verhalten bei @harryp und bei mir m.M.n. auch nicht wirklich. D.h. warum werden in der DB über einen Zeitraum von x Tagen Daten erfasst und die DB-Größe ändert sich fortlaufend und dann hört genau das auf und die DB-Größe bleibt statisch?
Hier noch einmal ein Screenshot der DB-Größe vom kompl. September:
recorder:
purge_keep_days: 30
Wie man sehen kann war die DB-Größe am 01.09. irgendetwas um die 3.650 MB und ist dann bis zum 08.09. auf irgendwas um die 4.150 MB angewachsen. Dann erfolgte am 08.09. ein automatisches auto_purge und/oder auto_repack, sodass die DB-Größe wieder auf ca. 3.850 MB reduziert wurde. Dann wurden wieder ganz normal Daten erfasst, aber halt nur bis zum 15.09. Ab dann wird für die DB eine statische Größe von genau 4.038,25 MB angezeigt.
Was sollte also in Verbindung mit “logischen Platz” die Erklärung dafür sein das die DB mal bis 4.150 MB anwächst und dann plötzlich über Tage hinweg bei exakt 4.038,25 MB stehen bleibt? Und warum legt die DB dieser Verhalten mal - wie aktuell - nach 7 Tagen (08.09. - 15.09.), mal nach 5 Tagen und mal erst nach > 10 Tagen an den Tag?
Das
passt m.M.n. nicht dazu, denn welcher “logische freie Platz” soll das dann genau sein und warum verharrt die DB-Größe dann bei mir genau bei 4.038,25 MB und nicht bei z.B. 4.150 MB, oder 4.000 MB, oder wo auch immer. Wer oder was gibt genau dieses Verhalten vor? Die Zeit kann es nicht sein und die Größe der DB auch nicht. Sprich wie kommt die DB auf die Idee am 15.09. bei einer Größe von exakt 4.038,25 für sich zu entscheiden jetzt die Größe nicht mehr zu verändern sondern stattdessen irgendeinen “logischen freien Platz” zu befüllen?
Mal ganz abgesehen davon das es dieses Verhalten der DB hier bei mir vor ein paar Monaten noch gar nicht gab, sondern es erst irgendwann vor ein paar Monaten aufgetaucht ist.
Das es logischen Speicherplatz in einer DB gibt der u.a. auch mit verwendet wird und der dazu führen kann das sich eine DB-Größe (scheinbar) nicht ändert ist schon klar, aber m.M.n. hat das nichts mit dem aktuellen DB-Verhalten bei @harryp und bei mir zu tun.
Edit: Noch ein Grund der dafür spricht das hier irgendetwas nicht stimmt. Lt. Recorder-Doku soll jeden zweiten Sonntag ein auto_repack erfolgen
auto_repack boolean (Optional, default: true)
Automatically repack the database every second sunday after the auto purge. Without a repack, the database may not decrease in size even after purging, which takes up disk space and can make Home Assistant slow.
D.h. für den September würde das bedeuten das wenn am 08.09. ein auto_repack erfolgt ist gestern, also am 22.09. ein erneuter auto_repack hätte erfolgen müssen. Dies hätte die DB-Größe dann gestern, so wie ja auch am 08.09., entsprechend verringern müssen. Aber das ist halt nicht erfolgt sondern die DB-Größe verharrt weiterhin auf 4.038,25 MB.
Für mich gilt daher das ich bisher keine wirklich Erklärung für diese Verhalten gefunden habe und es b.a.W. weiter ignoriere solange in der DB zumindest die Daten erfasst werden die ich haben möchte. Die Alternative dazu wäre nämlich die DB zu löschen und dann neu erstellen zu lassen. Darüber mache ich mir ggf. Ende des Jahres mal wieder Gedanken, sofern sich das Verhalten der DB bei mir hier bis dahin nicht ggf. doch noch geändert haben sollte und/oder ich eine für mich nachvollziehbare Erklärung dafür finde.
VG Jim
@harryp FYI: Nachdem ich jetzt einen weiteren Monat abgewartet habe musst ich wieder und weiterhin feststellen das sich das DB-Verhalten nicht geändert hast. Trotz
recorder:
purge_keep_days: 30
bleibt die Größe der DB hier auch nach weiteren 30 Tagen bei konstand 4.038,25 MB.
und ich glaube auch nicht das da heute Nacht noch etwas passiert.
Edit: Wie sieht es denn bei Dir inzwischen mit der DB aus? Erfolgt eine konstante Vergrößerung und dann wieder ein automatisches purge/repack, oder verharrt die DB bei Dir auch weiterhin bei einer bestimmten Größe?
VG Jim
Danke für die Info. Du meinst mit “getan” ja vermutlich die Änderung ganz rechts. Hätte dort nicht dann erst automatisch ein auto_purge und auto_repack passieren müssen, sodass sich die DB-Größe dann hätte verringern sollen/müssen?
VG Jim
Ja, wahrscheinlich schon, es sei denn der Platz war wirklich reserviert.
Ich warte jetzt mal bis zum 07.11.2024.
