logging.db etwas sehr groß geworden

Hallo Zusammen,

ich habe da ein Problem(chen):
Habe gerade ernsthafte Probleme, nach einem ganz normalen Reboot des Windows-Rechners mein IPS wieder zum Laufen zu bekommen.

Jetzt dachte ich, „mach erstmal ein Backup des ganzen IPS-Verzeichnisses“, damit im Zweifelsfall nicht alles weg ist. Nachdem das ewig gedauert hat, ist mir jetzt der Übeltäter aufgefallen: Meine logging.db hat im Moment eine Größe von - Aufgepasst! - ca. 13 GB!! Ja, es sind GB!

Was ist denn hier schief gelaufen? Habt ihr eine Idee, was hier zu tun ist?

Viele Grüße
Thomas

da ist nichts schief gelaufen, das ist auch nicht schlimm. Du loggst einfach sehr viel. Was Du loggst und was nicht musst Du schon selbst entscheiden.

Wenn dir die Daten zuviel erscheinen, bleibt Dir wohl nichts anderes übrig als alle Variablen im Archivhandler durchzuschauen und ggf. auzuräumen.

Falls Du aufräumst (=geloggte Daten löscht) wird die DB nicht automatisch kleiner, die kann man dann aber offline mit einem sqlite-Tool komprimieren

Also 13GB sind schon mächtig.

Wieviele Variablen und in welchem Zeitraum /Zyklus werden die gelogged.?

absolut gesehen ja, relativ gesehen fehlen hierzu Rahmenbedingungen (vielleicht loggt er aus gutem Grund und bewusst 100 Variablen im 3 sec Intervall).

Es sollte aber nicht zu Performance-Einbußen bei IPS an sich kommen (bestenfalls im WFE wenn eine Große Menge an Daten auch geplottet wird). Das „einzige“ Problem ist hier das Backup-Handling wegen des großen Files … aber ansonsten sehe ich hier keine Probleme :wink:

Danke für Eure Hinweise!

Nein, absichtlich passiert das nicht - eher durch Unwissenheit :o
Ich werd mir die Sache mit dem Logging wohl mal etwas genauer ansehen müssen.

Danke für die schnelle Hilfe!
Thomas

Na vielleicht loggst du ja wirklich alles mögliche (Beim Durchklicken munter angehakt ;)), was du garnicht brauchst.
Sieh doch mal im Archivhandler nach, was du alles loggst, deaktiviere dann das Logging für diese entsprechenden Variablen und hau’s aus dem Archivhandler raus.
Aber die logging.db wird danach nicht kleiner. Dazu brauchst du externe Tools, um die Datenbank wieder zu bereinigen und komprimieren zu können.

siehe #2

:wink:

Jo klar… dass passte nicht mehr auf meinen Desktop… sry ;):o

[QUOTE=Raketenschnecke;147421
Falls Du aufräumst (=geloggte Daten löscht) wird die DB nicht automatisch kleiner, die kann man dann aber offline mit einem sqlite-Tool komprimieren[/QUOTE]

Hallo Raketenschnecke,

wie heist das Tool und wo finde ich es?

Hi Bussard,

1: SQLite Download Page
oder
2: https://addons.mozilla.org/de/firefox/addon/sqlite-manager/

OK - das ist mir zu hoch:o

Da lasse ich lieber die Finger weg.:frowning:

dachte ich auch, es ist aber überschaubar. Versuch einfach die FF-Lösung.
Vielleicht kann ich dir das hiermit schmackhaft machen: Tricks & Tipps zum Datenmanagement in IP-Symcon | Raketenschnecke.net
:smiley:

Moin,
ich habe nach obigen Anregungen aus dem Blog heute versucht mal meine 600 MB grosse DB mal etwas zu verkleinern.
Resultat: Total zerschossene Datenbank und alle Daten seit 2010 weg. Backups lassen sich nicht mehr zurück spielen und selbst das rücksichern kompletter IPS Ordner zeigt nun die gleichen komischen Aussetzer

Ich habe vielleicht nen Hals…weil es IPS leider noch nicht schafft die DB vernünftig zu komprimieren.
Ein Backup via Dropbox wurde auch immer langwieriger und daher heute die obige Aktion.
Neben der Tatsache das die Daten weg sind hat mir meine Frau für die „Sonntagsarbeit“ am IPS um es wieder sinnvolle Daten anzeigen zu lassen etwas in den Senkel gestellt.

Kurz: kann sich nicht jemand einmal dieser Problemstellung der Komprimierung der DB annehmen ? Die Tools von RS sind echt super. Leider ändert sich aber an dem Platzbedarf der DB nichts.

Wäre echt cool wenn ich sowas nicht noch einmal durchleben müsste.

Gruss
B71

Wer den Schaden hat braucht für den Spot nicht zu sorgen …

Nein im Ernst: Für was benötigst du die ganzen alten Daten überhaupt ? Ist irgendwie gleich wie mit alten Tageszeitungen oder Fachzeitschriften. Man hebts auf aber reinschauen tut man nicht mehr.
Ich mein eine ernsthafte Auswertung von so lange zurückliegenden Daten ist eh nicht gescheit möglich, da man ja die ganzen Randbedingungen nicht mehr erinneren kann.
Ich bin dazu übergegangen die db alle paar Monate einfach zu löschen. Spart Ärger und gefehlt haben mir die alten logs bis lang nicht.

gruß
bb

Hi Bernardo,

ein sauberes DB-Backup MUSS sich zurücksichern lassen. Wenn das zurück gesicherte DB-File nicht läuft, kann es nur korrupt sein.
Das hat erstmal nichts mit IPS oder dem Analyzer zu tun. Wie sich damit die komplette IPS-Installation zerlegt kann ich aus deinem Posting nicht recht entnehmen ;)Wenn man ein sauberes Backup hat, läuft jede IPS-Installation nach der Wiederherstellung mittels Backup.

