Issue angelegt eazybusiness Datenbank bläht sich seit 1.5.42.0 stark auf ... Tabelle "tKunde_suche" im Verdacht

[wawi-dl]

Hallo,

seit wir die 1.5.42.0 aufgesetzt haben, verzeichnen wir eine stark wachsende Datenbank.

Durch Analyse haben wir ermittelt, dass die Tabelle "tKunde_suche" enorm viel Speicher frisst, wirft man ein Blick hinein weis man auch warum.

In der Tabelle werden die Daten eines Kundenstammes in jede erdenkliche Such-Variante kombiniert, mit und ohne Sonderzeichen/Bindestriche/Punkte usw. usw.
So werden aus einer Straßenangabe "Muster-Str. 4A" schnell mal fast ein Dutzend Zeilen, nur damit man den Kunden findet??? Kann man dies nicht eleganter lösen?

Bedeutet bei unserem Test mit 200.000 Kundenstämme, dass JTL dafür in "tKunde_suche" alles zusammenkombiniert zu 3.200.000 Zeilen (400MB)!!! --> Faktor 15-16
Was soll das? Ich will nicht wissen was das Speicher kostet, wenn man 500.000 Kunden im System hat.



Bitte an JTL das Problem zu optimieren, danke.

 

[wawi-dl]

Siehe auch hier:
https://forum.jtl-software.de/threa...ne-bestand-einfach-loeschen.97931/post-548720

 

[Xantiva]

Ups, danke für den Hinweis. Wenn ich mal schaue, wie viele Einträge es pro Kunde geben kann:

SELECT TOP (1000) [kKunde], COUNT([kKunde]) as Anzahl
  FROM [eazybusiness].[dbo].[tKunde_suche]
  GROUP BY [kKunde]
  ORDER BY Anzahl DESC

Dann sind das die Top 10:

kKunde    Anzahl
13987    1140
14101    668
10480    661
13479    661
20716    576
12458    537
9055     526
9517     515
10369    513
8770     487

1.140 Einträge in der Tabelle für einen einzigen Kunden?

Hier mal ein Auszug der anoymisierten Daten, alle Einträge auch noch doppelt (unterschiedliche nId):
Xxxxxx-Yyyyyyyyyyyy e. Kreisdekanat
Xxxxxx-Yyyyyyyyyyyy e. Kreisdekanat
Xxxxxx-Yyyyyyyyyyyy e. Yyyyyyyyyyyy
Xxxxxx-Yyyyyyyyyyyy e. Yyyyyyyyyyyy
Xxxxxx-Yyyyyyyyyyyy e. V.
Xxxxxx-Yyyyyyyyyyyy e. V.
Xxxxxx-Yyyyyyyyyyyy für Xxxxxx
Xxxxxx-Yyyyyyyyyyyy für Xxxxxx
Xxxxxx-Yyyyyyyyyyyy für Caritasverband
Xxxxxx-Yyyyyyyyyyyy für Caritasverband
Xxxxxx-Yyyyyyyyyyyy für das
Xxxxxx-Yyyyyyyyyyyy für das
Xxxxxx-Yyyyyyyyyyyy für e.
Xxxxxx-Yyyyyyyyyyyy für e.
Xxxxxx-Yyyyyyyyyyyy für Kreisdekanat
Xxxxxx-Yyyyyyyyyyyy für Kreisdekanat
Xxxxxx-Yyyyyyyyyyyy für Yyyyyyyyyyyy
Xxxxxx-Yyyyyyyyyyyy für Yyyyyyyyyyyy
Xxxxxx-Yyyyyyyyyyyy für V.
Xxxxxx-Yyyyyyyyyyyy für V.
Xxxxxx-Yyyyyyyyyyyy Kreisdekanat Xxxxxx
Xxxxxx-Yyyyyyyyyyyy Kreisdekanat Xxxxxx
Xxxxxx-Yyyyyyyyyyyy Kreisdekanat Caritasverband
Xxxxxx-Yyyyyyyyyyyy Kreisdekanat Caritasverband
Xxxxxx-Yyyyyyyyyyyy Kreisdekanat das
Xxxxxx-Yyyyyyyyyyyy Kreisdekanat das
Xxxxxx-Yyyyyyyyyyyy Kreisdekanat e.
Xxxxxx-Yyyyyyyyyyyy Kreisdekanat e.
Xxxxxx-Yyyyyyyyyyyy Kreisdekanat für
Xxxxxx-Yyyyyyyyyyyy Kreisdekanat für

 

[Gökhan Basoglu]

Hallo @wawi-dl,

ich habe für das Problem eine Feature Ticket angelegt. Hier der Link zum Ticket:
https://issues.jtl-software.de/issues/WAWI-55094

 

[Xantiva]

JTL hat das Ticket abgewiesen.

Man braucht unbedingt so viele Einträge um den einen Kunden schnell zu finden ...

 

[wawi-dl]

@Gökhan Basoglu
Abweisung des Tickets finde ich schwach, man sollte zumindest am Ende Duplikate löschen, danke.

 

[gnarx]

Ich würde erstmal prüfen was so gross ist in der DB mit dem Management Studio. Man klickt dazu auf der eazybusiness DB per rechten Mausklick auf Berichte -> Standardberichte -> Datenträgerverwendung durch oberste Tabellen.
Bei uns war es nach einem Update eine DBerrLog die voll gelaufen war. Außerdem hatten wir ein Backup versucht in dem man die Kundendaten ausklammert was schief gegangen war dadurch hatten wir auf einmal 2 DB`s für die Wawi drinne.
Im Anhang kann man sehen wie das aussehen kann. Bei uns ist das Templatezeugs gross das werde ich bereinigen in dem ich das ganze aus kommentierte von JTL rausnehme.

Unsere DB ist momentan 24 GB groß bei 170.000 Artikeln und 100.000 Kunden

 

[Gökhan Basoglu]

Das Ticket wurde von der Entwicklungsabteilung abgewiesen, ich werde das Problem aber noch einmal an das Team herantragen.

 

[wawi-dl]

Zumindest sinnfreie Einträge und Dupletten muss man löschen, das macht alles ja zusätzlich performanter!
Das Ticket abzuweisen war für uns unschön ... davon hat jeder einen Mehrwert.

Sollte es für die Zukunft 1.6 eine neue Lösung geben, dann muss man dies ja nur kommunizieren und alles ist gut.

 

[wawi-dl]

@Gökhan Basoglu
Also seit wir die 1.5.42.0 drauf haben, bläht sich unsere Datenbank in 1-2 Monaten so schnell auf, wie seither in einem ganzen Jahr.
Bitte prüfen, es ist unnötig!

Mit der 1.6 werden sicherlich noch mehr Daten erhoben, bin gespannt wie rasant dann die DB wächst!

Kann doch nicht sein, dass die Kundensuche so viel Speicherplatz einnimmt?!

 

[SebiW]

Spätestens in der 1.5.45.1 gibt es wohl auch ein Problem mit der Tabelle DBErrorlog.

Hat bei uns in Zusammenhang mit einem Drittanbietertool die Log Datei eines Mandante über Nacht auf 160 GB hochgeschossen und damit die DB des betroffenen Mandanten knirschend zum Stillstand gebracht.

Ich hab für unsere 5 DBs bei derzeit 50 GB gesamt 240 GB Platten drin - da hat selbst dieser fünffache Spielraum nicht mehr gelangt

JTL war auf unserem Server und hat eine Änderung an der dafür verantwortlichen SP durchgeführt. Der Fehler war bei JTL im Vorfeld auch schon bekannt, war also kein großer Aufwand.

Falls Ihr also ähnliches beobachten könnt (einfach zu sehen an der Größe der Log Dateien oder der Tabelle DBErrorlog) -> macht ein Ticket bei JTL auf.

 

[wawi-dl]

Danke dir für die Info, wir werten die Tabellen regelmäßig aus und sehen welche Tabellen ungewöhnlich wachsen.

Ohje ... sehr erfreulich zu lesen ..

 

[gnarx]

Spätestens in der 1.5.45.1 gibt es wohl auch ein Problem mit der Tabelle DBErrorlog.

Hat bei uns in Zusammenhang mit einem Drittanbietertool die Log Datei eines Mandante über Nacht auf 160 GB hochgeschossen und damit die DB des betroffenen Mandanten knirschend zum Stillstand gebracht.

Ich hab für unsere 5 DBs bei derzeit 50 GB gesamt 240 GB Platten drin - da hat selbst dieser fünffache Spielraum nicht mehr gelangt

JTL war auf unserem Server und hat eine Änderung an der dafür verantwortlichen SP durchgeführt. Der Fehler war bei JTL im Vorfeld auch schon bekannt, war also kein großer Aufwand.

Falls Ihr also ähnliches beobachten könnt (einfach zu sehen an der Größe der Log Dateien oder der Tabelle DBErrorlog) -> macht ein Ticket bei JTL auf.

Hast du dir die SQL gespeichert? Ich hatte die nur leider durch ein älteres Rechner Backup verloren.
Einmal kann man die ja mit Truncate leer machen und einmal hatten die uns ein SQL gegeben um das ganze zu verhindern.

@SebiW hast du das immer noch mit der 1.5.45.1, bei uns ist es mit der Version noch nicht wieder aufgetaucht.

 

[SebiW]

Hast du dir die SQL gespeichert? Ich hatte die nur leider durch ein älteres Rechner Backup verloren.
Einmal kann man die ja mit Truncate leer machen und einmal hatten die uns ein SQL gegeben um das ganze zu verhindern.

@SebiW hast du das immer noch mit der 1.5.45.1, bei uns ist es mit der Version noch nicht wieder aufgetaucht.

Das ist bei mir tatsächlich erst in der 1.5.45.1 aufgetaucht. War vorher auf der 1.5.41.1, da gabs keine Probleme. War keine große Sache, musste nur was auskommentiert werden, komme aber gerad nicht an die DB um nachzuschauen was.

 

[IT-WEFA]

wurde hier was noch angepasst. unsere Sucher hat 3GB!