Wie kann man die SQL-Datenbank bei Sage 100 (Warenwirtschaft) verkleinern?

R

R. Diez

Neues Mitglied
Hallo alle:

Wir verwenden Sage 100 (Warenwirtschaft). Wenn man über die 10 GB Grenze ist, kann man den Microsoft SQL Server Express nicht mehr benutzen, und der SQL Server Standard kostet extra.

Man kann angeblich alte Geschäftsjahre wegwerfen, oder die Datenbank irgendwie aufteilen. Aber das sind keine schöne Lösungen.

Kann man stattdessen irgendwelche "unwichtige" Sachen löschen, um die Datenbank so klein wie möglich zu halten? Ich kenne mich nämlich mit Buchhaltung etc. nicht so gut aus.

Ich habe z. B. in diesem Forum gelesen, dass Angebote nicht steuerrelevant sind. Kann man so etwas mittlerweile automatisch löschen?

Es gab auch jemanden, der meinte, die Duplikation in KHKVKBelegeStuecklisten wäre eigentlich nicht nötig:
Aber auch hier gab es keine sofortige Lösung.

Ich habe auch gesehen, dass ein zweiter Mandant bei uns in der selben SQL-Datenbank liegt. Wenn ich einen Mandanten lösche, wird viel Datenbank-Platz freigegeben? Oder bleiben die Daten für Belegen usw. trotzdem erhalten? Kann man einen Mandant in eine andere SQL-Datenbank verschieben?

Danke im Voraus,
R. Diez
 
Wenn die Datenbank die Grenze von 10 GB erreicht sollte man überlegen ob nicht doch der SQL Server Standard sinn macht. Auch aufgrund von RAM-Nutzung etc.

Wie viele User arbeiten denn mit der Sage?

Ansonsten: Wenn man viele Geschäftsjahre hat (>10) könnte man die DB kopieren in eine Archiv-Datenbank und ein paar Geschäftsjahre löschen.

Auch ratsam: Mal mit SQL-Scripten prüfen welche Tabellen den meisten Speicher verbrauchen. Manchmal gibt es Tabellen (Protokoll-Tabellen von Anpassungen etc.) welche viel Speicher fressen und ggf. bereinigt werden könnten.
 
Erstmals danke für Ihre Rückmeldung.

Die Anzahl an Benutzern ist nicht konstant, und was sie alle machen ist mir noch nicht klar. Ich bin neu bei Sage und ich selbst bediene es kaum (ich bin in diesem Fall eher im Bereich EDV tätig). Aber die Anzahl an Benutzern ist wohl nicht wirklich ausschlaggebend. Ich schätze, es geht eher darum, wie viele neue Belege etc. pro Jahr erstellt werden.

Ich mache mir keine große Sorge über die SQL-Leistung, es geht eher um die Größe der Datenbank. Ich habe mal eine Liste aller Tabellen-Größen erstellt, und die Größten sind die Belegepositionen. Es ist aber schwer zu wissen, wo man etwas löschen könnte.

Bei diesen "Protokoll-Tabellen von Anpassungen", könnten Sie mir sagen, wie die heißen? Ein einziges Beispielname wäre schon hilfreich für die Weitersuche.

Gibt es in Sage kein Werkzeug, um solche Protokolle zu leeren?

Unsere Datenbank war über 9 GB groß bei OfficeLine, daher sind wir vom ursprünglich geplanten SQL Server Express auf SQL Server Standard umgestiegen.

Die Datenbank ist aber auf etwa 7 GB geschrumpft nach der Migration auf die neuste Sage 100 (die der Sage-Partner gemacht hat). Alle alten Daten sind anscheinend immer noch da, und die Anzahl an Elementen in den Tabellen ist vergleichbar. Es ist aber für mich schwer, wirklich zu wissen, ob etwas verloren gegangen ist. Es könnte auch sein, dass der neue SQL Server, oder die neue Datenbank Struktur, besser auf Platzverbrauch optimiert ist.

Bei der alten Datenbank gabe es ein paar Tabellen mit dem Wort "Archiv" im Namen, aber die hatte vergleichweise wenige Elemente.

