Logging-Datenbank Daten ausdünnen

mischo22 · 19. März 2013 um 19:20

Hallo!

Ich habe das Problem, dass ich vor einigen Jahren den Zählerstand meines Energiezählers zu oft in die Datenbank geloggt habe (die Variable wurde zu oft aktualisiert - jede 3 Sek). Später habe ich das auf 60 Sekunden angepasst.
Leider sind nun zu viele Werte in der Datenbank für das Jahr 2011. Ich würde daher die Werte ausdünnen wollen, so dass nur ca. jede 60 Sekunden ein Log-Wert in der Tabelle existiert.

Über einen externen SQLite Editor kann ich SQL-Scripte ausführen und die Daten Löschen/Manipulieren.
Hat jemand schon mal ein Script geschrieben, welches alle Zeilen löscht, so dass z.B. nur noch alle 60 Sekunden (Spalte Timestamp) ein Datenwert existiert?

Ich habe bereits heute 4 Stunden Zeit investiert um ein SQL-Script zuschreiben.
Leider erfolglos, zumal SQLlite sehr eingeschränkt ist, wenn es um komplexe abläufe geht (komme aus der MSSQL-Welt).

Vielleicht kann mir jemand einen Tip geben.

PS: Rauslöschen von allen Datensätzen,wo z.B. der Timestamp Modulo 60 ist, funktioniert nicht, da Timestamp keine fortlaufende Indexspalte ist.

mcbelly · 19. März 2013 um 19:29

Hast Du dir das mal angeschaut: http://www.raketenschnecke.net/rs-db-analyzer/ ?

Eventuell hilft Dir das ja,…

Symkie · 22. März 2013 um 08:23

Du könntest es auch in PHP schreiben… Dann kann man dann gut mit for/next/each Schleifen arbeiten.

Datenbank erstmal sichern, es geht ja um ein experimentelles Script.
Alle Datensätze einlesen (mit SORT BY TIMESTAMP), und erst einmal ein paar Hundert um zu sehen wie lange das Script dafür überhaupt benötigt.
Ersten Timestamp als Referenz verwenden
Wenn nächster Timestamp kleiner als Referenz+60, dann SQL Befehl zum löschen aus der Datenbank auslösen.
Wenn der gleiche Timestamp (der in Punkt 4 geprüft wurde) größer als Referenz+60, dann diesen Timestamp als Referenz verwenden.
Goto 4)

mischo22 · 22. März 2013 um 09:24

An so eine Lösung habe ich auch gedacht. Ich werde mich mal hinsetzen und ein delphi Programm schreiben, was dies erledigt.

Symkie · 22. März 2013 um 09:25

Du hast doch IPS?!? Starte ein PHP Script per Button :c)

mischo22 · 22. März 2013 um 10:30

Richtig, aber kann ich lowlevel auf die Datenbank zugreifen und Daten löschen wenn IPS parallel mit der Datenbank arbeitet? Ich denke da ist eine Zerstörung der DB vorprogrammiert.

Oder gibt es Befehle, die SQLlite Datenbank via IPS direkt anzusprechen?
Wenn ja, wo steht dazu was?

Raketenschnecke · 22. März 2013 um 10:50

wenn du noch etwas warten kannst: der DB-Analyzer bekommt in Kürze ein entsprechendes Modul spendiert, welches diese Aufgabenstellung löst.
Die Funktion läuft schon, nur die Implementierung in den DB-Analyzer fehlt noch

Raketenschnecke · 29. März 2013 um 14:19

falls es noch von Interesse ist: mein DB-Analyzer V2.7 ist fertig, die Versionsinfos finden sich hier:
http://www.raketenschnecke.net/2013/03/29/rs-db-analyzer-update-v2-7/

Dazugekommen ist das Modul „Record Reducer“, welches nach Uservorgaben das Datenlogging von Variablen ausdünnen kann (Reduktion auf 1 Datensatz pro Stunde). Details im Link oben.

mischo22 · 29. März 2013 um 17:49

Cool, Werde das mal ausprobieren.

Frage:
Ist das Reduktionsintervall anpassbar?
Ich habe leider einige Variablen, die wurden in der Vergangenheit jede 2 Sekunden geloggt.
Ich würde gerne auf 1 Minute (Statt einer Stunde) reduzieren.

hbraun · 31. März 2013 um 08:32

Hallo,

bei mir ist der record reducer leer, muss ich da noch etwas machen?

Raketenschnecke · 31. März 2013 um 09:18

Moin Horst,

vermutlich hast du nach dem Update das User-Config Script (Initialisierung) nicht gestartet?

hbraun · 31. März 2013 um 09:54

Doch eigentlich schon. Habe jetzt die Bude voll, melde mich später nochmal.

Gesendet von meinem GT-I9300 mit Tapatalk 2

