Faqs

Alle Projekte auf Raketenschnecke.net sind ab 2013 mit einem Update-Info Modul ausgestattet. Ist eine neuere Version des Projekts verfügbar, wird eine Info über das WFE eingeblendet. Ausnahme: der Project Exporter hat keine WFE-Visualisierung, daher werden hier die Update-Informationen im Script-Meldungsfenster ausgegeben. Diese Info verschwindet nach einem erfolgreichen Update.

Versions- und Update-Infos werden immer über einen Blog-Artikel veröffentlicht, der mit der Projekt-Homepage verlinkt ist.

Der DB-Analyzer ist defaultmäßig so konfiguriert, dass er innerhalb der ersten 10 Minuten nach Mitternacht läuft. Hierbei werden nicht nur die Logging-Zeiträume der Variablen aufgeräumt (sofern in den variablen Vorhaltezeiträume definiert wurden), es werden auch Statistik-Daten erhoben, die ohne den täglichen Lauf nicht ermittelbar sind. Das sind im Wesentlichen die Zuwächse der Datenbestände pro Variable. 

Da auch der Datenzuwachs pro Tag ermittelt wird, ist es wichtig, dass der DB-Analyzer möglichst exakt zum selben Zeitpunkt läuft, da anderenfalls nicht korrekte Zuwachsraten pro Tag gemessen werden.

Lässt man den DB-Analyzer nun in unregelmäßigen/größeren Zeitabständen laufen,  ist eine Analyse der Datenbestände und Zuwächse kaum möglich bzw. wird es hier zu falschen Schlussfolgerungen kommen. Soweit man das in Kauf nehmen kann/will, kann der DB-Analyzer auch in unregelmäßigen/größeren Zeitabständen laufen (was aber ausdrücklich nicht empfohlen wird und auch nicht im Sinne des Projekts ist).

Keine Angst, Du bist nicht blind! Die Downloads sind (seit 16.11.2014) nur registrierten Usern zugänglich ;-)

F: Bei mir läuft der DB-Analyzer sehr lange (Script „read DB“),  IPS ist während dieser Zeit wie blockiert, DeathThreads tauchen auf. Woran liegt das, was kann ich tun?

A: Die Abfrage der Datensatz-Informationen aus der IPS-DB ist ziemlich Ressourcenhungrig. Bei einer intakten DB sollte das aber dennoch kein Problem sein.
Bei mir dauert eine Abfrage (Script „read DB“) ziemlich stabil zwischen 10-12 Sekunden. Ich habe ca 240 geloggte Variablen, die DB ist genau 2 Jahre als und beinhaltet aktuell 9,7 Mio Datensätze. Der Server ist ein i5 mit SSD’s und 8GB RAM.
Es kommt bei mir (selten) mal vor, dass die Abfrage 60 Sekunden läuft. Der Grund ist mir nicht transparent. Aus diesem Grunde habe ich die Laufzeit bei mir sehr großzügig eingestellt, um hier nicht auf einen Fehler zu laufen.
In den Fällen, wo das Script wirklich eine Blockade des IPS und DeathThreads zur Folge hat (bisher sind mir 4 Fälle bekannt, 3 davon wurden gelöst, im 4. Fall ist mir der Status nicht bekannt), war das immer auf eine korrupte DB zurück zu führen. Es empfielt sich hier, einen DB-Scan bzw. einen Repair-Versuch (keine Reaggregation!) zu starten: Anleitung DB-Reparatur auf der IP-Symcon-Seite.

Hinweis: Das Prüfungsergebnis der Db durch die genannten Tools ist leider nicht verlässlich! Auch fehlerfrei gemeldete Datenbanken verursachten Fehler im Betrieb, welche erst nach einem  tatsächlichen Reparaturlauf beseitigt wurden.

F (aus IPS-Forendiskussion):

Wir haben hier ja schon oft diskutiert das dies in einer SQLite ja eigentlich Blödsinn ist, da die Daten nur als gelöscht markiert aber nicht physisch gelöscht werden. Die Filegröße bleibt gleich.
Ist das bei deiner Löschfunktion auch so, oder reorganisierst du die Datenbank hinterher ?
Macht es also Sinn für die Behaltezeiten einzupflegen, oder ist das nur Makulatur – in Bezug auf Filegröße ?

A: Also: Blödsinn ist das m.E. nicht. zwar wird das File nicht kleiner (was durch es reagggregieren übrigens auch nicht wird), dazu müsste man IPS runterfahren und manuell verdichten.

Der Vorteil ist schon gegeben, da der durch gelöschte Daten eingesparte File-Space anschließend mit neuen Datensätzen aufgefüllt wird. d.h. dein File wächst solange nicht, bis die vor dem Löschen erreichte Anzahl von Datensätzen wieder erreicht ist. Und hier spielt der DB-Analyzer einen richtigen Vorteil aus: durch das tägliche Löschen ereicht man, dass das File so klein wie möglich bleibt (und nicht in der Größe oszilliert, wenn man alle paar Monate man. löschen + verdichten würde).

sehr gut zu sehen ist das hier:  RS.SYS-Health (Chart ganz unten)

vielleicht noch ein Nachtrag, um den Vorteil des zyklischen Löschens zu verdeutlichen:
würde man alle Variablen mit einer Vorhaltezeit definieren, dann täglich alle Daten (die nicht in diesem Zeitraum liegen) löschen, würde das DB-File nicht mehr wachsen. Seine Größe bliebe konstant. Natürlich nur unter der -rein theoretischen- Annahme, dass das tägliche Datensatz-Aufkommen absolut konstant ist.