Nicht mehr benötigte Daten löschen

Hallo zusammen

Ich habe die Aufgabe gefasst, eine Kundendatenbank in der Grösse zu reduzieren. Die DB hat im Moment eine Grösse von rund 50GB. Die laufende Zunahme ist sehr gross, so dass der Wunsch aufgekommen ist, periodisch nicht mehr benötigte Jahre einzeln aus der DB zu entfernen. Das heisst, für ein bestimmtes Jahr sollen alle Bewegungsdaten aus dem System entfernt werden, sodass es nach einer solchen Reorganisation einfach aussieht, als hätte man ein Jahr später mit dem System zu arbeiten begonnen.

- Hat jemand diesbezüglich schon Erfahrungen gemacht (vor allem negative)?
- Spricht etwas dagegen, über die Eingrenzung mittels Buchungsdatum alle Datensätze zu entfernen (Postentabellen, gebuchte Rechnungen, etc, etc.)

Bin für jeden Tip, Hinweis oder jede Warnung dankbar.

Hi,

hehe, was verstehst du unter 'nicht benötigten Daten'?
Die Funktion, die du suchst, nennt sich 'Datumskomprimierung' und arbeitet da recht effektiv.

Das mit den Posten löschen hab ich jetzt mal überlesen....
Was werden denn dazu die Wirtschaftsprüfer sagen?

[EDIT]
Oha, ich seh grad, es geht um eine 2.x Version, die sind ja fast älter als ich :)
Da weiss ich gar nicht 100%, ob es die Funktion da auch gibt.

Gruss, Otschko

>>Oha, ich seh grad, es geht um eine 2.x Version, die sind ja fast älter >>als ich :)
>>Da weiss ich gar nicht 100%, ob es die Funktion da auch gibt.

Doch die gibt es da.
Löschen sollte man die Posten sicher nicht, aber komprimieren kann man sie.
Was man löschen kann, sind die gebuchten Belege, wenn sie mind. einmal gedruckt worden sind (Anzahl gedruckt <> 0).
Das einzige Problem welches hier entsteht, ist halt dass man die Detailinformationen zu diesen Belegen verliert.
Sind es denn wirklich die Tabellen 32, 110,111 usw. die so extrem viel Platz brauchen, oder sind es vielleicht Tabellen die man selber implementiert hat. Diese, eigenen Tabellen, werden sehr oft unterschätzt.

Gruss

Ja, es sind schon die Tabellen 112 und 113. Da sind über 10 Mio. Datensätze drin. Tabelle 32 hat 5 Mio. Zeilen. Dazu kommen dann natürlich noch diverse weitere Tabellen, welche ebenfalls über viele Datensätze verfügen.

Dann würde ich an Deiner Stelle die Tabellen der gebuchten Verkaufsbelege (110,111,112,113,114,115) einmal löschen.
Wie gesagt, eben nur die Belege, die gedruckt sind.
Die Posten würde ich nicht unbedingt komprieren, sonst sind halt die meisten Statistiken für die Katz, da der Detailierungsgrad fehlt.

>>rund 50GB.
Noch ein Frage: NativeDB oder SQL?

Gruss

Noch ein Frage: NativeDB oder SQL?

Hier ist eine NativeDB im Einsatz. Die DB ist aufgeteilt auf 6 Partitionen, rsp. 6 Festplatten (welche wiederum gespiegelt sind)

Die Posten würde ich nicht unbedingt komprieren, sonst sind halt die meisten Statistiken für die Katz, da der Detailierungsgrad fehlt.

Das ist ein guter Hinweis. Vielen Dank.

>>Hier ist eine NativeDB im Einsatz. Die DB ist aufgeteilt auf 6 >>Partitionen, rsp. 6 Festplatten (welche wiederum gespiegelt sind)

Cool
50 GB ist doch der Beweis, dass die Native-DB eben doch ein tolles Ding ist und auch mit grossen Datenbanken keine Probleme hat.
Seit Microsoft reden ja alle nur noch vom SQL-Server.
Ich bin nach wie vor ein Fan der Native-DB

Da gebe ich Dir vollkommen recht. Etwas stabileres und einfacheres in der Handhabung als die NativeDB von Navision habe ich noch nicht gerade gesehen. Dazu kommt, dass SQL seinen Preis hat (was ja der Grund sein dürfte, dass MS lieber den SQL-Server verkauft)

Die DB hatte übrigens bereits einmal die Grösse von gut 70GB. Wir haben dann mal aufgeräumt (Migrationsdaten, Protokolleinträge in eigenen Tabellen, Schnittstellentabellen usw.)

>>Da gebe ich Dir vollkommen recht. Etwas stabileres und einfacheres in >>der Handhabung als die NativeDB von Navision habe ich noch nicht >>gerade gesehen.

Balsam ))

Die Native-DB kann noch erheblich mehr an Größe verkraften, max. 256 GB sind lizenzierbar.
Posten dürfen niemals einfach gelöscht werden, da der Saldo aller Posten den Bestand ergibt, egal ob das ein Artikel, ein Sachkonto usw. ist. Es werden zur Berechnung mit der SIFT immer alle Posten benötigt. Lediglich ein Komprimieren ( mehrere aufsummieren und einen neuen erzeugen, danach die Einzelposten löschen) ist zulässig.
Alte Rechnungen sollten nur gelöscht werden, wenn Sicherungen der Datenbank existieren, wo diese noch enthalten sind. Unbedingt vorher mit dem Wirtschaftsprüfer/ Steuerprüfer abstimmen.
Auf externen Festplatten können problemlos Datenbanken aufgebaut werden, die dann in Bedarfsfall zur Kontrolle oder zum Nachdrucken von alten Rechnungen genutzt werden können.

Unbedingt vorher mit dem Wirtschaftsprüfer/ Steuerprüfer abstimmen. Auf externen Festplatten können problemlos Datenbanken aufgebaut werden, die dann in Bedarfsfall zur Kontrolle oder zum Nachdrucken von alten Rechnungen genutzt werden können.

Das ist auf jeden Fall klar. Die Aufbewahrungspflicht muss eingehalten werden, da gebe ich dir recht. Es ist deshalb auch ein Auslagern der Daten geplant (Rechnungsnachdruck etc.)

kurze frage mal dazu,

wir haben eine sql datenbank und würden auch gerne die älteren jahre auslagern, aber so, dass man jederzeit zugreifen kann und rechungen reproduzieren kann.
gibt es da sowas wie ein anleitung bzw. mittlerweile erfahrungswerte?

LG
Nadine

Wir haben nach sorgfältiger Analyse und abwägen von Kosten/Nutzen darauf verzichtet, diese Auslagerung umzusetzen. Es birgt einfach zu viele Risiken (Inkonsistenzen, rechtliche Probleme, etc.).

Ich kann also keine Erfahrungswerte weitergeben.

...also bleibt nichts anderes übrig, als die hardware "aufzustocken" um die performance bei wachsenden datenbestand zu verbessern?