[gelöst] DBD::SQLite::st execute failed: database or disk is full at ./FHEM/

[jnewton957]

Hallo,
nach beimen DB crash Anfang Dezember habe ich ja alles wieder neu aufgesetzt.
FHEM ist auf neuestem Stand.
93_DbRep.pm:v8.50.7-s26865/2022-12-17

Meine SQLite DB ist ausgelagert: /media/usb256/fhemsql3.db

Nun hatte ich mir ein Rep.SQLite gem. Anleitung angelegt.
Das hat auch super funktioniert.
Nun bekomme ich seit dem 25.12.22 nachfolgende Fehlermeldung:

Code Auswählen Erweitern

DBD::SQLite::st execute failed: database or disk is full at ./FHEM/93_DbRep.pm line 10817.

Code Auswählen Erweitern

READINGS:
     2023-01-02 19:58:24   after_dump_message Reopen executed.
     2023-01-02 19:58:24   errortext       DBD::SQLite::st execute failed: database or disk is full at ./FHEM/93_DbRep.pm line 10817.

     2023-01-02 19:58:24   state           error
Attributes:
   dumpDirLocal /media/usb500/backup
   dumpFilesKeep 3
   event-on-update-reading state
   executeAfterProc set DbLog reopen
   executeBeforeProc set DbLog reopen 3000
   optimizeTablesBeforeDump 1
   room       99_DbLog
   showproctime 1
   verbose    3

/media/usb500/backup ist eine neue gemountete 500GB SSD  /dev/sdb1 466G  574M  466G    1% /media/usb500

Die fhemsql3.db ist 42MB groß. fhem hat mit chown -R fhem:dialout auch Rechte bekommen.

Was läuft da schief?

Danke für die Hilfe
Jörg

[DS_Starter]

Ich gehe davon aus, dass deine DB corrupt ist.
Versuche ein

set ... repairSQLite

Wenn die Vermutung stimmt und es danach wieder klappt mit der DB, würde ich den mount checken. Die DB ist über den mount ausgelagert.
Sollte es damit Probleme geben, könnte es m.M. nach zur Korruption kommen.

[jnewton957]

Ich gehe davon aus, dass deine DB corrupt ist.
Versuche ein

set ... repairSQLite

Ah.... mein Lieblingsbefehl nach dem Top 1 Befehl: backup

Repair finished /media/usb256/fhemsql3.db

aber leider weiterhin:

Code Auswählen Erweitern

DBD::SQLite::st execute failed: database or disk is full at ./FHEM/93_DbRep.pm line 10817.

Ich habe das mal optimizeTablesBeforeDump auf 0 gesetzt und neu einen dump gemacht.

Code Auswählen Erweitern

2023.01.03 08:39:12 3: DbRep Rep.SQLite - Starting dump of database 'fhemsql3.db'
2023.01.03 08:39:15 3: DbRep Rep.SQLite - Size of backupfile: 42.63 MB
2023.01.03 08:39:18 3: DbRep Rep.SQLite - Finished backup of database fhemsql3 - total time used (hh:mm:ss): 00:00:06
2023.01.03 08:39:18 3: DbLog DbLog: Reopen requested.
2023.01.03 08:39:18 3: DbLog DbLog - Creating Push-Handle to database SQLite:dbname=/media/usb256/fhemsql3.db with user
2023.01.03 08:39:18 3: DbLog DbLog - Push-Handle to db SQLite:dbname=/media/usb256/fhemsql3.db created
2023.01.03 08:39:19 2: DbRep Rep.SQLite - command message after dump: "Reopen executed."
2023.01.03 08:39:19 3: DbRep Rep.SQLite - Database dump finished successfully.

Es liegt also am "optimizeTablesBeforeDump"

[DS_Starter]

Moin,

Es liegt also am "optimizeTablesBeforeDump"

Hätte ich jetzt nicht gedacht. Der Befehl macht intern ein "vacuum" und braucht dafür zusätzlichen temporären Plattenplatz.
Aber davon hast du eigentlich genug.
Wahrscheinlich wird der temporäre Platz aber lokal benötigt. Bei SQLite müsste ich erstmal googeln wie sich die DB verhält, kann ich addhoc nicht sagen. Sieht aber danach aus. Musst du mal schauen wie dein lokaler Speicher ausgelastet ist.

Vacuum auszuführen ist auch nicht bei jedem Backup sinnvoll, nur wenn viel Löschungen vorgenommen wurden.
Diesen Befehl gibt es auch als Setter separat. Es reicht ihn von Zeit zu Zeit mal aufzurufen.

[jnewton957]

Hätte ich jetzt nicht gedacht. Der Befehl macht intern ein "vacuum" und braucht dafür zusätzlichen temporären Plattenplatz.
Aber davon hast du eigentlich genug.
Wahrscheinlich wird der temporäre Platz aber lokal benötigt. ... Musst du mal schauen wie dein lokaler Speicher ausgelastet ist.

