Das ist die letzte Version.
Ich würde mir aber nach mehreren Projekten den Aufwand sparen. Letztlich landest Du bei einem sinnvollen Schwellwert von 128kB.
Das sind dann ca 80% der max Anzahl aller Attachments, und möglichst geringer Zahl an resultierenden NLO.
Bei kleinerem Wert hast Du die ganzen Visitenkarten mit im Repository, die die Anzahl der NLO exponentiell in die Höhe schnellen lassen.
Ich denke, daosest war am Anfang dafür da, die Skeptiker bei einer neuen Funktion zu überzeugen sie einzusetzen. DAOS hat sich aber wirklich als „rocksolid“ erwiesen und ist in meinen Augen ein „nobrainer“ geworden. Für Mail und Archive lohnt sich das immer... vielleicht wurde deshalb das Tool nicht weiterentwickelt...
Und wie Ulrich schreibt: es kommt eh immer der gleiche optimale Schwellwert raus...
Oder muss der 128kB Schwellwert noch via notes.ini DAOSEST_BUCKETS eingestellt werden?Ui,Ui,Ui. Du möchtest Dich bitte noch einmal einghend mit DAOS beschäftigen!
Gibt es denn auch so einen ganz groben Wert den man Entschiedern nennen kann um zu sagen, so oder soviel wird eingepart?Nein, den gibt es nicht.
ZitatOder muss der 128kB Schwellwert noch via notes.ini DAOSEST_BUCKETS eingestellt werden?Ui,Ui,Ui. Du möchtest Dich bitte noch einmal einghend mit DAOS beschäftigen!
Der Schwellwert wird im ServerDokument eingestellt.
Nein, den gibt es nicht.
Die Ersparnis (in kB, MB oder GB ) hängt ja von einigen Faktoren ab.
Je mehr MailFiles die gleiche bitidentische Datei als Attachment haben, desto größer ist der Grad der Deduplizierung.
Werden Mails verschlüsselt? Da kann dann ein Attachment x mal vorhanden sein, DAOS dedupliziert aber nicht, weil die Verschlüsselung VOR DAOS greift.
Entscheidend ist aber nicht nur die Deduplizierung. Auch Standardprozesse wie compact oder Fixup sind schneller durch. Und die datensicherung sowieso. DAOS ist IMMER ein Gewinn.
Für Entscheider gibt es natürlich einen solchen Wert. Liegt bei mir zwischen 40% und 60%. Kommt darauf an, wo der am wenigsten das gesicht verzieht.
Oder so. :D
Noch eine abschließende Frage.
Wenn bei ca. 5 TByte Mailarchive DAOS aktiviert wird, hat der Server bestimmt erst mal was zu tun.
Merkt der Benutzer das in der Performance, wenn der auf sein Archiv zugreift bis DAOS fertig ist?
Ich tippe mal auf "kaum". :)
Ein compact -c bei einer Datenbank mit über 60 GB hat auch nur so 30 - 45 Minuten gedauert Wink.
LZ1 Komprimierung sollte vor DAOS aktiviert sein.Theoretisch ja.
ZitatTheoretisch ja.
In der Praxis gehe ich dazu über alle zusätzliche Komprimierung auszuschalten.
Also don´t use the option “-ZU” at already DAOS enabled databases !!! > In earlier releases -ZU was ignored for DAOS enabled databases. Now it works but gets attachments out of DAOS into the NSF to recompress, which is increasing the physical database size and duplicates data. You should only use -ZU before you enable DAOS. And this needs to be a two step process.wie wirkt sich DAOS denn aus, wenn Mail-DBs auch per imap und nciht nur per Notes/iNotes/Verse genutzt werden?
gibt es noch eine Beschreibung zum Estimator?
Ich will DAOS einführen, benötige jedoch ein paar Daten zur Planung.
gibt es noch eine Beschreibung zum Estimator?
Ich will DAOS einführen, benötige jedoch ein paar Daten zur Planung.
Bitte schau dir diesen Thread nochmal von Anfang an. Da stehen eigentlich alle Antworten, die du brauchst (inkl. Entscheider-Werte).
Carsten
Wie wird der Esimator eingesetzt?
Von der Domino Konsole oder über eine cmd?
Beides geht. Technisch ist es ein Addin, das über die API arbeitet und einfach ins bin Verzeichnis gepackt wird.
Danach kann es - wie z.B. updall oder compact - entweder bei laufendem Server über die Domino Console oder auch beim heruntergefahrenem Server, dann via cmd , aufgerufen werden.
Ich habe noch eine (ältere) Anleitung gefunden, die ich hier mal anhänge.
HTH
Carsten