DBLog und DBRep Problem (SQLite)

[stefanru]

Ich liefere mal noch die Versionen von mir nach:
SQLite: 3.16.2

Perl:
This is perl 5, version 24, subversion 1 (v5.24.1) built for arm-linux-gnueabihf-thread-multi-64int
(with 85 registered patches, see perl -V for more detail)

Habe gerade geschaut ob apt-get ein update liefert aber Fehlanzeige...

Gruß,
Stefan

[DS_Starter]

Die Versionen SQLite und Perl habe ich auch. Das passt dann schon mal.

Noch eine Frage, betreibst du DbLog synchron oder asynchron ?
DbRep (der Export) arbeitet nämlich immer asynch.

[stefanru]

Habe ich Probiert.
Hatte es Asynchron, da ich das auch als Fehlerquelle gesehen hab ist es seit heute mittag auf Synchron.
Hat aber nichts verändert am Fehler.

Gruß,
Stefan

[DS_Starter]

Naja, weißt wenn es ein genereller Fehler im DbLog wäre dann hättest du es wahrscheinlich schon viel eher bemerkt. Denn es ging doch bis vor kurzem ?
Und diese Selects speziell für die Gets bzgl. Plots sind schon "ewig" nicht geändert worden.
Mal schauen was wir noch herausbekommen.

[stefanru]

Ich werde wahnsinnig!

Da du mich mit der Perl Version usw auf eine Idee gebracht hast und da mein letztes update gut als Zeitpunkt passte habe ich jetzt nochmal apt-get update und apt-get upgrade gemacht.
Es war aber weder Perl noch SQLite oder irgendetwas interessantes dabei.
Nur Chromium und phyton.

Trotzdem habe ich den Raspberry mal durchgestartet.
Und siehe da nach dem Restart ist alles in Ordnung!!!

Was ist das denn jetzt?
Beim letzten update habe ich auch nen reboot danach gemacht.
Ich habe dafür keine Erklärung.
Hast du ne Idee was das sein kann.

Alle Graphen sind ok. Ich glaub das einfach nicht.

Das nächste mal mach ich zuerst ein reboot.

Ich danke dir vielmals für deine Unterstützung, weiß gar nicht wie ich das wieder gut machen kann

Danke und Gruß,
Stefan

[DS_Starter]

 
Reboot tut gut !   Alte IT-Weisheit. *grins*

Sowas kann ich auch nicht erklären. Vielleicht können Linux Profis dafür Erklärungen finden.
Aber gut das du es jetzt noch gefunden hast. 

Alles gut Stefan, solche Probleme sind ja irgendwo auch interessant und jetzt hast du im DbLog ein paar neue Attribute kennengelernt 

LG,
Heiko

[DS_Starter]

Stefan, du solltest jetzt auch nochmal das vacuum probieren 

[stefanru]

Hi,

ne bei Vacuum bleibts dabei.
Das Problem hatte ich auch von Anfang an.
DBD::SQLite::st execute failed: database or disk is full at ./FHEM/93_DbRep.pm line 6223.

Gruß,
Stefan

[DS_Starter]

Hallo Stefan,

ich habe dir eine Testversion von DbRep bereitgestellt:

https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter  (Downloadbutton benutzen)

Nun ist es beim sqlCmd möglich ein oder mehrere PRAGMA anzugeben.
Die Form wäre so:

Code Auswählen Erweitern


set <name> sqlCmd PRAGMA temp_store=MEMORY; PRAGMA synchronous=FULL; PRAGMA journal_mode=WAL; PRAGMA cache_size=4000; select count(*) from history;

Verbose 4 zeigt dir die einzeln abgearbeiteten Statements.
Probier mal ob es dir hilft.

EDIT: vorher fhem updaten. Ich brauche eine Funktion aus aktuellem 99_Utils.pm !

Grüße
Heiko

[stefanru]

Hi,

danke, probiere ich morgen.

Gruß,
Stefan

[stefanru]

Ok, super!
So tut das jetzt im DBRep bei mir.

Gebe ich ein

Code Auswählen Erweitern


set <name> sqlCmd PRAGMA temp_store=FILE; PRAGMA temp_store_directory = '/opt/fhem/'; VACUUM;

legt er die kopie zum reorg in /opt/fhem/ ab.

Seltsamerweise interessiert ihn die Umgebungsvariable

Code Auswählen Erweitern


fhem@raspberrypi:~$ printenv
SQLITE_TMPDIR=/opt/fhem/tmp

nicht.

Vielleicht liegt es auch einfach an dem PRAGMA temp_store=FILE; Es wird ja im Modul immer auf MEMORY gesetzt.

Ok das wollte ich jetzt doch wissen.
Also ein:

Code Auswählen Erweitern


sqlCmd PRAGMA temp_store=MEMORY; PRAGMA temp_store_directory = '/opt/fhem/'; VACUUM;

ging auch durch.

Ein

Code Auswählen Erweitern


sqlCmd VACUUM;
führt direkt zu
DBD::SQLite::st execute failed: database or disk is full at ./FHEM/93_DbRep.pm line 5714.

Sag mal die Befehle werden doch unter dem fhem Nutzer ausgeführt? Dem habe ich das SQLITE_TMPDIR=/opt/fhem/tmp extra gesetzt?
Könnte man das PRAGMA temp_store_directory = '/opt/fhem/'; eventuell als attribut setzen?

Gruß und Danke,
Stefan

[DS_Starter]

Danke für die Rückmeldung Stefan, dann nehme ich die Version ins Repository und ist morgen früh im normalen Update enthalten.

Vielleicht liegt es auch einfach an dem PRAGMA temp_store=FILE; Es wird ja im Modul immer auf MEMORY gesetzt.

Ja möglich. Kannst du ja mal im DbLog auskommentieren. Allerdings störte es bei mir nicht.

Dein Beispiel nehme ich mal mit in die commandRef von sqlCmd auf. 

LG,
Heiko

[stefanru]

Hi Heiko,

habe den post eins drüber nochmal geändert. Am Memory liegt es nicht, es liegt am temp_store_directory.
Vielleicht könnte man das als attribut setzen?

Gruß,
Stefan

[DS_Starter]

Sag mal die Befehle werden doch unter dem fhem Nutzer ausgeführt? Dem habe ich das SQLITE_TMPDIR=/opt/fhem/tmp extra gesetzt?

Ja, unter dem Nutzer mit FHEM gestartet ist

Könnte man das PRAGMA temp_store_directory = '/opt/fhem/'; eventuell als attribut setzen?

Machbar wäre das schon. Allerdings müsste man so etwas allgemeiner halten weil DbRep ja nicht nur SQLite unterstützt.
Man könnte ein Attribut anbieten welches für SQLite ein oder mehrere PRAGMAS enthalten kann oder aber SQL-Variablen
für MySQL.

Könnte so aussehen:

Code Auswählen Erweitern

attr <name> sqlCmdVars PRAGMA temp_store=FILE; PRAGMA temp_store_directory = '/opt/fhem/';

Und würde für die Ausführung von sqlCmd Kommandos gelten.

[stefanru]

Ja, ich denk das fände ich cool und würde mein Problem beseitigen.

Danke dir vielmals,
Stefan