Sage Altdaten - Datenbanken aufteilen per Partition oder Archivieren?

S

SPLH

Mitglied
Hi,
da wir 20 Jahre an Verkaufsdaten in Sage haben wird die Datenbank immer voller. Kann man diese per Partition aufteilen oder bringt das nichts? Oder lieber die Daten in eine Archivdatenbank umziehen?

Beispiel für's Partitionieren:
CREATE TABLE KHKVKBelegeP (BellId Int PRIMARY KEY, Mandant SmallInt, Belegkennzeichen varchar(3),... ) PARTITION BY RANGE (sale_date);

CREATE TABLE KHKVKBelege_2020 PARTITION OF sales FOR VALUES FROM ('2020-01-01') TO ('2021-01-01');
CREATE TABLE KHKVKBelege_2021 PARTITION OF sales FOR VALUES FROM ('2021-01-01') TO ('2022-01-01');
CREATE TABLE KHKVKBelege_2022 PARTITION OF sales FOR VALUES FROM ('2022-01-01') TO ('2023-01-01');
etc.
Danach die KHKVKBelege entfernen und KHKVKBelegeP in KHKVKBelege umbenennen.

Wie geht ihr mit Altdaten um?
 
Hallo,

ich habe keine Ahnung, ob das mit den Partitionen etwas bringt. Trotzdem würde ich davon abraten. Selbst wenn es heute funktioniert, wird es vielleicht mit irgendeinem zukünftigen Update Probleme geben.

Wenn unsere Kunden alte Geschäftsjahre auslagern wollen, bspw. weil ansonsten die Größe für den SQL Server Express überschritten wird, erstellen wir eine Datenbankkopie als Archiv. In der originalen Datenbank werden dann im Sage Administrator die alten Geschäftsjahre nacheinander gelöscht. Währenddessen sollte natürlich niemand an der Sage 100 angemeldet sein und je nach Datenbankgröße sollte man etwas mehr Zeit einplanen. Anschließend ggf. auch noch eine Datenbankreorganisation laufen lassen.
 
Hallo,

ich schließe mich Markus an - Partitionierung bei Range würde ich ebenfalls abraten.

Es ist eine sehr "spannende", jedoch eine sehr individuelle Frage - was will man am Ende erreichen? Z. B. einfach die Datenbankgröße verkleinern, Performance optimieren, etc..

* Für Datenbankgröße verkleinern z. B. wg. SQL Express hilft die Geschäftsjahre zu löschen + alte Logdaten z. B. "KHKLogbuch" zu "bereinigen"

* Zur Performanceoptimierung wirkt sich dagegen das Löschen der Geschäftsjahre nur sehr minimal aus.
- Hier sollte man die Bereinigung (inkl. Archivierung) der Logdateien z. B. KHKLogbuch in Erwägung ziehen;
- Fehlende Indexe überprüfen;
- Abfragen analysieren / optimieren
- Benutzer etwas "schulen" ;)
- Daten und Indexdaten auf unterschiedliche Platten aufteilen;
- Partitionierung der kompletten Tabelle sehr bewusst überlegen z. B. bei ca. 3.000 neuen Belegen am Arbeitstag hat geholfen die KHKVKBelege und KHKVKBelegePositionen auf unterschiedliche Filegroups (Platten) auszulagern;
- etc...

Beste Grüße
Sergej
 
Hallo,

ich denke nicht, dass die Datenbankgröße tatsächlich einen relevanten Einfluss auf die tägliche Arbeit mit der sage 100 hat. Der SQL Server ist ja dafür gemacht riesige Datenmengen zu verwalten. Die Performancegewinne in der Hard- und Software, die wir über die Jahre haben, dürften das jeweils locker kompensieren. Es ist meiner Erfahrung nach die Oberfläche der sage, die langsam ist, nicht das API und schon gar nicht der SQL Server. Wenn man mal sieht, wie eine einfache Aufgabencenterliste mehrere Belege (mit ein paar Positionen) pro Sekunde anlegt wenn sie die API aufruft, fragt man sich schon, was die Oberfläche da so trödelt.
Ich bin auch nicht sicher, ob sie wirklich 20 Jahre Daten in der sage 100 aufheben können, ohne ernsthaft gegen Vorschriften der DSGVO zu verstoßen. Nach 10 Jahren sollte man wirklich die Geschäftsjahre löschen. Fast niemand braucht die Daten aus 2003 - 2013 wirklich, um seinen Betrieb effizient zu steuern. Man trennt sich nur so wahnsinnig ungern von den alten Schätzchen. :)