hbraun · 31. März 2013 um 17:55

hallo,

ich habe jetzt einfach mal das Script DB Record Reducer händisch gestartet :rolleyes: , nun ist alles da.

Raketenschnecke · 31. März 2013 um 18:09

Hallo Horst,

das heisst aber nicht, dass intern alles richtig installiert und verknüpft ist. Wenn du das Installscript nochmal ausführts: tauchen im Meldungsfenster irgendwelche Fehlermeldungen auf?

Hintergrund der Frage; ich hab heute nachmittag mit Werner 2h lang fehler gesucht. Am Ende stellte sich raus, dass ein im Project Exporter bereits behobener Bug doch nicht zu 100% behoben wurde. Verursacht wird das Problem eigentlich durch den IPS-internen Editor, wenn ein Installationsprotokoll via Editor geöffnet und wieder gespeichert wurde. Nur dass der Exporter das noch nicht zu 100% kompensiert hat.

hbraun · 31. März 2013 um 19:10

hallo Rainer,

ich habe jetzt den ganzen DB Analyzer gelöscht und neu installiert. Ist aber nicht gan sauber durchgelaufen, hier ein Teil der Meldungen:

			--- Kontrolle durch User erforderlich -----------------------------------------------------
   	#3066 Event-Objekt ScriptTimer, neuID #43047 neu konfiguriert, NICHT aktiviert
   	#3066 Event-Objekt ScriptTimer, neuID #24424 neu konfiguriert, NICHT aktiviert
   	#3066 Event-Objekt ScriptTimer, neuID #38557 neu konfiguriert, NICHT aktiviert
   	#3066 Event-Objekt ScriptTimer, neuID #34288 neu konfiguriert, NICHT aktiviert
   	#3066 Event-Objekt ScriptTimer, neuID #36380 neu konfiguriert, NICHT aktiviert
   	#3066 Event-Objekt ScriptTimer, neuID #27919 neu konfiguriert, NICHT aktiviert
   	#3066 Event-Objekt ScriptTimer, neuID #24592 neu konfiguriert, NICHT aktiviert
   	#3066 Event-Objekt ScriptTimer, neuID #16736 neu konfiguriert, NICHT aktiviert
   	#3066 Event-Objekt ScriptTimer, neuID #35869 neu konfiguriert, NICHT aktiviert
   	#3066 Event-Objekt ScriptTimer, neuID #54271 neu konfiguriert, NICHT aktiviert
   	#3066 Event-Objekt ScriptTimer, neuID #20150 neu konfiguriert, NICHT aktiviert
		--- Kontrolle durch User erforderlich Ende-------------------------------------------------

			--- Kontrolle durch User erforderlich -----------------------------------------------------
   	#5010 Script ID#54875.ips.php: Inhalt NICHT verändert: Zeile 183, alte Target-ID #55819 nicht innerhalb des Projektes
   	#5010 Script ID#54875.ips.php: Inhalt NICHT verändert: Zeile 321, alte Target-ID #55819 nicht innerhalb des Projektes
   	#5010 Script ID#54875.ips.php: Inhalt NICHT verändert: Zeile 328, alte Target-ID #55819 nicht innerhalb des Projektes
   	#5010 Script ID#54875.ips.php: Inhalt NICHT verändert: Zeile 335, alte Target-ID #55819 nicht innerhalb des Projektes
   	#5010 Script ID#54875.ips.php: Inhalt NICHT verändert: Zeile 342, alte Target-ID #55819 nicht innerhalb des Projektes
   	#5010 Script ID#54875.ips.php: Inhalt NICHT verändert: Zeile 349, alte Target-ID #55819 nicht innerhalb des Projektes
   	#5010 Script ID#54875.ips.php: Inhalt NICHT verändert: Zeile 644, alte Target-ID #55819 nicht innerhalb des Projektes
   	#5010 Script ID#12588.ips.php: Inhalt NICHT verändert: Zeile 225, alte Target-ID #55819 nicht innerhalb des Projektes
   	#5010 Script ID#12588.ips.php: Inhalt NICHT verändert: Zeile 371, alte Target-ID #55819 nicht innerhalb des Projektes
   	#5010 Script ID#12588.ips.php: Inhalt NICHT verändert: Zeile 378, alte Target-ID #55819 nicht innerhalb des Projektes
   	#5010 Script ID#12588.ips.php: Inhalt NICHT verändert: Zeile 385, alte Target-ID #55819 nicht innerhalb des Projektes
   	#5010 Script ID#12588.ips.php: Inhalt NICHT verändert: Zeile 392, alte Target-ID #55819 nicht innerhalb des Projektes
   	#5010 Script ID#12588.ips.php: Inhalt NICHT verändert: Zeile 399, alte Target-ID #55819 nicht innerhalb des Projektes
   	#5010 Script ID#50457.ips.php: Inhalt NICHT verändert: Zeile 192, alte Target-ID #41546 nicht innerhalb des Projektes
   	#5010 Script ID#26374.ips.php: Inhalt NICHT verändert: Zeile 244, alte Target-ID #41546 nicht innerhalb des Projektes
   	#5010 Script ID#32296.ips.php: Inhalt NICHT verändert: Zeile 44, alte Target-ID #38711 nicht innerhalb des Projektes
   	#5010 Script ID#24412.ips.php: Inhalt NICHT verändert: Zeile 95, alte Target-ID #55819 nicht innerhalb des Projektes
   	#5010 Script ID#24412.ips.php: Inhalt NICHT verändert: Zeile 194, alte Target-ID #55819 nicht innerhalb des Projektes
   	#5010 Script ID#24412.ips.php: Inhalt NICHT verändert: Zeile 200, alte Target-ID #55819 nicht innerhalb des Projektes
   	#5010 Script ID#24412.ips.php: Inhalt NICHT verändert: Zeile 501, alte Target-ID #55819 nicht innerhalb des Projektes
   	#5010 Script ID#45299.ips.php: Inhalt NICHT verändert: Zeile 274, alte Target-ID #55819 nicht innerhalb des Projektes
   	#5010 Script ID#45299.ips.php: Inhalt NICHT verändert: Zeile 317, alte Target-ID #40000 nicht innerhalb des Projektes
   	#5010 Script ID#45299.ips.php: Inhalt NICHT verändert: Zeile 323, alte Target-ID #40000 nicht innerhalb des Projektes
   	#5010 Script ID#51635.ips.php: Inhalt NICHT verändert: Zeile 556, alte Target-ID #40000 nicht innerhalb des Projektes
   	#5010 Script ID#51635.ips.php: Inhalt NICHT verändert: Zeile 625, alte Target-ID #40000 nicht innerhalb des Projektes
   	#5010 Script ID#51635.ips.php: Inhalt NICHT verändert: Zeile 634, alte Target-ID #40000 nicht innerhalb des Projektes
		--- Kontrolle durch User erforderlich Ende-------------------------------------------------

