DAOS blockiert Nutzerkomprimierung?

[XinMing]

Hallo Forum,

wir haben nun seit gut einem Monat DAOS im Einsatz und sind mehr als zufrieden.
Jetzt kam ein Mitarbeiter aber auf die ja eigentlich gute Idee seinen Maileingang zu komprimieren.
Heißt er geht auf Datei -> Anwendung -> Eigenschaften -> i -> Komprimieren.
Dann wartet er normalerweise 5 Minuten, bzw schließt Notes und startet es neu und findet unter
Datei -> Anwendung -> Eigenschaften -> i -> Verwendet einen >90%-Wert.

Jetzt funktioniert das aber leider nicht mehr. Die Nutzer haben nach wie vor, auch wenn vllt gefährlich, Manager-Rechte.
Aber wenn er es ausführt passiert einfach nichts. Erst wenn ich via Admin-Console den "compact -c -D"-Befehl anstoße und die Datenbank geschlossen ist, funktioniert es.

Hat wer eine Idee woran das liegen kann, das es jetzt nicht mehr vom Nutzer selbst im laufenden Betrieb gemacht werden kann? 
Ich würde mich über jede Hilfe freuen. 

[NLA]

Hallo Pierre.

Das "warum gehts nicht" kann ich Dir nicht beantworten, aber grundsätzlich würde ich der Einfachheit halber ein Programmdokument übers Mailverzeichnis erstellen, welches dies automatisch für alle User erledigt...

[XinMing]

Schade.. Verstehe das mit dem Dokument dafür jetz nicht so wirklich.
Wäre schön wenn es wieder möglich wäre das die Mitarbeiter das selber machen können.
Aber wenn das wegen DAOS vllt nicht mehr geht, wäre das schade..

[Jörg P.]

Hi,

Ursache ist wohl nicht DAOS, sondern das Transaction Logging, Auszug aus der Hilfe:
"Wenn die Transaktionsprotokollierung jedoch aktiviert ist, können die Benutzer ihre eigenen Maildateien nicht komprimieren."

Aber das brauchen die Anwender auch gar nicht, wenn du die Quota enforcement auf "Check space used in file when adding a note" stellst.

[XinMing]

Kann ich das irgendwo im Administrator einrichten?
Muss eingestehen das ich davon noch nie etwas gehört habe..
Und Google spuckt mir seltsame Dinge aus.. o.O



Ich rede übrigens von:
"Aber das brauchen die Anwender auch gar nicht, wenn du die Quota enforcement auf "Check space used in file when adding a note" stellst."

[Jörg P.]

Findest du im Serverdokument -> Transactional Logging -> Quotas

Hth
Jörg

[XinMing]

Habe es jetz mal hier umgestellt, glaube das meintet ihr..
Vielen Dank schonmal, falls ich richtig lag! 


Serverdokument
-> domino
--> Transaktionsprotokolierung
---> Größenbeschränkung
Gewechselt auf:
Belegten Speicherplatz in Datei beim Hinzufügen eines Dokuments prüfen

[Ralf_M_Petter]

Diese Einstellung bringt aber nur was wenn Ihr auch Quota verwendet.

Übrigens ganz höflich formuliert (Will nicht wieder einen Tadel bekommen) ist der Tip mit dem compact in einem Programmdokument nicht schlau. Warum glaubst du hat die IBM das komprimieren bei eingeschalteten Transaction Log dem Benutzer weggenommen, damit jetzt der Admin mal einfach so den Compact aufruft.

Wenn ihr eine Backupsoftware die das Transaction Log bei der Sicherung verwendet einsetzt, werdet ihr beim Rücksichern schwer auf die Nase fallen, wenn ihr ein copy style compact gemacht habt. Das ist vor allem bei inkrementellen Sicherungen absolut tödlich. Compact weist auf diesen Sachverhalt auch hin, wenn Translog aktiviert ist (Wenn man es über ein Programmdokument macht sieht man diesen Hinweis aber nicht!!). Der Hintergrund für die Problematik ist, dass im Translog weder der Dateiname noch der Replikaname sondern die DBIID gespeichert ist. Jeder Datenbank hat eine eindeutige DBIID. Bei einem copy style compact bekommt die Kopie eine neue DBIID und alle Transaktionen sind für diese Datenbank nicht mehr vorhanden.

Grüße

Ralf




 

[MCPvsTron]