Die ganzen Tipps, die Daten und Logs und Temps alle auf verschiedene Platten zu verstreuen, stammen alle aus Zeiten wo die tatsächlich auf verschiedenen physischen Platten zu liegen kamen. In heutigen Zeiten mit hoch virtualisierten Servern landen das eh alles auf dem selben Storage. Das bringt also auch nichts mehr.

Ich würde also auch, wie bereits vorgeschlagen, die Datenbank in ein Archivsystem zurück sichern, in der aktuellen alle Geschäftsjahre bis auf die letzten 10 löschen und dann die Archivdatenbank einfach mal nicht wieder in die sage einhängen und schauen, ob jemand wirklich die Daten vermisst.
 
So ein wenig muss ich dem Löschen widersprechen.

Zum Einen haben wir Kunden - vor Allem im Produktionsumfeld - die länger auf Daten zurückgreifen müssen.
Da werden schon manchmal noch Ersatzteile für >10 Jahr alte Maschinen benötigt.

Außerdem wichtig:
Soweit mir bekannt darf man Geschäftsjahre nicht direkt nach 10 Jahren löschen, sondern erst 10 Jahre nach Ende des Bilanzerstellungsjahres.
Das Bedeutet zB:
Wurde das Geschäftsjahr 2011 erst verspätet in 2013 bilanziert, dann zählt für 2011 der 31.12.2013 als Aufbewahrungsfrist. Löschbar dann also erst frühestens ab 2014.
 
Ja, wir nutzen VM Maschinen und als Platte haben wir NVMe drives mit 7100 MB/s (Read) / 3700 MB/s (Write) Geschwindigkeiten. Da macht das Aufteilen der Daten auf unterschiedliche Platten glaube ich wenig Sinn. Abfragen in SSMS sind sehr schnell, aber Sage braucht halt schon ne Weile um z.B. die Verkaufsbelegauskunft zu laden. Hatte gehofft das wir hier performance upgrades bekommen könnten durch das reduzieren der Beleganzahl um ca. 30%.
Es scheint egal wie schnell die Server sind, oder wie schnell die Clients, Sage ist und bleibt einfach 'langsam' bis 32bit Access nicht mehr benötigt wird? Sage in einigen Ländern ist browser basiert und da ist es richtig schnell. Maybe one day auch in Deutschland - hier ist die aktuelle Cloud Lösung ja eher ein Witz.
:)
 
Moin,

einfach im Administrator mit der rechten Maustaste auf den Mandanten klicken, der letzte Menüpunkt vor den Eigenschaften bietet das Löschen des jeweils ältesten Geschäftsjahres an.
 
Danke an @KMoeser für den wichtigen Hinweis auf die Aufbewahrungspflichten.
Ich glaube aber nicht, das dass Argument "Ich brauche/will die Daten aber" im Rahmen der DSGVO zieht. Wenn diese Firma vor 15 Jahren mal ein Angebot an einen Einzelunternehmer für eine Maschine gestellt hat, welches nicht zu einem Auftrag geführt hat, ist dieser Mensch auch mit seinen Privatdaten in der Datenbank enthalten. Dieser Mensch hat sehr wohl einen Anspruch auf die Löschung. Ohne das Löschen der Geschäftsjahre kann ich aber solche Kunde überhaupt nicht löschen.
Eine DSGVO konforme Löschung oder hilfsweise Anonymisierung dieser Kundendaten bietet die sage 100 aber leider im Standard nicht an.
Vielleicht hat sich ja dazu mal ein Partner Gedanken gemacht und eine Lösung erstellt.
 
Bezüglich DSGVO gebe ich @planB völlig Recht.
Das hat Sage so nicht.