Das ist das einzige was auffällig ist, alles andere sind OK Meldungen.
Im Webfront sieht auch alles normal aus.

Raketenschnecke · 31. März 2013 um 19:29

ok, ich antworte mal stellvertretend für Rainer

der erste Code-Block ist völlig ok, das sind nur Hinweise für den User, dass Timer nicht aktiviert wurden. Wird in meinen Projekten im Allgemeinen durch die manuelle Initialisierung nach der Installation (Ausführung des Unser-Config Scripts geregelt).

Der 2. Code-Block ist (zumindest Stickprobenartig gecheckt) ok: man kann per Script nur schwer erkennen, ob eine 5stellige Zahl im Code eine IPS-Objekt-ID ist oder nicht. Also weist das Installscript alle fraglichen/unklaren Zahlen als „kontrollwürdig“ aus. Ich hab zwar einige Prüfungen drin, die die Meldungen reduzieren, hilft aber nicht immer.

In den ersten Zeilen Deiner Beispiele (#55819) ist es z.B. eine Farbangabe. Und das könnte durchaus eine IPS-ID sein, weil sie z.B. innerhalb der gültigen Range (10000 - 59999) liegt.

Also auch hier alles ok.

Ich lade gleich ein neues Installationspaket hoch, was die Protokollfile-Problematik behebt. Wer keine Installationsprobleme hatte, braucht nichts tun.

Andreas
alias Rainer
alias Raketenschnecke

hbraun · 31. März 2013 um 19:55

Sorry Andreas,

war wohl etwas durch den Wind :o
So richtig läuft es noch nicht. Diese Zeile:
$Avg7d = $RawData7d[(int)$Inventory[$i][2]][‚DayAvg‘]; im Script Create WFE-Table

wird angemeckert

das ist die Variable DB-Datensätze.

Wenn ich die Vorhaltezeit für die Daten eingebe

Raketenschnecke · 31. März 2013 um 20:40

ich vermute im Moment nur: die Variable ist neu (weil eben neu installiert), hat noch keine geloggten Daten? Müsste ich noch eine Plausiprüfung einbauen, um den Fehler zu vermeiden. Ist m.E. unkritisch und sollte spätestens nach 7 tagen wech sein

hbraun · 31. März 2013 um 20:59

Ok, werde dann mal abwarten.

GeTapatalk(t) mit meinem Galaxy Tab 10.1N

Raketenschnecke · 31. März 2013 um 21:10

ja, das ist wirklich unkritisch: hier gehts nur um den 7-Tage Durchschnitt des datenwachstums der betr. Variable.

Du kannst es mal mit einem ‚@‘ vor $RawData7d versuchen…