einzelne Replikatonselemente löschen?

[immanuel]

Hallo Zusammen

Ich würde gerne in einer Datanbank die Informationen für eine Replikation löschen. Etwas genauer: Ich erstelle ein Dokument und lösche es darauf wieder, möchte aber nicht dass diese beiden Änderungen repliziert werden. Kann ich diese Replikationsinformationen löschen, ohne dass ich gleich die ganze Replikationshistory löschen muss?

Vielen Dank für eure Antworten!

Grüsse
Manuel

[koehlerbv]

Nein, das ist nicht möglich.

Bernhard

[Glombi]

Evtl. das Cut-Off Datum auf die aktuelle Zeit - Datum + Uhrzeit setzen, damit alle Deletion Stubs gelöscht werden.

Andreas

[koehlerbv]

Das dürfte aber katastrophale Folgen haben: Löschungen werden nicht an Repliken übertragen, aber diese können in dieser DB bereits gelöschte Dokumente munter wieder zurückschreiben.

Bernhard

[Glombi]

Klaro, das muss Manuel abwägen...

Deletion Stubs aus anderen Repliken werden dann aber nicht als normale Dokumente wieder zurückgeschrieben.

Aus meiner Sicht dürfte es keine Katastrophe verursachen. Oder habe ich auf die Schnelle was übersehen?

Andreas

[immanuel]

Leider habe ich keinen Zugriff auf die Ziel Replik. Konkret: Ich habe in einer DB ein Dokument erstellt und dann wieder gelöscht. Auf der Zielreplik habe ich aber keine create document Rechte. Wenn die Fehlermeldung nicht noch wochenlang im Log erscheint, kann ichs ignorieren. Wisst ihr gerade wie lange der Server versucht fehlerhafte Replikationsversuche (in diesem Fall wegen zuwenig Rechte) zu wiederholen?

Grüsse
Manuel

[koehlerbv]

Deletion Stubs aus anderen Repliken werden dann aber nicht als normale Dokumente wieder zurückgeschrieben.

WENN die Löschungen schon in der anderen Replik sind, Andreas. Wenn ! Wenn die Docs dort aber noch existieren (hierbei auch seltener replizierende lokale User beachten), dann feiern die Dokumente fröhliche Urständ  Selber schon erlebt ...

@Manuel: Der Server wird das solange wiederholen, bis das Replication cutoff-Datum, das in den Replizierparametern steht, überschritten wird. Wenn das aber mal gelöscht wird oder das ganze Replizierprotokoll, dann geht das wieder los.

Bernhard

[immanuel]

@Manuel: Der Server wird das solange wiederholen, bis das Replication cutoff-Datum, das in den Replizierparametern steht, überschritten wird. Wenn das aber mal gelöscht wird oder das ganze Replizierprotokoll, dann geht das wieder los.
Bernhard

Dan müsste ich ja 365 Tage warten... Was passiert wenn ich die Replications History lösche - das sollte doch funktionieren oder?
Ich habe eine Dokument erstellt und wieder gelöscht - diese beiden Änderungen müssten doch beim Löschen der Repl History verschwinden, oder?

Grüsse
Manuel

[koehlerbv]

Nein. Dann baut der Server die wieder auf, in dem er jedes Dokument checkt - es passiert also genau das Gegenteil.

Bernhard

[immanuel]

Ist es nicht so, dass der Sever dann jedes Dokument vergleicht und überprüft. Auf unserem Server exisiert ja nur noch der Deletion Stub + Anweisung,  abgesehen von der Information das Dokument in der Zielreplik zu erstellen.

Grüsse
Manuel

[Semeaphoros]

Eben, da ist ja nur noch der Deletion-Stub vorhanden, also so wie Andreas beschrieben hat, mit dem Cutoff-Date dafür sorgen, dass die Deletion-Stubs entfernt werden, dann ist Dein Problem gelöst.

[koehlerbv]

Und ich sachs nochmal: Dieses sollte man nur machen, wenn mit allen Servern repliziert wurde (und damit alle Löschungen durchrepliziert wurden) und auch alle lokalen Repliken auf dem aktuellsten Stand sind, deren Benutzer das Recht haben, neue Dokumente auf dem Server anzulegen. Sonst erlebt Ihr evtl. eine Reinkarnation von Dokumenten, die ihr längst gelöscht glaubtet.

Bernhard

[Semeaphoros]

Naja, in diesem konkreten Fall ist das nicht soo schlimm, wenn man das Cutoff-date manipuliert, die Stubs somit zum Verschwinden bringt und dann das Cutoff-Date wieder zurücksetzt, jedenfalls wenn die Situation wirklich so konkret ist, wie Manuel es zu schildern scheint.

[koehlerbv]

Das ändert aber nix an meiner Aussage, Jens. Sind die Deletion stubs weg, fehlt dann auch die "Hau wech, den Schiet"-Info. Hat irgendeine Replik irgendeine Löschung, die auf dem Server seit der letzten Replikation stattgefunden hat, ist danach das Dokument wieder auf dem Server.
Manuel kann die Gefährdung sicherlich am besten abschätzen, ob sowas passieren kann.

Bernhard

[Semeaphoros]

Bernhard, überleg mal, Du sagst das jetzt zum dritten mal. Niemand hat bisher behauptet, Deine Aussage sei falsch. Warum? Das tut nicht not.

[Glombi]

Leider habe ich keinen Zugriff auf die Ziel Replik. Konkret: Ich habe in einer DB ein Dokument erstellt und dann wieder gelöscht. Auf der Zielreplik habe ich aber keine create document Rechte. Wenn die Fehlermeldung nicht noch wochenlang im Log erscheint, kann ichs ignorieren. Wisst ihr gerade wie lange der Server versucht fehlerhafte Replikationsversuche (in diesem Fall wegen zuwenig Rechte) zu wiederholen?

Grüsse
Manuel

In so einem Fall kannst Du auch folgendes machen: Erstelle eine Kopie (via Notes) machen (dann werden die Deletion Stubs) nicht mitgenommen und anschließend die Replik-ID ändern. Im Sandkasten gibt es glaube ich ein Tool dafür.
Der Effekt wäre aber der gleiche wie mit dem Cut Off Datum.

Die Reinkarnation erlebst du dann vielleicht auch 

Andreas

[Glombi]

Hier noch was aus der KBASE:

Title:   
   How to Purge Document Deletion Stubs on the Server Immediately
Product:   Lotus Domino  >  Lotus Domino Server  >  Versions 5.x, 4.6x, 4.5x
Platform(s):   Platform Independent
Date:   07.05.2003
Doc Number:   1095683



Problem
A customer would like to purge all of the document deletion stubs on the server database now, instead of waiting for the set purge interval.  How can this be done?


Solution
There are two options.

Option #1:

All document deletion stubs in a database can be purged by selecting File, Replication, Settings and setting the "Remove Documents Not Modified in the Last" setting to 0 days.  Once this is done, click OK and close the database.  Open the database again to purge the deletion stubs immediately.  Next, change back the "Remove Documents Not Modified..." setting to 90 days.

IMPORTANT:  If you place a checkmark next to "Remove Documents Not Modified in the Last" setting, and place a "0" in the Days field, all of the documents will be deleted from the database.  Do not place a checkmark in that box; only change the number of days setting to "0" (see Figure 1 in the Supporting Information section below for an example of this).

Once this is done, you can return this setting back to the original number.


Option #2:

All document deletion stubs in a database can be purged by setting the cutoff date ahead two days from the current date.  Once this is done, the deletion stubs are purged immediately.  To do this, select File, Replication, Settings, Other, and set "Only replicate incoming documents saved or modified after."

Be sure to replace the 2 days ahead date immediately once the deletion stubs have been purged.

WARNING:  If the "Remove Documents Saved More Than XX Days Ago" option is enabled in a database's replication settings when the cutoff date is set ahead, all documents saved before the cutoff date will be removed from the database.  Notes behaves this way because both the cutoff date and "Remove Documents..." feature are designed to save space in local replicas.  The cutoff date sets the maximum age for documents to be received by the local replica.  When the "Remove Documents..." option is enabled, Notes automatically removes (leaving no deletion stub) any document saved before the cutoff date, ignoring any interval specified in the "Remove Documents..." option.

Depending upon the Notes platform, it may also be necessary to set the purge interval to one day as well as setting the cutoff date ahead.  This is not required for all Notes platforms.  On early 3.x versions of Notes for UNIX platforms, the Cutoff Date option is not available, and the purge interval cannot be used to purge deletion stubs immediately.

You can see the approximate number of document deletion stubs in a database by adding up all of the shared fields and all of the documents, and then subtracting this number from the total number of documents shown, when a new replica of the database is created.

To view deletion stubs, Notespeek can be used.  Notespeek is available on the Lotus Developer Domain website (in the Sandbox).

Supporting Information:

This information does not apply to deletion stubs for design elements (eg. forms, view or macros).  Refer to the document titled "Removing Design Element Deletion Stubs From a Database" (#132699 ) for additional information.

BITTE DIE WICHTIGEN HINWEISE IN DEM ARTIKEL BEACHTEN !!!

[Glombi]

Hier noch etwas aus der KBASE, das Bernhard bereits hier mehrfach betont hat - und das wichtig ist zu wissen!

Title:   
   Deleted Documents are Reappearing After Replication
Product:   Lotus Notes  >  Lotus Notes  >  Versions 5.x, 4.x
Platform(s):   Platform Independent
Date:   13.09.2004
Doc Number:   1098733


Problem
Deleted documents reappeared after replication. How can this happen?



Solution
Deleted documents can reappear after replication under one of the following circumstances:

1. The purge interval  is more frequent than the replication schedule.
If a document is deleted and the deletion stub is purged before replication, the other replica copy does not have the information that the document has been deleted and replicates the document just like a new document.

2. A document was modified on one database replica after it was deleted on another replica copy.
If a document gets modified on one replica copy of the database after it was deleted from another replica, the modified date on the existing document is newer and would overwrite the deletion stub (there is no replication conflict with deletion stubs, the document just reappears).

3. A document was modified more often than the deleted document
If a document gets modified more often on a replica copy than of the database with the deleted document, it will come back after replication even if it was deleted after the last modification. This
is because the sequence number (number of modifications) takes precedence over the modified
date - and since there can't be a conflict with a deletion stub it reappears after next replication.

[Glombi]

Und last but not least

Title:   
   Q&As About Replication Purge Intervals and Cutoff Dates
Product:   Lotus Notes  >  Lotus Notes  >  Versions 6.x, 5.x, 4.x
Platform(s):   Platform Independent
Date:   13.09.2004
Doc Number:   1110117


Problem
What information is available about replication cut-off dates and purge intervals?



Solution
In these Q&As, the following terms will be used:

Purge Interval = 1/3 of the value found in the "Remove Documents Not Modified in the Last n Days" field (found in the Space Savers panel of the Replication Settings dialog box).  By default, the Purge Interval is 1/3 of 90 days, or 30 days.

Cutoff Date (Purge Date) = the value in the "Only Replicate Incoming Documents Saved or Modified After" field (found in the Other panel of the Replication Settings dialog box).


Q:  What is the Purge Interval?  How does it relate to replication?

A:  The Purge Interval is the number of days that stubs of deleted documents remain in the database before being permanently and completely removed.  Every time a database is opened, the purge function checks the Purge Interval to determine whether or not to activate a purge.  The purge function keeps track of when the database was created and of the date of the last purge.

Every time a database is opened, the purge function checks to see how long it has been since it was last run.  If it has not been run for at least 1/3 of the Purge Interval, it activates and purges all deletion stubs that are older than the Purge Interval.

For example, if you created a database on day 1 whose purge threshold was set at 90, on day 30 the purge function would check to see if there were any deletion stubs older than 90 days.  If there were, it would purge them.  It would next check on day 60, then on day 90, then on day 120, etc.  The first time that the purge could actually happen would be on day 120 (on day 90 there could not be any deletion stubs older than 90 days, only equal to 90 days).  It would then purge any deletion stubs that were older than day 30 (120-90=30).


Q:  How is the Purge Interval calculated?

A:  The Purge Interval is 1/3 of the days in the "Remove Documents Not Modified in the Last n Days" field (30, by default).


Q:  What criteria is used to calculate the date placed in the Cutoff Date field and why is a value in this field returned once it has been deleted?

A:  The Cutoff Date is calculated based on the Purge Interval; this is true whether or not the "Remove Documents Not Modified in the Last n Days" box is checked.

When the Cutoff Date is deleted, it repopulates itself based on the value of the "Removed Documents Not Modified..." field.  The Cutoff Date is set to n days ago.  So, by default, on September 1, 1996, the Cutoff Date will be June 1, 1996 (90 days earlier).  If the Cutoff Date is deleted, it will remain blank until October 1, 1996, when it will be set to July 1, 1996


Q:  A user can choose to have documents and deletion stubs automatically deleted (purged) from their Notes database by setting the "Remove Documents Not Modified..." field.  How is this value actually enforced by Notes?

A:  A purge occurs only once per database at the purge interval time.  Every time a database is opened, a check is made to see if any documents meet the purge criteria and, if so, the purge is performed, under the following circumstances:

1. Whenever a user double-clicks the icon of a database.
2. On all of the Name & Address Books (values in the NAMES= line of the NOTES.INI file), whenever it is programmatically opened for the first time, say, by a mail address lookup.
3. On the log database (LOG.NSF) and statistics database (STATREP.NSF), whenever they are programmatically opened.
4. On the server, on all databases, when the UPDALL task is run.
5. Whenever a change is made to the Purge Interval in the Replication Settings.

If the Purge Interval is set to 0 in the Replication Settings, the deletion stubs will be purged immediately.  Any change to this field will initiate a purge event when the user clicks OK.  This is true regardless of the location of the database (local or on the server).


Q:  Which time field is used when deciding which documents to purge?

A:  In the File, Document Properties dialog box, it is the time marked as "Modified."  Programmatically, it is the "SequenceTime" field in the document's Originator ID (OID, identifies a particular revision of a note, regardless of location.  In other words, every replica of a note has the same OID, but the OID changes when the note is modified).