Domino 9 und frühere Versionen > ND7: Administration & Userprobleme

Alte Daten und Löschungen beim Replizieren verhindern?

(1/4) > >>

LisaS:
Hallo, folgendes ist passiert:
Auf einer Sever-DB sind vor ein Paar Wochen viele Daten gelöscht worden. Nun hat wohl jemand eine lokale Replik repliziert und die letzte Replizierung war vor einem Jahr. Die Folge war das alle auf dem Server gelöschten Dokumente wieder drin sind.
Wie kann man dass verhindern? Leider ist das eine große DB die sich auf dem Server ständig ändert, lokal von den Leuten ehr zum Lesen genutzt wird(Die lokale Replik muss auch nicht unbedingt aktuell sein), dass heisst die Leute sind nicht unbedingt scharf drauf, ständig zu replizieren.
Ich denke eine Lösung wäre , wenn man vorm replizieren prüfen könnte, ob in den letzen nicht 60 Tagen repliziert wurde, dann die Replizierung zu verhindern.(Aber wie..?)
Der Mitarbeiter muss dann eine neue Replik anlegen und alles ist super ??? :-:

Was kann, sollte ich tun?

Gruß
Hitcher

koehlerbv:
Setze in den Replizierparametern das Intervall "Dokumente entfernen, die seit x Tagen nicht geändert wurden" entsprechend höher - und dabei NICHT den Haken vor der Option setzen (falls nicht gewünscht).
Hintergrund: Der Wert in diesem Feld - geteilt durch drei - bezeichnet auch die  Anzahl von Tagen, in den deletion stubs erhalten bleiben. Vulgo: Standard = 90, nach 30 Tagen werden daher die stubs entfernt, und Du erlebst dann ggf. den Effekt, den Du jetzt gesehen hast.

Anders kannst du in den Replikationsprozess nicht eingreifen.

Bernhard

mcilly:
Hallo Bernhard! Ich bin jetzt schon 12 Stunden im Büro hinterm Schirm, leicht müde. Kannst mir das jetzt mal in anderen Worten erklären, ich kapiers nicht und das interessiert mich jetzt schon auch. Danke!

koehlerbv:
Eigentlich ist die Sache ganz einfach, nur Iris (jo, das stammt noch aus der zeit) hat es aus meiner Sicht unnötig verkompliziert:

Du löschst ein Dokument. Zurück bleibt lediglich ein deletion stub (wer / wann gelöscht, UNID etc., aber nichts, womit man das Dokument wieder hervorzaubern könnte. Um hier falsche Erwartungen gleich zu dämpfen ...).
Nach dem oben genannten Intervall werden die deletion stubs aus der DB gekippt, um diese schlank zu halten.
Wenn nun aber erst nach Ablauf dieser Frist jemand wieder repliziert, dann sieht die Gegenseite (mangels des stubs) dieses dort längst nicht mehr vorhandene Dokument als "neu" an, und die "schöne Leich'" feiert fröhliche Urständ, sprich: Wird der DB wieder hinzugefügt.

Eine üble Sache, wenn man mit sowas nicht rechnet oder diesen Zusammenhang nicht kennt: Der Effekt ist ggf. "shocking". Notes geht hier einfach von regelmässiger Replikation aus ...

Wenn man das Verfahren aber durchschaut hat (wie gesagt - das wurde adminunfreundlich versteckt), kann man sich das sogar zu Nutze machen (massenhaft falsche Löschungen: CutOff-Date auf 0 herabsetzen, den Server zum Begreifen animieren und dann mit dem Backup replizieren ...).

So, und nun schleich Dich lieber heim nach so langer Arbeit - ich wünsche Dir einen schönen Feierabend (den ich mir jetzt auch gönne)!

Bernhard

mcilly:
Sodale, frisch und munter zurück, auf in einen neuen Admintag!  O0

Danke Bernhard, das ist gut erklärt. Was ich mich jetzt noch frage ist, wann und wo entstehen die Stubs? Wenn ich ein Dok lösche, dann wandert es ja mal auf Grund meiner Soft Deletions in den Papierkorb, gibts da auch schon Stubs, oder erst wenns aus dem Papierkorb verschwindet?

Navigation

[0] Themen-Index

[#] Nächste Seite