Hallo Community,
mich würde interessieren, ob die Größe der SQL-Datenbanken beobachtet bzw. begrenzt werden sollte oder ob man der Software 'freien Lauf lassen' sollte, nach dem Motto "wat mutt dat mutt".
Wenn man die Datenbankgrößen über die Jahre beobachtet, fragt man sich, ob irgendwann der Topf überläuft und ob das System nicht irgendwann hauptsächlich mit dem Verwalten der immer größer werdenden Datenbanken beschäftigt ist.
Gibt es von Datev oder von Microsoft Empfehlungen, welche SQL-Datenbankgrößen noch 'vernünftig' sind ?
Gibt es Stategien, übergroße Datenbanken besser in kleinere Pakete (z.B. max. 10 GB) aufzuteilen, z.B. durch Auslagern von älteren Wirtschaftsjahren ?
Bei der DesasterRecovery könnte es auch einen großen Unterschied machen, ob man eine einzige große Datenbank (z.B. IRW.MDF oder DOKORG.MDF) oder nur einen Teil davon wiederherstellen muss).
Viele Grüße
Michael Vogtsburger
ob die Größe der SQL-Datenbanken beobachtet bzw. begrenzt werden sollte oder ob man der Software 'freien Lauf lassen' sollte, nach dem Motto "wat mutt dat mutt".
Begrenzen nur dann, wenn es technisch notwendig wäre, insbesondere, wenn zu wenig RAM verbaut ist, den sich der Hypervisor (VMware, HyperV, ...) noch teilen muss.
Da kommt es auf Ihre Konfiguration an:
Allgemein: je mehr RAM der DATEV FS hat, desto besser, desto mehr der IRW Datenbank (zu 98% immer die Größte in DATEV) kann im RAM und daher schnell verfügbar gehalten werden.
Und die Datenbanken (*.mdf) an sich sind ja nicht das Einzige. Zu jeder Datenbank gibt es auch eine "Protokolldatenbank" (*.ldf), die je nach Fall gleich groß wie die *.mdf werden kann. Diese kann im DATEV Umfeld gelöscht werden, sollte aber nicht, da bei einem Crash hieraus die *.mdf wiederhergestellt werden kann und andere, wichtige Daten diese *.ldf bereitstellt, sodass es in DATEV noch schneller geht.
Wenn man die Datenbankgrößen über die Jahre beobachtet, fragt man sich, ob irgendwann der Topf überläuft und ob das System nicht irgendwann hauptsächlich mit dem Verwalten der immer größer werdenden Datenbanken beschäftigt ist.
Da brauchen Sie keine Sorgen haben. Einzig, wenn Sie Mandant sind wird der SQL Express installiert. Dieser kann Datenbanken von maximal 10GB verwalten. Als Kanzlei kommt die SQL Standard Version von Microsoft zum Einsatz. Genauer gesagt die 2014er Version.
Nach Angaben von Microsoft liegt das Limit damit bei 524PB (PetaByte = 524.000 TeraByte). Da liegt die IRW Datenbank mit Ihren ca. 150GB noch locker drunter.
Gibt es von Datev oder von Microsoft Empfehlungen, welche SQL-Datenbankgrößen noch 'vernünftig' sind ?
Siehe Link. Ich denke alle DATEV SQL Datenbanken sind noch "vernünftig".
Gibt es Stategien, übergroße Datenbanken besser in kleinere Pakete (z.B. max. 10 GB) aufzuteilen, z.B. durch Auslagern von älteren Wirtschaftsjahren ?
Besser nicht, denn: nach jedem SR muss eine Datenanpassung durchgeführt werden. So müssen dann mehr als 1 IRW Datenbank angepasst werden bzw. wer legt fest, mit welcher IRW Datenbank arbeitet? 10 Mitarbeiter mit Datebank A, andere 10 mit B? Gerade bei der Neuanlage von Mandanten wird dann wieder wild irgendwo gespeichert, wenn das nicht vernünftig organisiert ist.
Und wenn Sie erst SQL Datenbanken auslagern, vom SQL trennen und anderswo aufbewahren: Dann brauchen Sie mal eben schnell Daten, die dann aber irgendwo anders liegen. Also erst wieder einbinden und dann schön über die gesamte Datenbank erstmal eine Datenanpassung auf den aktuellen Stand machen. Ggf. klappt das dann aber nicht mehr, da die alte REWE Datenbank Version 7 nicht direkt auf 10 (in Zukunft) angepasst werden kann.
Bei der DesasterRecovery könnte es auch einen großen Unterschied machen, ob man eine einzige große Datenbank (z.B. IRW.MDF oder DOKORG.MDF) oder nur einen Teil davon wiederherstellen muss).
Ich weiß nicht, ob es jetzt immer noch so ist - ich habe gelernt: an die DATEV Datenbanken kommen keine externen Programme dran. Diese können immer nur die ganze Datenbank (*.mdf) sichern und wiederherstellen. Dafür gibt es ja die Datensicherung online, die in die DATEV Datenbank schauen kann und dort auf Blockebende Daten sichert und auch wiederherstellen kann.
Korrigiert mich, wenn das jetzt mittlerweile anders sein sollte.
Hallo Herr Bohle,
vielen Dank für die ausführliche Antwort.
Sie haben natürlich Recht damit, dass man nicht manuell in die komplexen Mechanismen des SQL-Servers eingreifen sollte.
Mir geht es hauptsächlich darum, die verfügbaren Resourcen nicht zu überfordern.
Klar, mit RAM-Speicher sollte man nie geizen. Wieviel tatsächlich von welcher Software benötigt oder verwendet wird, ist ein Buch mit mehreren Siegeln.
Der Festplattenspeicher wird seltsamerweiser auch immer wieder knapp bevor der nächste Serverwechsel ansteht, obwohl er zum Installationszeitpunkt mehr als ausreichend war.
Die Serverbetriebssysteme sind zum Glück erstaunlich intelligent, robust und 'leidensfähig', wenn es eng wird. Dann werden eben automatisch die Kontingente unter den Prozessen anders verteilt oder es wird zur Not auf die Festplatte ausgelagert, was das System natürlich sehr stark ausbremst.
Allerdings gibt es Aktionen, die direkt mit den Dateigrößen zusammenhängen, z.B. das Erstellen von Snapshot-Dateien für die Datenbankprüfungen (DBCHECK) u.a.
Mir sind einzelne Riesen-SQL-Dateien weniger sympathisch als mehrere kleinere SQL-Dateien. Datev unterstützt z.B. die Aufteilung der REWE-Datenbanken dadurch, dass man weitere Pfade anlegen kann.
Da diese Pfade als Unterverzeichnisse von STANDARD angelegt werden, werden sie bei Datenanpassungen auch automatisch berücksichtigt.
Ein Abhängen und Auslagern wäre sicher nicht sinnvoll.
Viele Grüße
Michael Vogtsburger
P.S.
Ich hatte noch nie den Ehrgeiz, und auch nicht die Ressourcen, um die Grenze von 524 PetaByte zu testen
Der Festplattenspeicher wird seltsamerweiser auch immer wieder knapp bevor der nächste Serverwechsel ansteht, obwohl er zum Installationszeitpunkt mehr als ausreichend war.
Dann wurde entweder vorher falsch geplant oder Sie haben andere Speicherfresser im System. Wenn vorhanden landen ganz viele E-Mails immer im Exchange, wenn sich Mitarbeiter Excel Tabellen und andere Dateien gegenseitig zuschicken anstatt sie auf einem Netzlaufwerk abzulegen, wo alle drauf zugreifen können .
Hier kann man ja mal auf den entsprechenden System TreeSize drüber jagen und die Speicherfresser schnell ausfindig machen und ggf. wieder Platz machen.
Oder per Exchange Regel Anhänge mit den Typen *.xlsx, *.docx und Co. einfach sperren.
Wieviel tatsächlich von welcher Software benötigt oder verwendet wird, ist ein Buch mit mehreren Siegeln.
Der DATEV SQL zieht sich erstaunlich viel. Gibt man einem DATEV FS 64GB RAM, werden diese auch schön und gut ausgenutzt. Weniger würde ich einem DATEV FS auch nicht mehr geben, sofern es sich um eine Kanzlei mit ca. 25 Mitarbeitern handelt und die REWE Datenbank um die 150GB hat.
Datev unterstützt z.B. die Aufteilung der REWE-Datenbanken dadurch, dass man weitere Pfade anlegen kann. Da diese Pfade als Unterverzeichnisse von STANDARD angelegt werden, werden sie bei Datenanpassungen auch automatisch berücksichtigt.
Das stimmt. Dann muss aber entsprechend festgelegt oder gleich verschoben werden, wo welche Mandante landen. Dann wird entsprechend schnell-schnell "mal eben" was erstellt und am Ende landet doch alles in der STANDARD Datenbank oder man muss manuell und händisch von A nach B verschieben.
Ist aber alles unnötig. Und wir haben auch eine 700GB Exchange Datenbank. Ist auch nur eine. Sehe auch da, wenn entsprechend gesichert kein Problem.
Allerdings gibt es Aktionen, die direkt mit den Dateigrößen zusammenhängen, z.B. das Erstellen von Snapshot-Dateien für die Datenbankprüfungen (DBCHECK) u.a.
Das mag sein. Aber ggf. wird das wie bei VMware auch beim 2. Mal inkrementell gemacht, sodass der Snapshot viel kleiner ausfällt? Das weiß ich nicht. Was ich weiß, ist dass Speicher heute kaum noch was kostet und wenn es nicht SSD sein muss, reichen auch 10k/15k HDDs aus, wobei 2. wohl mittlerweile so teuer wie SSDs sind.