Aufgeblähte DB bereinigen (dbo.POS_Bon) - Welches Vorgehen ist empfehlenswert?

[WhiteRabbit-CGS]

Hallo,

durch Einbindung eines Logos auf unserem Kassenbon haben wir unwissentlich unsere Datenbankgröße aufgebläht. So sind seit November 2019 in der Tabelle dbo.POS_Bon gut 50 GB aufgelaufen.



Irgendwo in den Spalten cData, CData2 und CData3 schlummern da die Bilder vor sich hin - das möchten/müssen wir nun ändern.

Zu folgenden Optionen neigen wir:
1.) Löschen aller Bons bis zum Zeitstempel 2026-01-01 ODER
2.) Leeren der dem Logo zuzuordnenden Spalte.

Die partielle Bereinigung der Bons durch Option 2 wäre uns lieber. Allerdings wissen wir nicht in welcher der Spalten die Logos tatsächlich liegen und ob die Spalten gesperrt sind.

Die Löschung der BOns würden wir über MS SQL Server Management Studio durchführen (DELETE TOP (1234567) FROM [Mandant_1].[dbo].[POS_Bon]).

Anmerkungen:
- Das Logo wurde inzwischen vom Bon entfernt.
- Ein Backup aller Bons bzw. der kompletten Datenbank wird mehrfach gesichert vorgehalten. So würden wir bei Option 1 für Rechtssicherheit sorgen - denken wir zumindest.
- Sämtliche empfohlenen Wartungs- und Optimierungsarbeiten an der DB wurden in der DB-Verwaltung von JTL durchgeführt - ohne Auswirkung auf die Größe der DB.

Fragen:
1.) Ist seitens des Kassen- (aktuelle Version von LS-POS) bzw. WAWI-Betriebs (aktuell JTL WAWI 1.10.15.0) mit Problemen zu rechnen wenn wir die Bons bis zum 01.01.2026 löschen (Falls wir Option 1 wählen)?
2.) Weiß jemand ob wir durch die (mehrfache) Ablage des Backups rechtssicher bleiben was die Aufbewahrung der Bons angeht (bei Option 1 bzw. 2)?
3.) Ist bekannt welcher Spalte die Logos liegen?
4.) Übersehen wir erforderliche Nacharbeiten an der DB im Zusammenhang mit der Löschung? Re-Indizierung z.B.?

Für Hilfestellungen wären wir sehr dankbar!

Mit besten Grüßen,
Heiner Michels

 

[swissguy01]

Hallo,

durch Einbindung eines Logos auf unserem Kassenbon haben wir unwissentlich unsere Datenbankgröße aufgebläht. So sind seit November 2019 in der Tabelle dbo.POS_Bon gut 50 GB aufgelaufen.

Den Anhang 131390 betrachten

Irgendwo in den Spalten cData, CData2 und CData3 schlummern da die Bilder vor sich hin - das möchten/müssen wir nun ändern.

Zu folgenden Optionen neigen wir:
1.) Löschen aller Bons bis zum Zeitstempel 2026-01-01 ODER
2.) Leeren der dem Logo zuzuordnenden Spalte.

Die partielle Bereinigung der Bons durch Option 2 wäre uns lieber. Allerdings wissen wir nicht in welcher der Spalten die Logos tatsächlich liegen und ob die Spalten gesperrt sind.

Die Löschung der BOns würden wir über MS SQL Server Management Studio durchführen (DELETE TOP (1234567) FROM [Mandant_1].[dbo].[POS_Bon]).

Anmerkungen:
- Das Logo wurde inzwischen vom Bon entfernt.
- Ein Backup aller Bons bzw. der kompletten Datenbank wird mehrfach gesichert vorgehalten. So würden wir bei Option 1 für Rechtssicherheit sorgen - denken wir zumindest.
- Sämtliche empfohlenen Wartungs- und Optimierungsarbeiten an der DB wurden in der DB-Verwaltung von JTL durchgeführt - ohne Auswirkung auf die Größe der DB.