kann sich nicht jemand einmal dieser Problemstellung der Komprimierung der DB annehmen ? Die Tools von RS sind echt super. Leider ändert sich aber an dem Platzbedarf der DB nichts.

dazu habe ich einige Beschreibungen, wie manbei reduziertem Datenbestand das DB-File komprimiert: klick
mit dem FF-Tool macht es sich am Besten. Hab ich grad erst wieder vor 2 Wochen erfolgreich gemacht.

…jeden Tag eine Vollsicherung gemacht…den ganzen IPS ordner inkl. der DB…
Selbst die ganze Rücksicherung des Ordners hat nichts mehr gebracht.

Das DB File zeiht dann „corrupt“ Fehlermeldungen.
Bis heute morgen war aber alles ohne Fehler und wenn ich jetzt einen Ordner von vor 2 Tagen komplett zurück hole…ebenfalls „corrupt DB“ Meldungen.

Und der Spass hat mit den Tools von FF heute morgen begonnen.
Also soweit hatte ich das ja alles gelesen.

Was auch immer das jetzt war…ich finde es mega doof.
Meine ganzen Gasgraphen und so weiter sind jetzt weg…

Daher wäre es schon cool wenn IPS an der Stelle eine Funktion hätte die die Grösse der DB nach Löschung von Daten reduzieren täte.

Gruss
B71

aber das heisst doch ganz klar: schon dein Backup (und damit auch die DB vor der heutigen Aktion) ist korrupt.

Das DB File zeiht dann „corrupt“ Fehlermeldungen.

was ge3nau bedeutet das? wo steht diese fehlermeldung?

Und der Spass hat mit den Tools von FF heute morgen begonnen.
Also soweit hatte ich das ja alles gelesen.

Was auch immer das jetzt war…ich finde es mega doof.
Meine ganzen Gasgraphen und so weiter sind jetzt weg…

jetzige Panik macht es nicht besser. Hast du mal die DB-Prüfung angeschoben und ne Reparatur laufen lassen?

Daher wäre es schon cool wenn IPS an der Stelle eine Funktion hätte die die Grösse der DB nach Löschung von Daten reduzieren täte.

das geht technisch nicht, weil der Zugriff auf die SQLite exclusiv erfolgt. Dieser Zugriff muss freigegeben werden (also IPS runterfahren).

…ich muss jetzt wohl damit leben…
Nun ist das Backup zumindest wieder fix.

Die Fehlermeldungen kamen wenn der Dienst mit der defekten DB wieder startete. database is malformatted bla, bla, bla…

Danke für die Rückmeldung
B71

Die DB hatte scheinbar wirklich einen Schlag abbekommen.
Denn immer mal wieder hatten die Graphen „25“ als Wert eingetragen, der dann aber bei der Suche nach dem Wert nicht zu finden war.

