Datenlogger mit MSSQL und Index-Fragmentierung

[HolgerX]

Hmm..

Oder nach dem Delete ein ALTER INDEX ALL auf die Tabelle.

https://learn.microsoft.com/de-de/sq...l-server-ver17

Einfaches Syntaxbeispiel

ALTER INDEX index1 ON table1 REBUILD;
ALTER INDEX ALL ON table1 REBUILD;
ALTER INDEX ALL ON dbo.table1 REBUILD;

[BigAl]

Zitat von HolgerX:

Hmm..

Oder nach dem Delete ein ALTER INDEX ALL auf die Tabelle.

https://learn.microsoft.com/de-de/sq...l-server-ver17

Einfaches Syntaxbeispiel

ALTER INDEX index1 ON table1 REBUILD;
ALTER INDEX ALL ON table1 REBUILD;
ALTER INDEX ALL ON dbo.table1 REBUILD;

Ein REBUILD blockiert die Tabelle relative lange (aktuell ca. 1,5 bis 2 Minuten). Evtl. ein REORGANIZE, welches auch relativ lange benötigt, aber das Schreiben und Lesen weiterhin zulässt. Ob es aber zielführend ist das in kurzen Intervallen auszuführen ist fraglich...

[MyRealName]

Alte Datensätze müssen doch nicht jede Minute geprüft und gecheckt werden (es sollten 60 sein). Mach es einmal am Tag, am Besten zu einer Zeit, wo Du ohne Probleme auch den Index wieder herrichten kannst. Nachts um 2 zum Bsp.

[BigAl]

Zitat von MyRealName:

Alte Datensätze müssen doch nicht jede Minute geprüft und gecheckt werden (es sollten 60 sein). Mach es einmal am Tag, am Besten zu einer Zeit, wo Du ohne Probleme auch den Index wieder herrichten kannst. Nachts um 2 zum Bsp.

Naja. Einmal pro Minute max. 100 Datensätze löschen hat nicht wirklich Einfluss auf die Performance. Einmal pro Stunde müsste ich dann schon > 3600 alte Datensätze löschen. Das geht dann auch wieder zu Lasten des transaction-log-Files...

Nachts ist keine gute Idee. Dann lieber zu einer Zeit zu der die Ingenieure greifbar sind. Sonst gibt es nachts Anrufe

[MyRealName]

Bei 7.7 mio DS zu jeder Zeit in der DB machen 3600 DS nichts aus, zumal es indiziert ist. Und selbst 24*3600 DS macht da nicht viel aus. Es geht ja auch nicht ums Löschen, sondern um den Index neu bauen. Mach das 1x pro Tag zu einer ruhigen Stunde. Weil Dir geht es ja eh nur um den Speicherplatz, der Index funktioniert ja korrekt auch nach dem Löschen.

[Bernhard Geyer]

evtl. anderes DBMS nehmen?
z.B. ein PostgreSQL welche einen Mechanismus hat automatisch immer wieder indizes zu defragmentieren hat, so das hier das evtl. gar nicht auffällt wenn das passiert.

[Uwe Raabe]

Nur mal so ein wenig out-of-the-box gedacht:

Was wäre wenn du alle Datensätze im Voraus anlegst, diese nach aufsteigender ID per UPDATE befüllst und wenn du beim letzten angekommen bist wieder mit dem ersten weitermachst (ein Ringbuffer halt). In einer separaten Tabelle führst du ID und LogTime des ältesten und neuesten Satzes mit.

Da ja (nach 90 Tagen) für jede Sekunde ein LogTime NOT NULL -Datensatz vorhanden ist, kannst du unter Berücksichtigung des Überlaufs für jede Sekunde die ID bestimmen. Den Index auf LogTime brauchst du nicht mehr und der für ID ändert sich nicht, da beim UPDATE die ID gleich bleibt.

Abfragen nach Zeiträumen errechnen die WHERE Klausel für die entsprechenden ID Werte (in den ersten 90 Tagen noch mit LogTime NOT NULL ) und die Sortierung läuft über ein ORDER BY LogTime .

Das müsste man sicher noch im Detail ausarbeiten, aber es wäre zumindest ein interessanter Ansatz.

[BigAl]

Zitat von Uwe Raabe:

Nur mal so ein wenig out-of-the-box gedacht:

Was wäre wenn du alle Datensätze im Voraus anlegst, diese nach aufsteigender ID per UPDATE befüllst und wenn du beim letzten angekommen bist wieder mit dem ersten weitermachst (ein Ringbuffer halt). In einer separaten Tabelle führst du ID und LogTime des ältesten und neuesten Satzes mit.

Da ja (nach 90 Tagen) für jede Sekunde ein LogTime NOT NULL -Datensatz vorhanden ist, kannst du unter Berücksichtigung des Überlaufs für jede Sekunde die ID bestimmen. Den Index auf LogTime brauchst du nicht mehr und der für ID ändert sich nicht, da beim UPDATE die ID gleich bleibt.

Abfragen nach Zeiträumen errechnen die WHERE Klausel für die entsprechenden ID Werte (in den ersten 90 Tagen noch mit LogTime NOT NULL ) und die Sortierung läuft über ein ORDER BY LogTime .

Das müsste man sicher noch im Detail ausarbeiten, aber es wäre zumindest ein interessanter Ansatz.

Hallo Uwe

Ich bin immer wieder begeistert von Deiner Denkweise. Genau so ein Ansatz ist mir im Kopf herumgeschwirrt. Das könnte funktionieren, wenn da auch mit einer kleinen Hürden für die ich noch keine Lösung habe:

Aktuell speichere ich einen NULL-Datensatz ab, der mir eine Unterbrechung der Aufzeichnung markiert. Wird die Anlage also mal abgeschaltet, dann kann ich damit die Lücke im Graph entsprechend visualisieren:

20250717-101538-dbForge Studio for SQL Server.png

Wie ich diesen "Sprung" in der vordefinierten Tabell festhalten soll weiß ich momentan noch nicht. Eine Idee wäre eine Spalte wie "NextID" neben der "ID" einzuführen. Diese speichert dann den jeweils nächsten gültigen Index. Die Sprünge müsste ich dann halt mit meiner Software herausfiltern. Da ich in der Anzeige maximal zwei Stunden pro Seite ausgebe wäre das bei 7200 Datensätzen nicht die Welt...

Ich werde aber auf jeden Fall diesen Ansatz weiter verfolgen.

Danke!

[Uwe Raabe]

Die Logik aus einem sekundengenauen Datum eine ID zu berechnen erfordert allerdings genau einen Datensatz für jede Sekunde. Eine solche Unterbrechung würde dann eben auch durch mehrere Null-Sätze in der Tabelle hinterlegt werden. Ob du das dann als einen Eintrag anzeigst bleibt dir ja dann immer noch offen.