Bei einer Größe von 7 GB schätze ich, wir könnten noch ein paar Jahre mit SQL Server Express leben. Aber die Geschwindigkeit des Zuwachses habe ich noch nicht gemessen.
 
Um die Tabellen mit dem höchstem Speicherverbrauch zu ermitteln, braucht es keine Skripts, Am einfachsten geht es mit dem SSMS. Rechtsklick auf die Datenbank - Berichte - Standardberichte - Datenträgerverwendung durch oberste Tabellen.

Wenn zwei Mandanten in derselben Datenbank liegen, kann man problemlos im sage Administrator eine neue Datenbank anlegen und alle Daten eines Mandanten in diese kopieren, danach den Mandanten in der alten Datenbank löschen. Der Platz wird aber erst freigegeben, wenn man die Datenbank im SSMS verkleinert. Ihre Fachhändler kann das für sie sicher erledigen. Dabei verdoppelt sich aber der Verwaltungsaufwand für Benutzeranlage und Berechtigung, weil das nun immer in zwei Datenbank erfolgen muss.

Außer dem Abschneiden von Geschäftsjahren, die mehr als 10 Jahre zurückliegen, gibt es keine "überflüssigen" Daten in der sage Datenbank.
 
Hallo R.Dietz,
es gab mal einen Bug zwischen Access und MS SQL Server, der dazu führte, das die Datenbanken sich "künstlich" aufgebläht haben. Man musste diese Datenbanken dann im OLAdmin kopieren und dann war diese um den Faktor 8-10 kleiner. Aber achtung: Bei Anpassungen durch Fachhändler kann es passieren, das diese Ihre Tabellen, Views, Felder nicht korrekt eingebunden haben und diese dann beim Kopieren "vergessen" werden.
Alternativ kann man auch mal schauen, wie die DB eingestellt ist - oftmals steht die Protokollierung auf "Standard" - dann hat man 1 GB an Daten und 7 GB an Protokoll wie die Daten modifiziert wurden.
Und wenn das alles nicht eintrifft, dann kann man sich per SQl anzeigen lassen, wo die großen Datenfragmente sind und dann überlegen, wie man diese reduziert. Sollte in einer Stunde erledigt sein
 
Erstmals danke für die Informationen.

Im Datenbank-Bericht sieht man nichts Besonders. Die größten Tabellen sind mit Abstand diejenigen, die mit Belegen und Lagerplatzbuchungen zu tun haben.

Man kann nicht direkt herausfinden, wie viel Platz der andere Mandant braucht. Ich frage in meiner Firma herum, ob die zusätzliche Arbeit sich lohnen würde.
 
> es gab mal einen Bug zwischen Access und MS SQL Server, der dazu führte, das die Datenbanken sich "künstlich" aufgebläht haben. Man musste diese Datenbanken dann im OLAdmin kopieren und dann war diese um den Faktor 8-10 kleiner.

Danke für den Hinweis, aber ich denke, ein solcher Fall hätte der Partner sicherlich gesehen. Gibt es irgendeinen Weg, herauszufinden, ob dieser Bug uns trifft? Ich denke z.B., wenn Tabelle X Elemente wie Y hat, dann ist das dieser bekannter Bug.

Ich habe mich schon gewundert, dass eine eine relativ kleine Firma so viele Gigabytes braucht, aber ich habe noch kein Gefühl, wie viele Daten ein Warenwirtschaftssystem aufbewahrt.

> Aber achtung: Bei Anpassungen durch Fachhändler kann es passieren, das diese Ihre Tabellen, Views, Felder nicht korrekt eingebunden haben und diese dann beim Kopieren "vergessen" werden.

Jetzt, dass Sie das erwähnen: Wir haben im alten Sage einige Views, die wir wohl nicht mehr brauchen. Die wurden vor Jahren gemacht durch andere Partner, vor meiner Zeit, damit man mit Excel irgendwelche Daten manuell holen konnte.

Das Problem ist, ich wüsste nicht, welche Views oder Tabellen standard in Sage sind, und welche maßgeschneidert / custom sind. Ich habe Angst, etwas Wichtiges zu löschen, daher habe ich es so gelassen. Oder gibt es irgendwo eine Tabelle, die auflistet, welche Tabellen oder Views der Benutzer selbst eingefügt hat?