Fragen:
1.) Ist seitens des Kassen- (aktuelle Version von LS-POS) bzw. WAWI-Betriebs (aktuell JTL WAWI 1.10.15.0) mit Problemen zu rechnen wenn wir die Bons bis zum 01.01.2026 löschen (Falls wir Option 1 wählen)?
2.) Weiß jemand ob wir durch die (mehrfache) Ablage des Backups rechtssicher bleiben was die Aufbewahrung der Bons angeht (bei Option 1 bzw. 2)?
3.) Ist bekannt welcher Spalte die Logos liegen?
4.) Übersehen wir erforderliche Nacharbeiten an der DB im Zusammenhang mit der Löschung? Re-Indizierung z.B.?

Für Hilfestellungen wären wir sehr dankbar!

Mit besten Grüßen,
Heiner Michels

Hallo Heiner

Ja, wir haben das gleiche Problem. Gut 30% der DB-Speicher ist nur für POS_Bon und wächst weiter.

Hatte aus diesem Grund Luwosoft-Support angefragt, hier die Antwort:

Hallo Herr Stoni,

es handelt sich hierbei um die Tabelle für Kassenbons. Diese enthält neben den Bonsummen auch die Rohdaten des gedruckten Bons, d. h. die Druckvorlage mit ausgefüllten Variablen. Wenn auf dem Bon Bilder wie z. B. ein Logo enthalten sind, ist auch dieses enthalten. Das bedeutet, je größer das Logo, desto höher der Speicherverbrauch pro Bon. Deshalb empfehlen wir, das Logo so klein wie möglich zu halten. Alternativ kann man auch die Logo-Druck-Funktion des Druckers verwenden, um Platz zu sparen: https://www.luwosoft-support.de/382423-FlexBon-Im-Drucker-gespeichertes-Logo-verwenden . Außerdem enthält die Tabelle auch für jeden Bon eine Signatur, um Manipulation der Einträge zu verhindern. Diese belegt pro Bon auch ein wenig Speicher im niedrigen kB-Bereich.

Sofern Sie SQL Server Express nutzen, können Sie entweder auf SQL Server Standard wechseln oder ein Update auf SQL Server 2025 Express in Betracht ziehen. Da hat Microsoft die Größe der Datenbank auf 50 GB erhöht.

Möglich wäre auch, die Datenbank zu sichern und ältere Einträge zu löschen, um Speicherplatz freizugeben.

Mit freundlichen Grüßen,

Ich weiss es klärt nicht all Deine Fragen, aber zumindest die Option 1) müsste technisch gehen.

Frage doch mal Luwosoft-Support an, ob sie eine Antwort zu Deinen Punkten haben. Würde uns auch helfen.

Gruss Armin

 

[WhiteRabbit-CGS]

Hallo Heiner

Ja, wir haben das gleiche Problem. Gut 30% der DB-Speicher ist nur für POS_Bon und wächst weiter.

Hatte aus diesem Grund Luwosoft-Support angefragt, hier die Antwort:

Hallo Herr Stoni,

es handelt sich hierbei um die Tabelle für Kassenbons. Diese enthält neben den Bonsummen auch die Rohdaten des gedruckten Bons, d. h. die Druckvorlage mit ausgefüllten Variablen. Wenn auf dem Bon Bilder wie z. B. ein Logo enthalten sind, ist auch dieses enthalten. Das bedeutet, je größer das Logo, desto höher der Speicherverbrauch pro Bon. Deshalb empfehlen wir, das Logo so klein wie möglich zu halten. Alternativ kann man auch die Logo-Druck-Funktion des Druckers verwenden, um Platz zu sparen: https://www.luwosoft-support.de/382423-FlexBon-Im-Drucker-gespeichertes-Logo-verwenden . Außerdem enthält die Tabelle auch für jeden Bon eine Signatur, um Manipulation der Einträge zu verhindern. Diese belegt pro Bon auch ein wenig Speicher im niedrigen kB-Bereich.

Sofern Sie SQL Server Express nutzen, können Sie entweder auf SQL Server Standard wechseln oder ein Update auf SQL Server 2025 Express in Betracht ziehen. Da hat Microsoft die Größe der Datenbank auf 50 GB erhöht.

Möglich wäre auch, die Datenbank zu sichern und ältere Einträge zu löschen, um Speicherplatz freizugeben.

Mit freundlichen Grüßen,

Ich weiss es klärt nicht all Deine Fragen, aber zumindest die Option 1) müsste technisch gehen.

Frage doch mal Luwosoft-Support an, ob sie eine Antwort zu Deinen Punkten haben. Würde uns auch helfen.

Gruss Armin

Hallo Armin,

danke für die Infos. Shcike gleich die Anfrage an Luwosoft raus udn melde mich dann wieder wenn wir etwas hören.

VG,
Heiner

 

[WhiteRabbit-CGS]

Wir haben folgende Antwort von Luwosoft bekommen:

Hallo Herr Michels,

bitte klären Sie derartige Schritte am besten vorab mit Ihrer Steuerberatung und dokumentieren Sie diese.

Solange Sie die Datenbank aus einem Backup wiederherstellen können, um Bons und ggfs. damit verknüpfte Daten im Falle einer Prüfung auslesen zu können, sollte es kein Problem sein, diese aus der Datenbank zu entfernen. Wichtig ist, dass die Wiederherstellung in einer eigenen Datenbank erfolgen muss, damit nicht die Produktivdatenbank überschrieben wird. Bei Prüfungen der vergangenen 5 Jahre werden in der Regel die TSE-Daten geprüft, was aber nicht bedeutet, dass die Daten der Bons bedeutungslos sind.

Wenn Sie nur die cData-Felder entfernen, werden die Bons im Bonjournal weiterhin aufgelistet, sind aber nicht mehr nachdruckbar. Im Ergebnis müssen Sie auch hier die Datenbank wiederherstellen, wenn Sie die Bons nachdrucken oder Daten für eine Prüfung exportieren wollen.

Allgemein wäre es bei beiden Optionen evtl. sinnvoll, nicht gleich alle Daten bis 31.12.2025 zu löschen, sondern z. B. bis 31.12.2024, um zumindest auf Bons vom letzten Jahr zugreifen zu können.

Mit freundlichen Grüßen,
Florian Schneider

Bitte geben Sie bei allen Supportanfragen die Versionsnummern von LS-POS, JTL-Wawi und die verwendete Windows-Version an.

 

[WhiteRabbit-CGS]

Damit lässt sich, finde ich, gut arbeiten. Danke an den Luwosoft-Support!

Aktuell sind wir dabei, die Bons zu löschen. Ein paar Infos dazu, falls es mal jemanden ähnlich geht:

• Vor Beginn der Löschung wurde die DB exportiert, komprimiert und mehrfach archiviert (2x USB-Stick, 2x externe HDD, 1x Cloud).
• Ebenfalls vor der Löschung wurden Shop und DB getrennt, Worker deaktiviert und JTL-Zugänge deaktiviert um ungestört arbeiten zu können.
• Zum Löschen haben uns für 10.000er Blöcke entschieden, um ein besseres Gefühl für den Prozess entwickeln zu können.
• Vor Absenden eines Delete SQL-Queries schauen wir uns kurz die ersten 10 Zeilen an um zu verstehen welchen Zeitstempel wir als nächstes treffen.
• Auf unserem Server dauert das Löschen von 10.000 Zeilen in dieser Tabelle ca. 3 Minuten.
• Die SQL-Queries hängen hier an.
• Nach Abschluss der Löschung wird die DB in der JTL Datenbank-Verwaltung bereinigt/indexiert.

Nächstes Update: Größe der Tabelle nach Abschluss der Arbeiten

 

[WhiteRabbit-CGS]

Gelöschte Bons: 200.000
Gelöschter Zeitraum: November 2019 bis Dezember 2024
Tabellen-Größe vor Löschung: ca. 50 GB
Tabellen-Größe nach Löschung: ca. 20 GB
Gesamte Dauer der Arbeiten: Ca. 45 Minuten

Nennenswerte Beobachtungen:

• Die Dauer eines Löschvorgangs schwankte bei gleicher Anzahl zu löschender Zeilen zwischen 2:30 und 5 Minuten. Wir nutzen einen Shared Server, eventuell liegt es daran.
• Wir greifen per RDP auf den Server zu. Manchmal friert die Verbindung ein, was dann beunruhigend wirkt. Schließen und Öffnen der RDP-Verbindung hilft.

In beiden Fällen heißt es: Ruhe bewahren, passt schon.

 

[WhiteRabbit-CGS]

Abschließende Infos zu dieser Phase:

• Die Performanceoptimierung der DB via JTL Datenbankverwaltung hing im Schritt "Indizes neu organisieren und neu erstellen" fest. Nach ca. 6 Stunden ist sie dann letztlich abgestürzt. Inwiefern auch das mit dem Shared Server zutun hatte lässt sich nicht sagen. Auslastung von CPU und RAM waren jedenfalls so hoch, dass das Sytem ordentlich gestottert hat.
  
  Hier die Fehlermeldung aus dem Errorlog:
  
  

  Unbehandelte Ausnahme #5B9567768D187DDD vom Typ System.Runtime.InteropServices.COMException in Void SyncFlush()
  System.Runtime.InteropServices.COMException (0x88980406): UCEERR_RENDERTHREADFAILURE (Ausnahme von HRESULT: 0x88980406)
     bei System.Windows.Media.Composition.DUCE.Channel.SyncFlush()
     bei System.Windows.Interop.HwndTarget.UpdateWindowSettings(Boolean enableRenderTarget, Nullable`1 channelSet)
     bei System.Windows.Interop.HwndTarget.UpdateWindowPos(IntPtr lParam)
     bei System.Windows.Interop.HwndTarget.HandleMessage(WindowMessage msg, IntPtr wparam, IntPtr lparam)
     bei System.Windows.Interop.HwndSource.HwndTargetFilterMessage(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
     bei MS.Win32.HwndWrapper.WndProc(IntPtr hwnd, Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
     bei MS.Win32.HwndSubclass.DispatcherCallbackOperation(Object o)
     bei System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs)
     bei System.Windows.Threading.ExceptionWrapper.TryCatchWhen(Object source, Delegate callback, Object args, Int32 numArgs, Delegate catchHandler)
  System.Object = <null>
  
  Zeitstempel: 2026-05-03T18:37:29
  Locale: German (Germany)
  Locale: German (Germany)
  Version: 1.10.15
  Plattform: WMS
  WawiSeed: DBToolStarter
  Prozessname: JTL-Datenbankverwaltung
  Physikalischer Speicher: 190271488 / Peak: 374558720
  Basispriorität: 8
  Prioritätsklasse: Normal
  CPU-Zeit (User): 1:52:59,0625
  CPU-Zeit (System): 0:35:26,453125
  Page-Size (Sytem): 1271520 / Peak: 339644416
  Page-Size: 133066752 / Peak: 339644416
  Offene Handles: 1227
  Database:
  Build: 2510161205 ad624e4890d9d4c285e9fec84107b45393b1a121

  
  
• Hätte den Fehler gerne weiter recherchiert und verstanden, aber da die Öffnung des Ladens anstand haben wir uns entschieden, zunächst darauf und auf einen neuen Anlauf für die Neuorganisierung der Indizes zu verzichten.
• Wir haben dann den BEtrieb aufgenommen. Login und Nutzung sind seit dem unauffällig.

Jetzt schauen wir mal wie der Betrieb läuft und melden uns dann in 10.000 Bons oder so wieder...