Häufig gestellte Frage
SMOdatabase ist sehr groß - Langsamer Zugriff auf Montiordaten
Zuletzt aktualisiert vor 8 Jahren
Beim Monitoring fallen sehr viele Daten an. Momentan werden diese Daten noch nicht automatisch abgeschnitten, da das Löschen recht lange dauert und das System nicht weiter verlangsamt werden sollte (Einlesen der Scans).
Dieses Verhalten führt dazu, dass die entsprechenden Tabellen immer voller werden, was sich sowohl auf den Speicherbedarf auch als auf die Performance negativ auswirkt.
Im Anhang befinden sich ein paar SQL-Scripte, welche die Monitordaten abschneiden.
Mit dem Skript <000_Count-ScanSoftwareMonitorPeriod.sql> kann man prüfen kann man prüfen, wie viele Datensätze abgeschnitten würden. (weiter Anmerkungen im Script).
Wenn man zum Schluss kommt das ein Abschneiden sinnvoll ist, dann muss man die Scripte 001-003 in dieser Reihenfolge abfeuern.
Da das Löschen der Ds unglaublich lange dauert, wird hier eine andere Strategie gewählt: die bisherige Tabelle wird umbenannt und es wird eine neue strukturgleiche Tabelle erstellt (001_MonitorDelete_Init.sql).
Dann werden alle Daten in die neue Tabelle kopiert, die erhalten bleiben sollen (002_MonitorDelete_CopyRelevantData.sql).
Als letztes wird die alte Tabelle gelöscht und für die neue noch die fehlenden Indexe erstellt (003_MonitorDelete_Finish.sql)
In der Regel ist es sinnvoll die Datenbank SMOdatabase nach dieser Aktion zu verkleinern, damit unnötiger Speicherplatz wieder freigegeben werden kann.
Dieses Verhalten führt dazu, dass die entsprechenden Tabellen immer voller werden, was sich sowohl auf den Speicherbedarf auch als auf die Performance negativ auswirkt.
Im Anhang befinden sich ein paar SQL-Scripte, welche die Monitordaten abschneiden.
Mit dem Skript <000_Count-ScanSoftwareMonitorPeriod.sql> kann man prüfen kann man prüfen, wie viele Datensätze abgeschnitten würden. (weiter Anmerkungen im Script).
Wenn man zum Schluss kommt das ein Abschneiden sinnvoll ist, dann muss man die Scripte 001-003 in dieser Reihenfolge abfeuern.
Da das Löschen der Ds unglaublich lange dauert, wird hier eine andere Strategie gewählt: die bisherige Tabelle wird umbenannt und es wird eine neue strukturgleiche Tabelle erstellt (001_MonitorDelete_Init.sql).
Dann werden alle Daten in die neue Tabelle kopiert, die erhalten bleiben sollen (002_MonitorDelete_CopyRelevantData.sql).
Als letztes wird die alte Tabelle gelöscht und für die neue noch die fehlenden Indexe erstellt (003_MonitorDelete_Finish.sql)
In der Regel ist es sinnvoll die Datenbank SMOdatabase nach dieser Aktion zu verkleinern, damit unnötiger Speicherplatz wieder freigegeben werden kann.