Ob das jetzt alles mit dem RS Analyzer begonnen hat oder nicht kann ich nicht sagen.
Ein gewisser Zusammenhang einer angeschlagenen DB und einem RS analyzer und dann dem Versuch zu komprimieren vor dem Tod der DB liesse sich vermuten, ist aber nicht zu beweisen und somit werde ich jetzt mit der neuen DB schön darauf achten und noch vorsichtiger agieren.

Gruss
B71

Hi B71,

ich will mich hier nochmal zu Wort melden, um evtl. Außenstenden und Verunsicherten etwas mehr Transparenz zum Thema zu vermitteln:

Grundsätzlich arbeitet der DB-Analyzer ausschließlich mit IPS-Systembefehlen (AC_*). Im Falle von DB-Aggregationen sind diese teilweise nur exclusiv ausführbar (d.h. wurde z.B. eine Reaggregation angestoßen, geht zeitgleich nur diese eine und zwar so lange, bis diese fertig ist).
Wenn man sich jetzt die Foren-Historie anschaut (und speziell der Threads mit Fragen zum DB-Analyzer), so stelle ich fest, dass es immer dann zu bösen Überraschungen kommt, wenn erstmalig der DB-Analyzer (und hier speziell der Reaggregationsbefehl und der Befehl zum Auslesen der Variablen-Statistikwerte) eingesetzt wird. Meistens zeigt sich das schon beim Start des Scripts „read-DB“, welches einfach nicht mehr beendet wird. Und hier werden einfach „nur“ die Statistikdaten zu den geloggten Variablen ausgelesen: Aggregatiponstyp, first Record, last Record, #Records etc.

Ursache ist eine schon vorher korrupte DB. Dass viele User davon nichts bemerken, wundert mich auch nicht, da diese Fehler offensichtlich nur beim Zugriff auf die DB mit bestimmten IPS-Sytsembefehlen sichtbar wird (eben die Beiden oben genannten). Das sind aber auch Befehle, die im Allltag so gut wie niemand eindsetzen dürfte (ausser vielleicht mal eine händisch angestoßene Reaggregation über die Variableneigenschaften). Mit anderen Worten: der DB-Analyzer macht zwar derartige Fehler sichtbar, ist aber weder Ursache noch kann er diese beheben.

Über die Ursachen von korrupten IPS-Datenbanken kann ich nur mutmaßen, tippe aber stark auf abgeschossene IPS-Tasks (z.B. manuell, ließt man hier alle par Wochen, oder beim Reboot nach Windows-Update: hier wird IPS ebenfalls hart abgeschossen, das ist seit mind. 1 Jahr bekannt). Jetzt kann jeder mal für sich überlegen, wie oft ihm das schon passiert ist.

Seit dem der DB-Analyzer verfügbar ist, traten ca 6-8 (ca. 10% aller Nutzer) mir bekannte Fälle auf, bei denen ein solches Problem mit Einsatz des DB-Analyzers sichtbar wurde. In allen Fällen (soweit ich mich erinnere) stellte sich hinterher heraus, dass die DB korrupt war und via Repair-Tool (siehe dazu obige Links bzw. IPS-FDoku) repariert werden konnten.
Einzige Merkwürdigkeit hierbei: das Repairtool zeigt offensichtlich nicht jeden Defekt an. Man sollte im Zweifel also einen Repair-Job starten und sieht dann, ob tatsächlich Macken drin waren oder nicht.

Was mir zu Deinem aktuellen Problem fehlt, ist die exakte Transparenz, was Du in welcher Reihenfolge mit welchem Ergebnis gemacht hast.

was bedeutet z.B.

…somit werde ich jetzt mit der neuen DB schön darauf achten…
?

[ul]
[li]hast Du eine neue, leere DB erzeugt oder eine saubere im Backup finden können?[/li][li]wenn Letzteres: von wann war dieses Backup?[/li][li]Hattest Du überhaupt fehlerfreie DB-Backups?[/li][li]Wie sicherst Du deine Backups? -> im laufenden Betrieb oder wenn IPS-offline ist?[/li][li]was genau hast du beim ersten Einsatz des DB-Analyzers gestern gemacht und bei welchem Schritt hast du ein Problem bemerkt?[/li][li]Wie äusserte sich dies?[/li][/ul]

etc etc…

Nicht falsch verstehen: ich möchte hier nur mögliche Verunsicherungen -so weit vorhanden - eindämmen und Transparenz schaffen.