Alte Daten und Löschungen beim Replizieren verhindern?

[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! 

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?

[Hive]

Den Stub gibs erst wenn das Dok wirklich gelöscht wird. Mit Notespeek kann man diese auch einsehen, deren Anzahl bei einer aktiven Datenbank mal schnell ein paar 100.000 werden können.

KAI

[mcilly]

Ok, alles klar, ich hab grad mal aktuell 22317 Stubs in meiner DB. Wenn ich sie vom Server auf lokal kopiere, dann sinds sofort 0. Wenn ich nun in den Replizierparametern nichts drinnen stehen habe, wann löscht er dann die Stubs? Weil nach Bernhards Beschreibung ist es die angegeben Zahl durch 3 in Tagen. Wenn aber keine Zahl drinnen steht?

[Glombi]

hier noch was von IBM dazu

http://www.ibm.com/support/docview.wss?rs=203&uid=swg21110117

http://www-1.ibm.com/support/docview.wss?uid=swg21095683

Andreas

[Hive]

Hast du Sie kopiert oder repliziert? Auf der Console kannst du die Stubs übrigens mit 'show Database <DB Name>' zumindest in der Anzahl auch sehen.

KAI

[mcilly]

@Steve_O: Notes Kopie, das wirds wohl sein. Und danke für den Tip mit dem sh database, man kann noch so viel lernen und es wird immer zu wenig sein 

@Andreas: Danke auch für die Links

[Steve_O.]

Roman, wir hatten das Vergnügen in einem anderen Post.. 

Hiermit schiebe ich deine Dankbarkeit virtuell an KAI weiter!!

[LisaS]

@Bernhard:
Danke, für die ausführliche Erklärung. Mir bleibt wohl nicht anderes übrig die 90 Tage auf einen realistischen Wert zu erhöhen.
Im aktuellen Fall sind hunderttausende von Dokumenten wieder in die DB gekommen.
Zum Glück habe ich nen kleinen Agent, der die Dokumente anzeigt.
Das sind aber trotzdem zwei Tage Arbeit alles wieder grade zu biegen.
@all:
Danke für die rege Diskussion, das Thema scheint ja nicht nur mich zu quälen.

Gruß
Hitcher

[mcilly]

Roman, wir hatten das Vergnügen in einem anderen Post.. 

Hiermit schiebe ich deine Dankbarkeit virtuell an KAI weiter!!

Uuppss, achja, thx. 

Sodale, hab nun in meiner Mipau beim Salat die beiden KB Artikel gelesen. Feine Ware, vor allem die Möglichkeit, den Purge Interval auf 0 zu setzen und dann auch noch den Haken zu aktivieren. Nichts für Administratoren mit Verantwortungsgefühl, weil dann werden alle Dokumente in der DB gelöscht.

Nur eines ist mir nicht verständlich, der 2te Artikel beschreibt 2 Methoden zum sofortigen Löschen der Stubs, nur was bringt das? Ich sehe keinen Sinn darin, meine Stubs einmalig sofort zu löschen.

[Hive]

Nur eines ist mir nicht verständlich, der 2te Artikel beschreibt 2 Methoden zum sofortigen Löschen der Stubs, nur was bringt das? Ich sehe keinen Sinn darin, meine Stubs einmalig sofort zu löschen.

Es gibt ein paar Gründe, z.B.

100.000 verbrauchen 20 MB Speicherplatz (ungefähr den genauen Wert hab ich vergessen).

Mehr als irgendwas 100.000 Deletion Stubs können zu einem eigenartigen DB verhalten führen z.B. das hier:
IBM zitat:
It was found that the error "Invalid or non-existent document" is caused by not handling the copying of a large (>64K) RRV bucket array. This can happen in databases that contain a large number of documents, including deletion stubs.

Datenbanken die über keine Replik verfügen brauchen Sie zudem nicht.

Außerdem ist der Tag lang und wenn einem langweilig wird, kann man sich mit solchen Tätigkeiten über Wasser halten 

[mcilly]

Danke alles klar. Bis auf den letzten Punkt mit dem langen Tag, das Problem hatte ich die letzten 6 Jahre nicht. Lang war der Tag schon, aber eben nicht in dem Sinne wie du das meinst ... 

[Hive]

War auch eher sarkastisch gemeint ..  wenn man zu zweit mehr als 2000 User und 40 Server in Betrieb halten darf .. hat man nicht wirklich Zeit ..

KAI