Datev-Datenbanken beliebig groß werden lassen oder besser entrümpeln / verteilen / begrenzen / archivieren ?

[#1]

Hallo @Datev-Community, hallo @Datev,

aus  gegebenem Anlass stelle ich mal die o.g. Frage in den 'Raum', ob man die Datev-Datenbanken beliebig groß werden lässt oder ob es Strategien gibt, um die Datenbankgrößen in 'vernünftigen' Grenzen zu halten.

Konkretes Beispiel:

Wir nutzen in unserem Datev-OnPremises-Client-Server-Netzwerk als Haupt-Speicherplatz-Verbraucher die "Dokumentenablage" (nicht revisionssicher), "Kanzlei-Rechnungswesen", "Eigenorganisation Comfort"

... wobei sich die Datev-Anwendungen das Gesamt-Datenbankvolumen (laut den BAK-Dateien der SQL-Online-Sicherung) wie folgt 'brüderlich' teilen:

• Dokumentenablage etwa 75 %
• IRW-Datenbanken etwa 15 %
• der gesamte Rest  etwa 10%

Das sieht für mich nicht 'gesund' aus, sondern eher wie ein Vulkan, in dem sich die Magma  ansammelt, hochsteigt und ihn irgendwann 'ausbrechen' (hier: 'zusammenbrechen') lässt

Ich sehe in den immer größer werdenden Datenbanken die Gefahr, ...

• dass die Sicherung der kompletten Datev-Umgebung immer zeitaufwändiger und technisch komplizierter und teurer wird
• dass defekte große Datenbanken auch einen großen Datenverlust mit sich bringen können, falls sie nicht reparierbar sind

Daher die Kernfrage:

Macht es Sinn, große bzw. übergroße Datenbanken ...

• auf kleinere Datenbanken zu verteilen (z.B. mit mehreren Datev-Datenpfaden oder mit anderen 'Tricks')
• zu "entrümpeln", indem man z.B. in der Dokumentenablage nach überflüssigen Datenmengen fahndet und sie entsorgt
  (vielleicht meinen manche MA, die Dokumentenablage sei ein Wertstoffhof oder eine  Mülldeponie)
• veraltete Daten in eine Art 'Altarchiv' auslagert, um sie nicht täglich mitsichern zu müssen
• mit Methoden zu verkleinern, die mir bisher noch nicht in den Sinn gekommen sind 😎

[#2]

SQL Datenbanken können beim 2017er SQL Express max. 10GB groß werden; beim Standard bis zu 524 PB (Petabyte). 

[#3]

... die 10 GB sind weit, weit überschritten und die 524 PetaByte will ich mir höchstens als eine Zahl mit vielen Nullen auf einem Blatt Papier oder in einer Excel-Tabelle ansehen 😉

[#4]

Nachtrag:

ganz allgemein scheint man sich bei der Datev relativ wenig Gedanken darüber zu machen, wie man die gesammelten Daten-Mengen irgendwann mal wieder löschen bzw. entsorgen kann 

.. und falls löschbar, dann sollte der Löschprozess auch intuitiv verstehbar und bedienbar sein und nicht in eine Sisyphos-(Straf-)Arbeit ausarten

[#5]

Löschen geht.. das ".. und falls löschbar, dann sollte der Löschprozess auch intuitiv verstehbar und bedienbar sein und nicht in eine Sisyphos-(Straf-)Arbeit ausarten" wird es höchstens erst 2030 - 2040 geben, wenn alles in der Cloud liegt und eine "Basis" hat.

Vermutlich dann ähnlich wie der Löschvorgang im Arbeitsplatz..

[#6]

---

@vogtsburger  schrieb:

... die 10 GB sind weit, weit überschritten und die 524 PetaByte will ich mir höchstens als eine Zahl mit vielen Nullen auf einem Blatt Papier oder in einer Excel-Tabelle ansehen 😉

---

Geht auch kürzer: 524 * 10^15

[#7]

Auf ihrem Konto würden sich bei der Anzahl Nullen freuen 🤣

[#8]

... da man sich hier mit Empfehlungen nicht 'aus dem Fenster lehnen will', frage ich mal ein wenig direkter nach:

... wäre denn eine Aufteilung von übergroßen SQL-Datenbanken in 'niedliche' Portionen von max 10 GB eine gute Idee ...

... oder sollte man die 'Datenbanken' einfach wachsen lassen, so lange es (gut) geht ?

[#9]

---

@bodensee  schrieb:

Auf ihrem Konto würden sich bei der Anzahl Nullen freuen 🤣

---

Wäre dann "Petadär" die richtige Bezeichnung?

[#10]

---

@vogtsburger  schrieb:

... wäre denn eine Aufteilung von übergroßen SQL-Datenbanken in 'niedliche' Portionen von max 10 GB eine gute Idee ...

---

NEIN!

[#11]

---

@bodensee  schrieb:

Auf ihrem Konto würden sich bei der Anzahl Nullen freuen 🤣

---

... man müsste erst mal wissen, unter/mit welchen Vorzeichen diese Zahl dort steht 😎

[#12]

@siro, danke für die unmissverständliche und ausführliche Antwort

... sogar diese 4 Buchstaben könnte man noch in voller Länge zitieren, wenn man den starken Impuls  danach verspürt 😎

[#13]

Moin,

grundsätzlich haben wir es erst einmal mit einer Standard-Einstellung für SQL-Datenbanken zu tun. 

1. Allokiert der SQL-Server für eine Datenbank Speicher auf der Festplatte, um einer Fragmentierung vorzukommen. 

2. Wenn der allokierte DB-Speicher sich dem Ende näher (DB voll), werden 10% der bestehenden DB-Größe erneut allokiert.

Daraus folgend: 

Wenn Sie nun Daten in der Datenbank löschen und auch in der Anwendung den Papierkorb leeren, bleibt die Datenbankgröße erhalten. Der allokierte Speicher wird also auf der Festplatte nicht freigegeben.

Ob es Sinn macht hier Datenbanken aufzuteilen um ggf. den Festplattenspeicher optimaler zu nutzen, da z.B. nur noch Nutzdaten auf Platte A und Altdaten auf Platte B sind, muß wohl von Umgebung zu Umgebung entschieden werden. 

Aus Sicht der Datensicherung sollte es eigentlich auch kein Problem darstellen. Die Sicherung erfolgt in den meisten Fällen via SnapShot. Das bekommt kein Anwender mit. Das anschließende kopieren des SnapShots ist dann eine Frage des Plattenstapel/-durchsatzes. 

Im Bereich Rechnungswesen könnte ich mir ein Auslagern von Altbeständen auf einen anderen Datenbankpfad vorstellen, wobei ich hier eher ein Fan von Löschen bin (Übergabe der Daten an Mandanten vorausgesetzt... oder an übernehmenden StB, etc.).

Bei der Dokumentenablage/DMS macht es wohl eher keinen oder weniger Sinn. Und was "aufgeräumt" oder "umgeräumt" wurde, wird durch scannen, etc. schnell wieder belegt... 

Im DMS (damals classic) wurden die Datencontainer zum Schluss auch automatisch angelegt, da diese im Regelfall schnell wieder gefüllt waren. 

Spannender wird irgendwann die Frage, wie wir den gesamten Kram in die Cloud bekommen... aber dorthin ist noch ein langer Weg... 

Ach so: Von den Möglichkeiten im SQL-Manager wie "DB verkleinern" oder "DB komprimieren" = FINGER WEG!!! Damit können Sie auch zuverlässig eine Datenbank schrotten... Diese Funktionen immer nur im Supportfall und wenn es gar nicht mehr anders geht!

Zudem sich der SQL-Server dann ganz schnell berufen fühlt, die verkleinerte DB wieder anzupassen und neuen Speicher zu allokieren... Ist also quasi sinnfrei... 

Beste Grüße
Christian Ockenfels

[#14]

@chrisocki ,

vielen Dank für den ausführlichen und technisch begründeten Kommentar

Ich sehe die Daten-Volumen-Probleme eigentlich (noch) nicht im Bereich Rechnungswesen, dem zweithungrigsten "Mitesser" am Tisch

der "hungrigste Vielfraß" am Tisch ist die "Dokumentenablage" und dort liegen ja ausgerechnet Unmengen von Dokumenten, die schon mit dem Zeitpunkt des Abspeicherns zu altern beginnen 

... und garantiert noch jede Menge an Müll (in IT-Sprech "Garbage")

Meine Idee: 

• die Dokumentenablage nach überflüssigem 'Speicherfressern' durchsuchen und diese entsorgen
• die Dokumentenablage nach veralteten Dokumenten durchsuchen und diese in ein Altarchiv auslagern, das nicht täglich mitgesichert werden muss
• die Mitarbeiter darauf 'einschwören', dass nicht jeder Mist in die Dokumentenablage geschoben wird (nach dem Motto: "aus den Augen, aus dem Sinn")

Nachtrag:

bei uns/bei mir hat sich die tägliche SQL-Online-Prüfung und -Sicherung und die tägliche Offline-Sicherung der kompletten Datev-Daten (weniger als 100 GB) bewährt und diese Datenmengen sind (noch) gut zu 'händeln'.

Ich habe nicht den Ehrgeiz, in den TerraByte-Bereich vorzustoßen.

Wenn sich der Berg an Daten aber immer weiter vergrößert, muss Einiges an Hard-und Software umgestellt werden.

Die IT-Partner haben sicher Spaß am Bestellen, Liefern, Aufrüsten, Umrüsten, Tunen, Migrieren und anderen 'hoheitlichen' und hochpreisigen Tätigkeiten.

Vielleicht reicht ja schon ein schlaueres Ablage- und Sicherungskonzept, um die 'Vermüllung' der Ressourcen zu vermeiden

[#15]

---

@vogtsburger schrieb:  der "hungrigste Vielfraß" am Tisch ist die "Dokumentenablage" und dort liegen ja ausgerechnet Unmengen von Dokumenten, die schon mit dem Zeitpunkt des Abspeicherns zu altern beginnen 

---

Nun ja, das liegt in der Natur der Dinge... Viele Kanzleien gehen sowohl der Papierablage als auch bei der digitalen Ablage nach dem Motto: "lieber haben als brauchen"... 

Das führt dann zu Unmengen Papier im Keller oder zu einem Dateienhort in der DokAblage/DMS....

Was ich keiner Kanzlei raten würde, ist die Belegablage in der DokAblage/DMS.  Insbesondere bei der Trennung von Mandanten kommen dann viele Handgriffe, die keiner haben möchte. Die Fibubelege würde ich immer in Belege online parken. Und ja, DSL & Co. ist in DE nicht immer gut ausgebaut..., Ausfälle gibt es auch, ist mir alles bekannt... dennoch lautet meine Empfehlung "Belege online".

Zudem gilt hier auch die Mitarbeiterbelehrung im Bezug auf die Qualität der Scans. Es macht keinen Sinn ein Dokument in Vollfarbe bei 600dpi zu scannen. Insbesondere, wenn nur schwarze Schrift zu sehen ist. Die Scanner mischen dann kräftig und ein Megabyte-Grab wird gebaut... Wie für Belege online: Schwarz/Weis 300dpi 

Doppelablage... müssen Belege für das Anlagenverzeichnis wirklich nochmal abgelegt werden, wenn sie schon in Belege online vorhanden sind? ...das machen tatsächlich Kanzleien/Mitarbeiter... 

u.s.w.... Hier muss aber bei jeder Kanzlei und deren Arbeitsabläufen nachgesehen werden. Pauschal kann das wohl keiner hier angehen... 

Und mit zunehmender Digitalisierung wird gerade die DokAblage/DMS ein echtes Datengrab. Kanzleien die DMS seit Jahren im Einsatz haben und den Einsatz durchweg "leben", können hier mit Sicherheit im TByte-Bereich berichten... 

Beste Grüße
Christian Ockenfels

[#16]

---

@chrisocki  schrieb:

---

u.s.w.... Hier muss aber bei jeder Kanzlei und deren Arbeitsabläufen nachgesehen werden. Pauschal kann das wohl keiner hier angehen... 

Und mit zunehmender Digitalisierung wird gerade die DokAblage/DMS ein echtes Datengrab. Kanzleien die DMS seit Jahren im Einsatz haben und den Einsatz durchweg "leben", können hier mit Sicherheit im TByte-Bereich berichten... 

Beste Grüße
Christian Ockenfels

---

Genau! 

Zudem: sich jetzt im Jahre 2022 noch mit der Verkleinerung von SQL-Datenbanken zu beschäftigen (hier in der Community gab es ja schon vor Jahren entsprechende Beiträge zum Thema) ist m.E. Zeitverschwendung mit Hang zum Hobby. 

Plattenplatz ist billig, Datenbanken aufzusplitten führt höchstens in die Tablettensucht...Zumal man nur noch neue Datenfriedhöfe schafft.

In ein paar Jahren geht das ganze eh in die Cloud; dann lieber zusammenhängend.

Kann mir nicht vorstellen das DATEV "Datentöpfe mit abgesplitteten Datenbanken" übernimmt. 

[#17]

... Herr @blum hatte vor einiger Zeit von seiner "User Experience" (seinem Umzug) von Datev DMS "alt" nach Datev DMS "neu" berichtet, eine 'Rechenaufgabe' und ein 'Umschaufeln' für mehrere Tage, sicherlich schweißtreibend, obwohl körperlich nicht anstrengend.

... und das ganze spielte sich sogar lokal in der eigenen 'Server-Landschaft' ab, wenn ich mich recht erinnere, auch mit einer 'wundersamen Brotvermehrung' (deutliche Vergrößerung des Datenvolumens)

Für mich sieht eine Vergrößerung der Datenmenge i.d.R. nicht nach einer Steigerung der 'Intelligenz' aus, sondern eher nach unkontrolliertem Verbrauch von Ressourcen.

Vielleicht passen heute nicht mal mehr Programme auf eine CD, die nicht mehr können, als "Hello World" auf den Bildschirm zu schreiben 😎

Ich werde jedenfalls nach Möglichkeiten Ausschau halten, die Datenmengen möglichst klein zu halten, auch wenn vielleicht eine Verkleinerung schlecht möglich ist

... und ob Hobby oder nicht, liegt im Auge des (vorerst einen) Betrachters 😎

.. aber das ist ok 😉

... zum Glück gibt es keine verpflichtende "Deutsche Hobby Grundverordnung" (DHGVO)

Apropos, @chrisocki ,

Sie bringen mich auf eine Spur ( es ist eben immer gut, sich auszutauschen, den 'Brain zu stormen') 

Es könnte tatsächlich sein, dass in der Dokumentenablage größere Belege-Sammlungen 'abgekippt' werden, die z.B. per E-Mail eintrudeln, weil diverse Mitarbeiter und/oder Mandanten UO noch nicht nutzen.

Ein 'Müllberg' in der Cloud ist jedenfalls nicht so störend wie ein Müllberg im eigenen Haus

[#18 · Accepted solution]

Hallo Community,

ich habe den Thread mal an unsere Kollegen aus der Entwicklungsabteilung weitergegeben, woraufhin ich eine sehr ausführliche Antwort erhalten habe. Diese möchte ich euch natürlich nicht vorenthalten und poste sie daher ungekürzt:

Wir beschäftigen uns schon einige Zeit mit der Größe der Datenbanken. Wie Sie schon richtig erkannt haben, betrifft es uns besonders bei der Dokumentenablage/DATEV DMS (insbesondere die Datenbank DOKORG_D wo die ganzen Dateien der Dokumente gespeichert werden).

Daher ist hier der Handlungsbedarf am größten ,weshalb der Fokus auch dort liegt.

Wie hier auch schon gesagt wurde, liegt der Fokus nicht unbedingt auf der Lauffähigkeit, denn die maximale Größe von Datenbanken werden wir nicht erreichen. Auch auf die Performance hat die Größe der DOKORG_D keinen Einfluss. Wo die Größe aktuell aber ein zunehmendes Problem darstellt, sind Prüfläufe, Wartungsläufe und Sicherungen und wieder Einspielen der Datenbanken.

Es sind uns auch mittlerweile Anwender bekannt, die eine Maximalgröße von Volumes festgelegt haben und dadurch an Grenzen stoßen.

Wir arbeiten daher gerade an der Möglichkeit, die DOKORG_D aufteilen zu können. Der aktuelle Plan ist, dass wir hierfür die vom Microsoft SQL-Manager angebotenen Funktionen der Filegroups verwenden. Die Datenbankdatei .MDF wird dabei ergänzt um .ndf Dateien. Die entsprechende Verteilung der Dokumentdateien auf die Datenbankdateien übernimmt der SQL-Server.

Die Aufteilung soll dabei so vorgenommen werden, dass nur neuere Filegroups beschrieben werden und ältere Filegroups nur noch durch Löschen von Dokumenten verändert werden.

Wenn es also Probleme in der Handhabung von zu großen Datenbanken geben sollte, kann diese aufgeteilt werden. Durch die Aufteilung können entsprechende Prüf-, Wartungsläufe oder Sicherungen zeitlich entzerrt werden. Z.B. die älteren Partitionen seltener (da sich wenig bis nichts ändert), die neueren häufiger prüfen. Für die tägliche Nutzung des Programms ergibt sich keinerlei Veränderung durch eine Aufteilung.

Alles ist weiterhin im Zugriff und erste Tests haben auch keine Änderung des Laufzeitverhaltens gezeigt. Die entsprechenden Datenbankdateien können hierbei auch überall liegen (solange die nötigen Rechte auf dem Verzeichnis sind), wodurch eine Einhaltung von Maximalgrößen auch möglich ist.

Das Ganze soll optional sein. Wer keine Probleme mit der Größe der Datenbank hat, kann weiterhin ohne Aufteilung arbeiten. Im Moment befindet sich die Möglichkeit zur Aufteilung in der Entwicklung und soll nach aktueller Planung im Laufe des Jahres möglich sein.

Mit einer wirklichen Empfehlung, ab wann eine Datenbank zu groß ist, tun wir uns aktuell wegen den oben genannten Punkten auch schwer. Die Grenze der maximalen Datenmenge werden wir mit DMS nicht erreichen, wodurch die Lauffähigkeit für sich gewährleistet ist. Daher kommt es auf individuelle Faktoren an, wie z.B. wie lang sind Wartungsfenster, wie lang dürfen also Prüfungen, Wartung und Co. dauern? Gibt es maximale Volume Größen oder allgemein, wie ist die aktuelle Größe handhabbar?

Die Überlegungen beschränken sich aktuell auf die Dokumentenablage/DMS, sind aber in Zukunft natürlich auch woanders denkbar.

Viele Grüße aus Nürnberg


Nina Schlee
DATEV eG, Service Dokumentenmanagement

[#19]

Hallo @Nina_Schlee,

vielen lieben Dank, dass Sie sich der Thematik angenommen und die Entwicklung weitergegeben haben.

Leider frage ich mich an dieser Stelle ernsthaft, warum das bei der Entwicklung des neuen DMS und der Dokumentenablage nicht schon seit Jahren auf dem Bildschirm ist?

Der Vorgänger (Dokumentenorganisation) hat doch ähnliche Mechanismen? Es gab ein Release, da wurden die Dokumente aus dem, bis dahin genutzten, Dateipfad in die SQL-Datenbank kopiert. Spätestens hier hätte man doch schon realisieren können, dass die Datenbanken naturgemäß an Volumen zulegen werden.

Zudem gab es bei dem DMS classic (Saperion) schon immer die extra angelegten Dokumentenspeicher. Die entweder manuell oder automatisch angelegt wurden, wenn der Vorgängerspeicher voll war. 

Allein dieser Mechanismus hätte doch die Entwicklung schon vor Jahren triggern müssen?

Warum wird hier mal wieder nur "reagiert" und nicht mal "agiert"?

Beste Grüße
Christian Ockenfels

[#20]

Der ganze Speicher muss dann wann besser früher als später auch noch in die Cloud. Also besser heute schon vorsorgen, dass es beim Wechsel in die Cloud keine Probleme gibt. 

Oder will DATEV wirklich bei 0 anfangen? Wie will DATEV dann die alte on-premise Umgebung im Zugriff behalten, wenn man doch in die Vergangenheit schauen will oder es gar muss? 

Spannend zu sehen, was Solution Partner dann machen, wenn DATEV in der public Cloud gelandet ist und weitgehend via Browser genutzt werden kann. 

[#21]

Hallo Community, 

folgende Rückmeldung habe ich bekommen: 

Das Thema haben wir bereits seit längerem auf dem Schirm. Bisher war der Bedarf allerdings nicht sehr hoch, weshalb andere Themen Vorrang hatten. Uns ist auch aktuell kein Fall bekannt, wo es Probleme mit der Größe der Datenbank gibt.

Die größten Datenbanken, die wir aktuell kennen, bewegen sich im Bereich von maximal 3TB und hier sind keine Beschwerden bekannt.

Warum das Thema nun in den Fokus gerät?

1. Das stetige Wachstum bestehender Bestände
2. Die Umstellung der größeren DMS classic Bestände

Dateien der alten Dokumentenorganisation lagen nicht in der Datenbank, sondern auf dem Filesystem, was mit Umstellung auf die Dokumentenablage im Sinne der Revisionssicherheit geändert wurde. Aber auch hier hatten wir nicht mit solchen Volumen zu tun, die zu einem Bedarf einer Partitionierung führten.

Wie Sie zurecht anmerken, gab/gibt es in DMS classic die Aufteilung mittels Medien. Mit den Größen der Dokumentenablage und der bisher umgestellten DMS Bestände gab es noch keinen Bedarf einer solchen Aufteilung. Daher ist es aus unserer Sicht nicht nur ein Reagieren.

Ein Bild, wie die Umstellung von Beständen in die Cloud aussehen wird, ist aktuell noch in der Entstehung.

Das Thema ist aber unabhängig davon, ob Bestände aufgeteilt sind oder nicht, da der Zugriff auf die Daten bei Aufteilung unverändert bleibt.

Viele Grüße aus Nürnberg


Nina Schlee
DATEV eG, Service Dokumentenmanagement

[#22]

@Nina_Schlee 

Wir es wohl eine Möglichkeit geben, extra Archivdatenbanken zu erstellen und dort beliebige Dokumente (inkl Revisionen) hinzuschieben? Meinetwegen Archiv 1, 2, 3 oder 2010, 2011 usw.

Anschließend wird ein Schreibschutz gesetzt oder ggfs. auch einfach gelöscht.

Das wäre natürlich sehr cool!

3TB-Datenbank.. ach du lieber Scholli.

Bei uns ist Rewe größer als DMS.. vermutlich 200DPI u. S/W sei Dank.