Macke in der Mailschablone ?

  • bei uns läuft über programmdokument
    täglich compact mail/-B und wöchentlich compact -B

    Mail-Cluster 2 x ND 8.5.3 FP3 , 2200 Clients 8.5.3, je 1 SMTP-IN/SMTP-Out ND 8.5.3,
    Anwendungscluster (2 x ND 8.5.3), interne SMTP-Sender (2xND 8.5.3)

  • ok - ich hab nochmal genauer geforscht und (ich hatte sowas schon befürchtet) meine aussage daß der compact dafür verantwortlich ist war schlicht falsch. ich war da einer falschaussage in einem älteren papier aufgesessen. man soll eben nicht alles glauben was man nicht überprüft hat. für abgelaufene dokumente ist es nämlich ein anderer task nur hatte ich gelöschte nicht mit abgelaufenen gleichgesetzt. es ist nämlich der indexer (update bzw. updall). allerdings gibt es keine mir bekannten parameter die das ganze beeinflussen können wann er das tut. m.e. tut er es sofort wenn eine db von ihm bearbeitet wird. zumindest sollte er das laut support info so tun. da der indexer in form des update-tasks ständig läuft kann man es auch kaum verhindern. warum allerdings bei dir nachweislich einige dokumente nicht gelöscht wurden weiß wohl nur der server selber ;=)


    in dem zusammenhang fand ich noch die folgenden infos die für argumente gegen den papierkorb als dauerablage sprechen:


    Zitat:
    Starting in Domino 5.0.12 and Domino 6.0, the Maximum number of Soft Deletions is 32768. In previous releases of Domino 5.x the default maximum number of Soft Deletion was 1000.


    unabhängig davon wirst du das problem mit den defekten gelöschten dokumenten m.e. nur los wenn du die softdeletion wenigstens kurzzeitig deaktiviertst (und vorher alles daraus rettest was nicht endgültig weg soll)

  • Um mich auch mal in diese diskution ein zu mischen... folgendes..


    Die erwünschte funktionalität der immer vorhanden bleiben von "löschungen" klappt in Notes einfach nicht zuverlässig.
    Ich habe bei einem kunde ein ähnliches problem zu lösen gehabt und es NUR und AUSSCHLIEßLICH über einen design änderung durchführen können.
    Was ich gemacht habe:
    1) QueryDelete geändert um manuelle löschungen zu unterbinden
    2) Aktion eingefügt der ein feldwert setzt und damit das dokument markiert als "gelöscht"
    3) ALLE ansichtformel geändert und den gelöschte dokumente nicht mehr anzeigen
    4) Ansicht (und foldervorgabe) erstellt für das darstellen (und eventuell sortieren) von gelöschte dokumente
    5) Aktion dort erstellt für das tatsächlich löschen (mit 3 fache (!) bestätigung)


    Einziges problem was wir dort bis heute hatten war ein plattenplatz problem, weil sämtliche quota's überschritten worden sind.
    Es gibt dort etwa 500 users, und durchschnittlich 20.000 Dokumente in der mailfile, und 2.4 Gb plattenplatz verwendung.


    Mittlerweile denken die über einen ND6 umgebung nach damit dort nochmehr gespeichert werden kann... leider.

  • Ach ja, im postopen der maske war noch einen zusätzliche routine der wenn das dokument aus ein ordner heraus geöffnet wird während es "gelöscht" ist das der anwender gefragt wird ob er das dokument im "gelöscht" struktur übernehmen möchte, wenn ja, dann wird den gleiche ordner im gelöscht struktur erstellt (wenn nicht vorhanden), und dann dort hin verschoben.


    Waren insgesamt fast 5 tagen arbeit mit viel viel testen..

  • hallo carsten,
    nochmals vielen dank für deine hilfe. nachdem "herr müller" wieder da war, musste ich seine fehlerhafte mail-db reparieren. habe vorsichtshalber eine replik davon gemacht und die reparaturversuche auf diese replik angewendet. der papierkorb war nach dem replizieren schon leer, brauchte nur noch die restlichen von dir am 22.07. 18:35 beschriebenen schritte durchführen. jetzt klappt es wieder :)


    gruss
    jürgen

    Mail-Cluster 2 x ND 8.5.3 FP3 , 2200 Clients 8.5.3, je 1 SMTP-IN/SMTP-Out ND 8.5.3,
    Anwendungscluster (2 x ND 8.5.3), interne SMTP-Sender (2xND 8.5.3)