Eigentlich ist da auch genug Platz. Ich hatte Anfang Dez mal das komplette RPi von 16GB auf 32 GB umgezogen.
/dev/root        29G     15G   13G   53% /

Aber es hat ja geklappt und ich beobachte weiter.

Danke für die Hilfe. ==> Titel auf [gelöst] geändert.

[betateilchen]

Hätte ich jetzt nicht gedacht. Der Befehl macht intern ein "vacuum" und braucht dafür zusätzlichen temporären Plattenplatz.
Aber davon hast du eigentlich genug.
Wahrscheinlich wird der temporäre Platz aber lokal benötigt. Bei SQLite müsste ich erstmal googeln wie sich die DB verhält,

sqlite schreibt eine neue Datenbank mit dem verdichteten Inhalt und überschreibt danach die ursprüngliche Datenbankdatei mit der neuen Datenbank.

Alternativ kann man auch "vacuum into" verwenden, dann wird eine neue Datei mit neuem Namen geschrieben und die alte Datei bleibt unangetastet. Vorteil: man braucht keinen temporären Platz, sondern kann die neue Datei gleich dorthin schreiben, wo sie später erwartet wird.

Bei mir verwende ich "vacuum into" gerne 'umgekehrt': ich benenne die originale Datenbank um und mache dann ein "vacuum into" in den ursprünglichen Dateinamen. Wenn das alles funktioniert hat, wird die alte Datei gelöscht.

[DS_Starter]

Danke für die Info betateilchen, insbesondere die Ergänzung "vacuum into".
Das schaue ich mir genauer an ob es für DbRep eine Option sein könnte.

[jnewton957]

Danke für die Info betateilchen, insbesondere die Ergänzung "vacuum into".
Das schaue ich mir genauer an ob es für DbRep eine Option sein könnte.

Wäre das Thema "vacuum into" nicht auch was fürs wiki?

[DS_Starter]

Habe gerade etwas zu dem ursprünglichen Problem gefunden: https://stackoverflow.com/questions/23249843/sqlite3-vacuum-database-or-disk-is-full

Kannst du dir mal anschauen für dein System.

Wäre das Thema "vacuum into" nicht auch was fürs wiki?

Im Wiki kann jeder mitarbeiten. Prinzipiell kann man über DbRep sqlCmd beliebige Kommandos abarbeiten.
Insofern kann man einen Artikel im DbRep-Wiki dazu schreiben.

[betateilchen]

Das schaue ich mir genauer an ob es für DbRep eine Option sein könnte.

Es wäre bestimmt sinnvoller, in sqlite Datenbanken für DbLog das pragma auto_vacuum zu setzen, bevor die Tabellen in der Datenbank angelegt werden.

https://www.sqlite.org/pragma.html#pragma_auto_vacuum

[DS_Starter]

Da hast du recht. Gilt dann aber nur wenn jemand mit dem angepassten Script aus contrib die DB neu anlegt.
Werde ich aber mal ergänzen und testen.

Vllt. wäre es ergänzend möglich, den Ablauf "repairSQLite" im DbRep mit dem Pragma zu ergänzen ?
Wenn das funktioniert, könnte der User über diesen Weg seine bestehende DB automatisiert auf auto_vacuum umsetzen.
Muss ich aber erstmal anschauen und testen.

Ach ich lese gerade im Manual:

Code Auswählen Erweitern


....
To change auto-vacuum modes, first use the auto_vacuum pragma to set the new desired mode, then invoke the VACUUM command to reorganize the entire database file.


Würde also imho über diesen Weg nachträglich funktionieren.

[DS_Starter]

Es wäre bestimmt sinnvoller, in sqlite Datenbanken für DbLog das pragma auto_vacuum zu setzen, bevor die Tabellen in der Datenbank angelegt werden.

Ich habe das PRAGMA auto_vacuum bei der Neuerstellung getestet und das Script im db_create_sqlite.sql contrib/dblog ergänzt.
Hat einwandfrei funktioniert.

Auch das Kommando "vacuum" im DbRep setzt nun bei Ausführung die benutzte Datenbank um auf die Nutzung von auto_vacuum = FULL.

[jnewton957]

Ich habe auch noch etwas beizutragen, da ja häufig bei größeren DB der Fehler: disk full erscheint, da eben das tmp Verzeichnis /var/tmp oder /usr/tmp nicht ausreichend Platz für das vacuum hat. Man braucht wohl bis zum doppelten des Platzes der sqlite db.

Code Auswählen Erweitern


sqlite> pragma temp_store_directory = '/directory/with/lots/of/space';

Damit kann man das tmp Verzeichnis auf ein anderes medium verlagern. Dann klappt auch das vacuum bei größeren db.

[DS_Starter]

Danke für den Hinweis. Nehme ich in die Hilfe zum Vacuum Kommando (DbRep) auf.

[betateilchen]

Den Parameter kann man auch als Umgebungsvariable setzen, wenn ich das richtig in Erinnerung habe.