Aber da hilft das Löschen der alten geschäftsjahre nix, da das Angebot ja auch von vor 2 Jahren sein könnte und das Löschen verlangt wird.
Da Angebote nicht steuerrelevant sind, müssten wir es löschen können.
Ist zum Glück - zumindest bei uns - noch nie gefragt worden, da eine richtige Lösung gäbe es "out of ne Box" glaube ich nicht.
 
Ein paar Gedanken zum Thema Partitionierung, Performance etc:

Das eine Datenbank mit der Zeit immer größer wird, stellt, sofern der Storage richtig dimensioniert ist, kein Problem dar.
Eine Partitionierung macht meines Erachtens immer nur dann sinn, wenn wir mit Datenbankgrößen von hunderten Gigabytes unterwegs sind.

SQL Server Partitionen sind aus Sage Sicht kein Gamebreaker, machen aber nur sinn, wenn wirklich extrem hohes Belegaufkommen mit sehr vielen Positionen stattfindet. Selbst dann macht eine Partitionierung nur Sinn, wenn Abfragen nur einen bestimmten Datenbereich benötigen (meistens Auswertungen und kostspielige Select Statments).

Für eine erfolgreiche Partitionierung muss zunächst festgestellt werden, welche Tabellen am größten sind und man muss sich Gedanken darüber machen, welchen Datenbereich man auslagern möchte. Der Storage, auf den Partitionen ausgelagert werden sollen muss immer zur Verfügung stehen und Online sein. Das heißt, entweder ein zusätzliches Raid Array (was langsamere Platten haben darf als der Host) oder eine weitere virtuelle Festplatte. Keinesfalls jedoch Netzlaufwerke, NAS-Speicher oder ähnliches, was vom SQL Server getrennt sein könnte.

Eine Partitionierung betrachtet immer nur einen zuvor fest definierten Datenbereich. Bei Jahreswechsel oder auch nach einiger Zeit (je nach Datenwachstum) muss das Partitionsschema von Hand angepasst werden, oder man automatisiert dieses via Script. Stackoverflow bietet hier ein paar gute Referenzimplementierungen.

Bevor ich jedoch anfange zu partitionieren, sollte ich mir meine Datenbank über den Tag einmal betrachten und schauen, was denn da tatsächlich am längsten dauert. Ein kaum bekanntes Feature dazu ist der Abfragespeicher
Diesen gilt es zunächst für die zu überwachende Datenbank zu aktivieren (rechtsklick auf die DB im SQL Server Management Studio und dann Eigenschaften). Dann den Betriebsmodus auf Lesen/Schreiben stellen und der DB ein paar Tage zeit lassen, Daten zu sammeln.
1692711456566.png

Danach stehen unter der Datenbank im Bereich Abfragespeicher großartige Standardauswertungen zur Verfügung
1692711555185.png

Diese liefern tatsächlich auch gleich noch entsprechende Indexoptimierungsratschläge mit
1692711613402.png

Mehr Indizes bedeuten gleichermaßen ein weiteres Wachstum der reinen Datenbankdateien. Hier muss ich natürlich immer abwägen, jedoch darf über den Daumen gesagt der Indexspeicher ruhig halb so groß sein wir die eigentliche Datenbank. Muss ich natürlich zehntausende Belegpositionen im Batch einfügen und das immer wieder, so sind viele Indizes auf der Belegpositionstabelle eher kontraproduktiv. Man sieht, es ist immer von der jeweiligen Arbeitslast und Anwendung abhängig.

Ein Wort noch zum Thema Aufteilung von DB, TempDB und log auf mehrere Datenträger. Hier muss ich meinem Vorredner wiedersprechen. Es ist richtig, dass wir heute meistens alle Daten eh auf virtuellen Festplatten lagern und diese einem globalen Physischen Storage unterliegen. Jedoch hat jeder Datenträger (also auch jede virtuelle HDD) seine eigene Warteschlange, die vom Betriebssystem abgearbeitet wird. Diese Abarbeitungen finden immer seriell statt und daher ist es aus SQL-Performance-Sicht durchaus ein Unterschied, wenn ich Data, Logs und Tempdb auf drei unterschiedlichen Laufwerken liegen habe. Nur so haben ich unterschiedliche Warteschlangen die dann tatsächlich auch parallel abgearbeitet werden können.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben