Optimale Datenbankgröße

[mcilly]

Hallo zusammen!

Wir sind gerade daran unsere User ein wenig zu erziehen. Darunter fallen Quotas und Archivierung. Da ja Version 6 mit 64 GB max. arbeiten kann, die simple Frage, was ist den optimal? Wir haben teilweise DBen über 15 GB und das ist nicht wirklich einfach zu administrieren. Bei einer Archiv DB lasse ich mir die 64 GB noch einreden, aber sonst...?

Was meint ihr, alles unter 1 GB ist gerade noch gut?

[matze79]

Bei einer DB von 5 GB / 80.000 Docs dauert die Datenbank-Maintenance (fixup, compact, updall) je nach Hardware ca. 1/2 Stunde. Hast du nun ein Problem und musst Datenbanken recovern, dauert dass entsprechend lange. Bei uns sind die DBs zwischen 20 MB und 1 GB groß. In den DBs sind mind. 50 % unwichtige Mails drin, wo es einfach nur mal ein bisschen Zeit kosten würde, diese zu löschen.

[mcilly]

Meine Rede, danke matze79 für das erste Feedback.

[Georg2102]

Ich hatte vorletzte Woch ein Problem mit einer Mail-DB von 4,8 GB.
Daraufhin hat mir der nette Herr von Notes-Support mitgeteilt, dass Datenbanken ab 3 GB zu Problemen neigen. Das wird zwar mit Sicherheit nirgends von IBM offen publiziert, aber entsprechende Probleme sind wohl bekannt.

HTH
Georg

[matze79]

@Georg2102

Dem kann ich nur zustimmen. Manche große DBs werden bei mir jede Nacht über ein Programmdokument gefixt. Die Probleme basieren aber mehr auf den Indizes. Wenn ein Kollege keine Ordner zur Ablage nutzt, sind 40.000 Dokumente in der Inbox leicht möglich. Ist dann was buggy stürzt der Indexer ab oder geht auf 99% CPU-Load. Auch wird die DB (und damit augeschneinlich Notes) für den User sehr langsam.

Es gibt zu dem Thema einen neuen Artikel von Lotus, wo auch dieses Thema beleuchtet wird:

Sizing your IBM Lotus Domino mail servers
http://www-128.ibm.com/developerworks/lotus/library/domino-mail-sizing/

[Georg2102]

@matze79

Bei uns ging das so weit, dass der User einen Hash-Wert-Fehler angezeigt bekam und eigentlich ein Restore der Mail-DB nötig gewesen wäre. Zum Glück hat unser System sehr ausgeprägte Selbstheilungskräfte, sodass nach Domino- und Client-Neustart der Fehler spontan behoben war.
Aber der Restore von 4,8 GB hat schon für ein schelchtes Gefühl gesorgt.

[dh-paule]

Wenn ich es richtig lese, dann gehts hier um die MailDB...

Mich würde in dem Zusammenhang interessieren welche wirklich vernünftige Begründung es für ein Mailfile im GB Bereich gibt! Bei uns gibt es offiziell 50MB Speicherplatz, bei 100MB wird "QuotaWarning" versendet... und das dann immer wieder, bis es den User richtig nervt 

Mal ganz ehrlich, wenn man die Archivierungsfunktion richtig einsetzt ist es doch absolut kein Problem eine MailDB im Bereich bis max. 100MB / 150MB. Wenn man sich selbst diszipliniert sind auch unter 100MB absolut kein Problem.

Ich selbst bearbeite pro Woche einige hundert Mails, auch mit Anhängen, Präsentationen usw... ich komme jedoch prima mit der 100MB Vorgabe zurecht. Alles gesendeten Mails grösser 1MB wandern am Ende der Woche ins Archiv, und monatlich wird auch der Eingang "bereinigt" und archiviert.

Wie gesagt, mich interessiert brennend was eure User denn sagen WARUM eine MailDB unbedingt so gross sein muss.

[mcilly]

@dh-paule: ja stimmt schon was du sagst. Unser Problem, ich habe das Domino System übernommen, Plattenplatz und Archivierung war NIE ein Thema. Kaufen wir einfach ein paar Platten, das passt schon. Nur jetzt mach ich schon seit 2 Jahren Dampf, dass das System nicht mehr administrierbar ist (Backup, Restore, Fixup, Compact usw.).

Nun wird eine Archivierung und eine Quota eingeführt, man bin ich glücklich...
Dass das die User jetzt nicht versetehen ist auch klar, denn es ging ja bisher auch! Wegen den 100 MB, damit kommt ihr aus? Was ist denn mit den Ansichts Indizen? Die brauchen doch auch einiges und werden der DB Größe mit angerechnet.

[dh-paule]

100 MB schafft man beim disziplinierten Arbeiten problemlos. Der Volltextindex wird lokal erstellt, so wie auch jeder User hauptsächlich lokal arbeitet und per periodischer oder manueller Replizierung immer wieder die updates dazuholt.