@Ralf
Als Ergänzung, nicht nur bei einem compact -c, sondern auch bei einem compact -B was man in der Regel einsetzt und auch bei einem fixup -j wird die DBIID neu erzeugt.
Wobei man bei diesem Fall nicht sagen kann ob überhaupt Archive Logging aktiviert wurde. DAOS setzt zwar TR-Logging voraus, es kann ja aber auch der Circular-Style im Einsatz sein.
Nichtsdestotrotz sollte der Admin wissen was er macht 

Viele Grüße

Christian

[Ralf_M_Petter]

Meine Meinung ist, dass man weder "compact -c" noch "compact -B" regelmäßig machen sollte. Das verschlechtert nur die Performance. "compact -b" ist die Option die man regelmäßig durchführen sollte. Steht ja auch in der Hilfe, dass dies die empfohlene Option ist.

Die Reduzierung der Datenbankgröße macht ausschließlich dann Sinn, wenn man sich sicher ist, dass die Datenbank nicht mehr auf diese Größe anwachsen wird.

Ein Beispiel Mail File 1 GB und der Benutzer löscht 100 MB an Daten. Jetzt komprimiert er mit Reduzierung der Datenbankgrösse. Jetzt kommen wieder neue Mails und in einer Woche hat er wieder 1 GB an Daten. In der Zwischenzeit musste das Betriebssystem aber mehrmals die Dateigröße anpassen, was ein aufwendiger Vorgang ist. Ausserdem wurde dadurch die Datei in mehrere Fragmente zerteilt. Beispiel 2 Wieder löscht der Benutzer 100 MB Daten. Die Datenbank wird ohne Reduzierung der Dateigrösse komprimiert. Jetzt hat das Operating System 1 Woche keinen Aufwand mit der Datei, da der Whitespace bereits vorhanden ist. Ausserdem wird die Datei nicht fragmentiert.

[MCPvsTron]

@Ralf, das compact hat noch einen anderen Sinn.
Wenn man beim Archived TR-Logging mit einem Backup Tool sichert, musst du theoretisch ja die zugehörigen TR-Logfiles so lange im Backupsystem aufheben bis eine neue DBIID vergeben wird um ein punktgenaues Restore einer Datenbank zu ermöglichen.
Das ist aber je nach Datenmenge nicht lange möglich, zudem dauert es dann sehr lange wenn man wirklich eine Datenbank von Uhrzeit X zurück bringen will, da ja alle Logfiles durchgegangen werden müssen.
Wir führen am Wochenende nach dem compact immer eine Vollsicherung durch (incremental im IBM TSM Jargon) und sichern in der Woche nur die TR-Logfiles.
Selbst dann benötige ich zum Teil schon 2 Stunden wenn ich eine Datenbank mit Stand von Freitag benötige (immer dann löschen die Anwender wohl hektisch..), da auf die Vollsicherung vom Wochenende alle Logfiles bis Freitag angewendet werden müssen.

Viele Grüße
Christian

[koehlerbv]

Ralf, einen Fragmentierungstod musst Du aber sterben: Auch, wenn die Mail-DB nicht selbst auf OS-Ebene fragmentiert sein sollte (meist schon ein frommer Wunsch), dann werden die Mails innerhalb der Mail-DB über den Whitespace munter verteilt, da der User ja nicht gerade NoteID-mässig zusammenhängende Notes löschen wird.

Bernhard

[Ralf_M_Petter]

@Bernhard muss man eben genau nicht, du defragmentierst ja den Whitespace mit compact -b. Diese Option ist auch die empfohlene von der IBM und der Grund ist genau der von mir erklärte.

@Christian Du musst aber keine Änderung der DBIID machen nur damit der Tivoli eine neue Vollsicherung macht. Der richtige Weg wäre doch den Tivoli einfach anzuweisen, dass er eine Komplettsicherung machen soll. Nennt sich soweit ich weiß "Selektive Sicherung" Was Ihr macht ist wahrscheinlich die "Teilsicherung" die genau das von dir beschriebene Verhalten zeigt. Dazwischen müsst Ihr dann noch ziemlich oft die "Protokoll Archivierung" machen, da sonst das Transaction Log nicht gesichert ist und es schlimmestenfalls sogar voll werden könnte.

siehe:

http://pic.dhe.ibm.com/infocenter/tsminfo/v6r3/index.jsp?topic=%2Fcom.ibm.itsm.mail.dom.unx.doc%2Ft_dpdom_daos_backup.html

[koehlerbv]

Sorry Ralf,  den Teil Deines Posts habe ich ausser Acht gelassen, so dass meine Aussage sich auf ein "Lass laufen nach den Löschungen" bezog. Du hattest natürlich vollkommen Recht.

Bernhard (aus dem ehemaligen Vorderösterreich  )