Mit "Felder" meinen Sie wohl benutzer-definierte Felder. Man kann solche Felder im Sage Administrator separat sehen und verwalten bzw. löschen, richtig?


> Alternativ kann man auch mal schauen, wie die DB eingestellt ist - oftmals steht die Protokollierung auf "Standard"

Die Protokollierung ist auf "einfach" bzw "simple" gestellt. Daher sollte die Log-Datei nicht viel wachsen, wenn ich das richtig verstanden habe.

> Und wenn das alles nicht eintrifft, dann kann man sich per SQl anzeigen lassen, wo die großen Datenfragmente sind und dann überlegen, wie man diese reduziert. Sollte in einer Stunde erledigt sein

Das Problem ist das "überlegen, wie man diese reduziert". :cool:

Der unbenutzte Platz in der Datenbank ist nicht so groß, daher müsste man "unwichtige" Sachen löschen. Das ist der Grund, warum ich z.B. gefragt habe, ob man Angebote, die zu keinem Verkauf geführt haben, bedenkenlos löschen kann, und ggf. wie man das automatisieren könnte. Aber es sieht nicht so aus, dass es viel "fett" zum Wegwerfen wäre.
 
Wenn ich das jetzt alles richtig verstande habe, läuft die Installation auf einem SQL-Server und nicht mehr SQL-Express.

Warum ist denn so total wichtig, die Datenbank - die sowieso scheinbar nicht so groß ist - noch weiter zu verkleinern?

Das ist nicht "einfach mal so nebenbei" zu machen, sondern braucht neben kompletter Sicherung auch viel Know-How, um nicht wichtige Dinge zu löschen bzw. die Datenbank unbrauchbar zu machen.
Diesen großen Zeitaufwand würde ich mir sparen, da sich Kosten und Nutzen da kaum rechnen werden.

Warum der Aufwand?
 
> Wenn ich das jetzt alles richtig verstande habe, läuft die Installation auf einem SQL-Server und nicht mehr SQL-Express.

Ja. Unser Partner nennt das "SQL Server Standard".

> Warum ist denn so total wichtig, die Datenbank - die sowieso scheinbar nicht so groß ist - noch weiter zu verkleinern?

Ich habe nicht gesagt, dass es "total wichtig" ist. Ich zahle ja die Rechnung nicht selbst. :cool:

Mein Eindruck ist, dass Sage träge und teuer ist. Ich bin in der Regel kein Freund von der Cloud, aber ein SQL Server Standard Edition ist ziemlich teuer für eine relativ kleine Firma. Der SQL Server Standard, den wir in der Cloud nutzen, wird mit anderen Cloud-Kunden geteilt, was die Kosten drückt. Die genauen Preise habe ich aber nicht parat.

Man hat das Cloud-System nicht mehr so richtig in der Hand. Die Benutzer werden durch Remote Desktop leicht verwirrt. Etc.

Ich dachte auch, je kleiner die Datenbank, desto schneller könnte Sage werden. Aber mittlerweile denke ich, das wäre wohl nicht der Fall.

Wenn wir den SQL Server Express nutzen könnten, könnte man Sage lokal laufen lassen, wie früher. Dann könnten wir einen fetten Server lokal betreiben, der nicht mit anderen Kunden geteilt ist. Und wir wären nicht mehr abhängig von der Cloud. Ob das sich lohnt, ist aber auch nicht klar. Nachteile gibt es immer.

Wie ich schon sagte, die ursprüngliche Datenbank war über 9 GB groß, da stellte die Frage sich gar nicht. Aber bei 7 GB käme es in Frage. Mittlerweile weiß ich, dass es einen zweiten Mandanten gibt, den man auslagern könnte. Sollte es weitere Sparmöglichkeiten geben, dann könnte man einen Umzug in Betracht ziehen.

Und auch, wenn es sich nicht lohnen würde, bin ich sehr neugierig und will trotzdem alles wissen. :cool:
 