Klar, so ein Umstellung, wenn vorher "alles" möglich war, ist schon schwierig. Bei uns war es genau anders herum, wir haben mal mit 50MB angefangen... Achja, die Größenordnung unserer Organisation vielleicht noch als Info... ich hab grad mal ins Adressbuch geschaut und 33.000 Usereinträge gefunden. Da braucht man nur noch zu multiplizieren und weiss was für eine unbeherrschbare Datenmenge daraus werden könnte.

[scifi]

Ich kann mich dh-paule nur anschließen: 100 MB sind machbar. Wir haben nur einige 'Ausreißer' mit ca. 500 MB ... der Oberindianer und so ...
Allerdings hatten wir das Glück, die ganze Domino-Struktur vor 3 Jahren neu aufzusetzen (Übernahme von 600 OutLOL's: JA!!!) und haben damit auch gleich ein paar vernünftige Regeln einführen dürfen.

Gruß Sebastian

[Georg2102]

@dh-paule

über Sinn oder Unsinn solch großer Mail-DBs gibt es ja hier bereits mehr als genug Threads.
Ich hätte auch gerne kleinere Mail-DBs. Allerdings sind wir von Outlook nach Notes umgestiegen und ich musste alle Mails aus Outlook importieren, sonst wären wir gar nicht gewechselt.
Zumindest darf ich seit einer Woche archivieren. Seitdem ist die durchschnittliche Mail-DB-Größe auf etwa 25 bis 30% gesunken.

Gruß
Georg

[mcilly]

Der Volltextindex wird lokal erstellt, ...

Ich meinte den Ansichtsindex und der ist ein Teil der Mail Datenbankgröße. Wenn du im Admin unter Dateien auf eine DB klickst und dann auf "Dateien -> Ansichten verwalten", dann schreibt er dir wieviel % der vom Speicherplatz betrifft. Ist der bei uns nur deshalb so bei 200 MB, weil es auch um große DBen wie 3 GB geht?

[HarryB]

Was meint ihr, alles unter 1 GB ist gerade noch gut?

Daniel Nash meinte auf der letzten DNUG Konferenz in seinem Vortrag über die Performance von Notes Datenbanken, dass diese bei Überschreiten von ca. 500 MB signifikant langsamer werden.

Viele Grüße
Harry

[koehlerbv]

Das wäre aber eine reichlich allgemeine Aussage, der ich - wenn sie denn so gefallen ist - glatt widersprechen würde.

Bernhard

[HarryB]

Wie er gesagt hat, haben die entsprechende Perfomance-Tests auf eine Reihe Datenbanken gemacht. 500 MB scheint da der mittlere Wert zu sein. Dass es Datenbanken gibt, die auch mit 1 GB gut laufen und andere, die mit 250 MB schon in die Knie gehen (auch abhängig von der Qualität der Programmierung) dürfte klar sein.

Viele Grüße
Harry

[dh-paule]

@dh-paule

über Sinn oder Unsinn solch großer Mail-DBs gibt es ja hier bereits mehr als genug Threads.
Ich hätte auch gerne kleinere Mail-DBs....

SORRY, aber wenn man doch die Ursachen der Probleme kennt (zu grosses Mailfile) dann macht man sich doch an die Beseitigung der Ursache und doktert nicht dran herum. Ich bin mir sicher das KEIN vernünftig denkender Mensch ein Mailfile im GB Bereich rechtfertigen kann. Das ist pure Faulheit und Unvermögen LN richtig zu nutzen.
Da hilft wirklich nur Schulung und Erziehung der User !!!

P.S: Wenn Du eine wirklich plausible und nachvollziehbare Begründung für die Größe der MailDB liefern kannst, dann lasse ich mich gern von der "Notwendigkeit" überzeugen.

P.P.S: Ich hab grad mal mein lokales Mailarchiv angeschaut. Seit 01.2004 haben sich dort 25.000 Dokumente angesammelt, davon 600 Dokumente > 1MB und das Archiv hat jetzt 2.1 GB
Ich wüsste nicht warum ich den Kram der 2 Jahre alt ist in der "produktiven" MailDB lassen sollte. Im allgemeinen benötigt man einen Rückblick auf die letzten 1-2 Monate, alles andere kann ins Archiv...

[Georg2102]

Bei mir machen 3 User alleine knapp 70% des Datenvolumens aus, aber leider gehören diese 3 in die GL. Sag da mal was...

Bei allen anderen "normalen" Usern ist die durchschnittlich Größe der Mail-DB unter 100MB.

Aber ich gebe auch bei den letzten 3 Problem-DBs (bitte nicht mit dem ProblemBÄR vom StoiBÄR verwechseln und auf meinen Domino ballern...) noch nicht auf.

Außerdem ging es hier mal in einem anderen Thread um Aufbewahrungspflichten von Geschäftsvorfällen. Da wird der lokalen Replik nur wenig vertraut. Leider funzt die serverbasierte nicht richtig und die Jungs von IBM haben auch keinen Tipp mehr für mich.