Inaktiv tArtikelHistory Tabelle sehr groß

[edv-werl]

Moin zusammen,
wir fragen uns seit geraumer Zeit warum unsere Datensicherung immer größer wird mittlerweile sind wir bei über 25GB pro Sicherung. Daher habe wir uns die Tabellengrößen in der Datenbank angeschaut und festegestellt, dass die dbo.tArtikelHistory Tabelle dezente 15,4 GB belegt. Das sind 68 Millionen Zeilen.

Wie kommt das zustande? Wir haben 252k Artikel in der tArtikel Tabelle. Und wir fahren täglich ein Update, welches automatisch die aktualisierungen der Großhändler übernimmt.

Eine Ursache konnten wir aber bisher nicht genau ausmachen bzw. abstellen. Hat dazu einer einen Hinweis / Idee / Lösung.

Danke!

 

[Xantiva]

Sorgt nicht jede Bestandsänderung automatisch für einen Eintrag in der Tabelle?

Angenommen bei den 252k Artikel gibt es täglich eine Differenz im Bestand, dann schaffst Du:
68.000.000 / 252.000 = 269,8

die 68 Millionen in 270 Tagen, oder?

 

[edv-werl]

Ja ist korrekt. Allerdings nicht Ziel führend.
Wir haben jetzt erstmal händisch alles rausgenommen, was die Ameise anlegt. Hat soweit keine Probleme verursacht...
DELETE TOP (5000000)
FROM [eazybusiness].[dbo].[tArtikelHistory]
WHERE [kBuchungsart] = 80
Das Statement muss halt mehrfach ausgeführt werden...

 

[ag-websolutions.de]

Viele Artikel, häufige Aktualisierung = große History

Ich verstehe jetzt nicht wieso der Hinweis von @Xantiva nicht Zielfernrohr ist

Ansonsten kennt die WaWi auch eine Datenbankbereinigung

 

[DIE E-COMMERCE AGENTUR]

Ich hatte das gleiche Problem.

Durch einen 4x täglichen Ameisen-Import mit 30.000 Artikeln für Preise und Bestandsänderung hat sich die SQL Express Datenbank innerhalb von 3-4 Monaten von 3,5 GB auf knapp 10 GB vergrößert.
Eine Upgrade auf SQL Standard mit knapp 1000 Euro war mir in Moment zu viel Geld, vor allem wenn es einen für mich akzeptablen Workarround gibt.

Auf Grund dieses Forumeintrages habe ich mir auch die tArtikelHistory angeschaut und den "Übertäter" damit identifiziert. Die Tabelle hatte alleine schon über 6,0 GB an Daten.
Mit Hilfe von verschiedenen SQL Scripten und dem SQL Management Studio habe ich diese Datenbank Tabelle verkleinert.

Bei einer Rückfrage beim JTL Support gab es die Empfehlung die Daten nicht zu löschen um eventuell die Artikelstatistik nicht zu zerstören oder zu beeinflussen. Das Risiko wollte ich allerdings eingehen.

Nach dem Löschen der Daten aus der tArtikelHistory hatte ich keine Probleme und mit einer reduzierten Größe auf ca. 4 GB auch wieder eine funktionierende Datenbank.

Geholfen haben mir folgende SQL Scripts:

--- Löscht die TOP 500000 Datensätze der tArtikelHistory bis zu einem bestimmten Datum mit der kBuchungsart = 80 ----
(kBuchungsart = 80 ist der Import über die Ameise)

DELETE TOP (500000)
FROM [eazybusiness].[dbo].[tArtikelHistory]
WHERE [dGebucht] < CONVERT(DATETIME,'30.09.2018')
AND [kBuchungsart] = 80

--- Zeigt die Größe einzelner Tabellen an ---

SELECT
t.NAME AS TableName,
s.Name AS SchemaName,
p.rows AS RowCounts,
SUM(a.total_pages) * 8 AS TotalSpaceKB,
SUM(a.used_pages) * 8 AS UsedSpaceKB,
(SUM(a.total_pages) - SUM(a.used_pages)) * 8 AS UnusedSpaceKB
FROM
sys.tables t
INNER JOIN
sys.indexes i ON t.OBJECT_ID = i.object_id
INNER JOIN
sys.partitions p ON i.object_id = p.OBJECT_ID AND i.index_id = p.index_id
INNER JOIN
sys.allocation_units a ON p.partition_id = a.container_id
LEFT OUTER JOIN
sys.schemas s ON t.schema_id = s.schema_id
WHERE
t.NAME NOT LIKE 'dt%'
AND t.is_ms_shipped = 0
AND i.OBJECT_ID > 255
GROUP BY
t.Name, s.Name, p.Rows
ORDER BY
TotalSpaceKB DESC


---- Größe der DB ---

USE [eazybusiness]
GO
EXEC sp_spaceused