Komprimieren von Mailfiles durch User

[brosmic]

Hallo zusammen,

...ich habe ein Problem, bei dem ich etwas Unterstützung brauche und zwar folgendes:

Die Mailfiles unserer User haben eine Größenbeschränkung. Wird diese erreicht, so sind sie aufgefordert in ihrer DB Platz zu schaffen (durch Löschen von Anhängen, Nachrichten).

Anschließend komprimieren sie ihre DB über den Button in den DB-Eigenschaften. Nur werden damit die gelöschten Bereiche nicht freigegeben! Es erfolgt keinerlei Reduktion der DB-Größe!

Führe ich das Komprimieren jedoch mit "load compact -B mail\xxxx.nsf" an der Konsole durch, klappt dies problemlos.

Zusätzlich führen wir 3-mal wöchentlich eine programm-gesteuerte Komprimierung durch, die auch funktioniert.

Meine Frage: Woran kann dies liegen? Welche (minimalen Rechte) benötigen die User auf dem Server um diese Aktion durchzuführen? Handelt es eventuell gar um einen Bug?

Unsere Umfeld: Server 6.5.2, Clients mit 6.5.1 und 6.5.2.

Wir haben unsere Systeme vor kurzem von R6 umgestellt (d.h. Server komplett neu installiert, R5 Mail-DB's auf ODS 43 konvertiert (Schablone inotes6.ntf )).

Vielleicht hat einer von Euch eine Idee !?

Gruß
brosmic

[m3]

Ich weiss, die Frage klingt bloed, aber ...

Komprimieren Deine User auch wirklich die DB am Server und nicht eine lokale Replik?

[Driri]

Habt ihr SoftDeletion aktiviert ? In dem Fall bleiben die gelöschten Dokumente ja noch für einen Zeitraum X in der Datenbank erhalten, dann bringt der Compact erst nach Ablauf des Zeitraums etwas.

[brosmic]

@m3
...es wird in der Tat die Server-DB komprimiert, bzw. sie sollte komprimiert werden

@Driri
...das mit den SoftDeletion's werde ich nochmal prüfen.

Gruß
brosmic

[m3]

Hmm. Man koennte natuerlich einen Agent schreiben, den die User aufrufen koennen, der dann ein "compact -B" fuer das Mailfile des Users auf dem Server ausfuehrt.
Ist aber IMHO ein boeser Hack.

[brosmic]

@Driri

...habe das mit den SoftDeletion's ausprobiert. Hat aber leider keinen Einfluß.

Wenn der User die Komprimierung über die DB-Eigenschaften startet, steht auf der Konsole 0K Bytes recovered (0%).

Löst man als Admin den compact an der Konsole aus (load compact -B mail\xxx.nsf) so sieht man auch ein positives Ergebnis (xK Bytes recovered (x%).

Hat vielleicht noch jemand eine Idee oder gar auch dieses Problem?
Vielleicht ist auch bei anderen noch garnicht aufgefallen!?

Gruß
brosmic

[koehlerbv]

Haben denn Deine User Manager-Rechte auf ihre Mail-DBs ?

Bernhard

[Wolfgang]

... das klingt so, als ob Transaction Logging aktiviert ist. Wenn das der Fall sein sollte, können die User meines Wissens nicht so komprimieren, das die DB-Größe tatsächlich abnimmt.

Gruß
Wolfgang

[brosmic]

@Wolfgang

...in der Tat, Transaktionsprotokollierung ist aktiviert. Allerdings muss ich jetzt hier in Verbindung mit Komprimierung wissensmäßig passen.

Wie ist da der Zusammenhang? Heißt das, Transaktion-Logging und Komprimierung durch User geht generell nicht oder nur mit bestimmiten Konfigurationseinstellungen?

Gruß
brosmic

[m3]

Es hat einen guten Grund, warum der User das nicht darf.

Aus der Online-Hilfe:

When you enable transaction logging, Domino assigns a unique database instance ID (DBIID) to each Domino database. When Domino records a transaction in the log, it includes this DBIID. During recovery, Domino uses the DBIID to match transactions to databases.
Some database maintenance activities, such as using the Compact command with options, cause Domino to reconstruct the database in such a way that old transaction log records are no longer valid. When this happens, a new DBIID is assigned to the database. From that point on, all new transactions recorded in the log for that database use the new DBIID. After a database is assigned a new DBIID, take a new full backup of the database.

Du wuesstest sonst nie, wann du ein Full-Backup machen muesstest.

[brosmic]

@m3

...danke für diesen Auzug!
Ich glaube damit habe auch ich  ;)es kapiert und dies scheint auch das "Problem" zu sein, wobei es andersrum betrachtet ja eigentlich kein Problem ist, sondern ein Feature.

Nochmals danke für die Hilfe!!

Gruß
brosmic

[brosmic]

@all

...danke nochmals für Eure Unterstützung !!

Ich wollte das Thema nur nochmal kurz mit einem Status abschließen.

Das "Problem" läßt sich beheben, indem man in den erweiterten Datenbankeigenschaften schlicht und ergreifend die Transaktionsprotokollierung für jede gewünschte DB deaktiviert.

Wichtig dabei ist noch, daß die DB nicht geöffnet ist und der Datenbankcache geleert wird.

Hat jetzt bei diversern Usern auf Anhieb funktioniert.

Gruß
brosmic

[m3]

* m3 ist heute philospophisch:

Verwendet ihr die Transaktionssicherung gar nicht?
Wieso war sie dann aktiviert? 

[brosmic]

@m3

...wir verwenden sie, waren uns aber des Einflusses der Komprimierung nicht bewußt.

Um es auch mal philospohisch zu sagen: Wir haben jetzt quasi eine Bewußtseinserweiterung erfahren

[m3]

Und jetzt stellt Ihr die Sicherungen der Maildatenbank um auf .... ?

(ja, ich bin neugierig

[brosmic]

@m3

.....Fullbackup mit BrightStor ArcServe Backup 11 + Backup Agent for Lotus Notes ?!

[m3]

OK, ihr pfeift also sozusagen auf das incrementelle Backup. Alles klar, danke fuer die Info.