Es wird doch vermutlich einen Grund geben, warum der betreuende Partner das so vorgeschlagen hat und da wird es bestimmt auch einen Kosten-Nutzen-Abgleich gegeben haben.

Abgesehen davon: Auch wenn sich da verschiedne Kunden den Server teilen, die Lizenzkosten werden dadurch kaum weniger.

Bei einer "kleinen Firma" ist Cloud in der Tat oft nicht interessant, wenn nicht wenigstens ein paar außerhalb der LAN sitzen.
Da hat zumindest bei unseren Kunden bisher noch kein Vergleich der Kosten zur Cloud tendiert.

Aber "kleinen Firma" ist auch eine Ansichtssache.
Manche sage Klein ist 2-3 User, andere reden bei 15 User noch von klein.

Kann man so einfach nicht abschätzen und müsste wirklich detailiert besprochen werden.
Der betr. BP kann da bestimmt genaueres sagen.
 
R. Diez schrieb:
Und auch, wenn es sich nicht lohnen würde, bin ich sehr neugierig und will trotzdem alles wissen. :cool:
Zum Vergrößern anklicken....

Es macht sicherlich absolut Sinn auf dem SQL-Server automatisierte Datenbank-Wartungspläne anzulegen.
Das geht auf dem SQL-Server-Express nur sehr eingeschränklt bzw. bzw. nicht automatisiert.
Dazu gehört auch die Sicherung und Verkleinerung der LOG's. Lesestoff hierzu: https://ola.hallengren.com

Im Sage-Administrator kann man Sicherungen anlegen und danach auch mal eine Datenbankreorganisation durchführen lassen. Speziell die Installationen, auf SQL-Server-Express können davon etwas profitieren.

Meine Erfahrung ist aber, dass der SQL-Server in den meisen Fällen nichts für das "träge Verhalten" der Sage 100 kann.

Bei uns war es immer der Client bzw. Terminalserver und der Applikationsserver (oder eben die VM's auf der diese Funktionen laufen).

Hier hilft Energieeinstellung "Höchstleistung" - und maximaler Prozessor Basistakt + Turbotakt - deutlich jenseits der 3 GHz.
(weil die Sage noch immer eine 32Bit Anwendung im Access- Korsett ist)
Übermäßig viele Cores halfen hingegen nie - bzw. wirkten sich eher negativ aus.

Ich kenne Installationen in der Cloud auf Basis Proxmox und einer mir unbekannten Hardware, auf der mehrere Kunden "gehostet" werden (oftmals Terminalserver, App-Server und ein gemeinsamer SQL-Server) die auch ausreichend performant laufen.

Ich kenne auch All-In-One VM's zu Entwicklungszwecken auch auf Proxmox mit App-Server und SQL-Server auf der gleichen VM - die auch ausreichend performant laufen.

Wenn ich "ausreichend performant" sage, dann spreche ich als ungeduldiger Power-User, der täglich mit dem System Artikelpflege, Belegerstellung mit Audrucken etc. auf einer Produktivdatenbank mit Zusatzmodulen und ca. 15 - 20 angemeldeten "Normal-Usern etc. durchführt.
Ich spiele selten nur mit der Stehlampe und der Firma Arber auf der Demo-Datenbank von Sage herum.

Selbst auf meinem lokalen Rechner in einer VirtualBox läuft eine All-In-One Entwicklungsumgebung mit annehmbarer Geschwindigkeit ( Turbo-Takt >4 GHz)

Sage 100 9.0.8.5 ist auf unserem on premise Server mit EPYC 73F3 (virtualisiert mit Hyper-V) nicht super schnell - sondern ausreichend performant.

Ich beobachte aktuell die günstigen EPYC 4004 Prozessoren bzw. deren kommender Einsatz auf namhaften Serversystemen.
Ich vermute, dass auf z.B. einem EPYC 4584PX die Sage (Terminalserver und App-Server) ganz flott laufen kann.

Man bekommt die Sage mit einer vernünftigen Hardware tatsächlich zu einer "akzeptablen" Geschwindigkeit - "ausreichend performant" eben.

Das Thema Performance bleibt bei Sage auf jeden Fall spannend.
 
Zuletzt bearbeitet:
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben