Gelöschte Dokumente durch alte Replik zurückgeschrieben...

[TomKet]

Hallo Forum,
ich hab hier gerade ein riesen Chaos.
Ein Kollege hat gestern mit seinem Notebook repliziert, scheinbar ist die Replik jedoch sehr alt gewesen, jedenfalls habe jetzt ca. 15000 Dokumente wieder in der Datenbank die zwischenzeitlich bereits gelöscht wurden.
Ich habe das Problem erst heute morgen bemerkt, (Gestern wurden auch einige Agentenläufe gestartet, die Dokumente aktualisiert haben - daher standen sowieso viele Dokumente zur Replikation an und ein Großteil der Aussendienstler hat bereits repliziert. Das heisst das ich diese "Datensatzleichen" bereits auf einigen Notebookrepliken habe.
Ich möchte jetzt die "Datensatzleichen" in der DB in einer Ansicht aufführen und diese löschen.
Einige Dokumente konnte ich anhand des Typs identifizieren, diese haben bei den Dokumenteneigenschaften (auf dem ersten TAB) einen Timestamp bei Hinzugefügt (in dieser Datei) stehen.
Wie kann ich in einer Ansicht auf diesen Wert zugreifen.
Im Feld $Revisions wird er nicht angezeigt.
Hat jemand ausser meiner Idee mit der Ansicht einen Geistesblitz wie ich die zuvielen Dokumente rauswerfen kann?
Eine neu Verteilung der Replik (ich meine die Sicherungsreplik von Gestern Morgen) kann ich aus diversen Gründen nicht an die Kollegen im aussendienst verteilen, daher die Idee die Dokumente zu identivizieren und dann zu löschen.

Danke für Eure Beiträge
Gruß Thomas

[Semeaphoros]

An diesen Wert kommt man leider nicht ran. 

[TomKet]

Hallo Semeaphoros,
auch icht via Script und dann vielleicht in einen Ordner verschieben.
Der Wert wird doch angezeigt - ergo müßte er doch auch irgendwo gespeichert sein.
Das man da gar nicht rankommen soll kann ich bei Notes nicht wirklich glauben
Hast Du vielleicht noch irgend eine andere Idee?

Gruß Thomas

[yes2002]

Hi,
hast Du eine akutelle Datensicherung einer der betroffenen DBen? Dann kannst Du per script die Dokumente vergleichen und ggf. via script die Dok. wieder löschen.

Noch ein Vorschlag, bin mir nicht ganz sicher (kann es gerade auch nicht checken), lege doch mal eine Ansicht an und lasse Dir in einer Spalte den Wert @modified ausgeben. Könnte das nicht das Datum der beschriebenen Replikation sein? Würde auch noch nach dem Wert @accessed schauen. Vielleicht hilft es Dir?
Gruß

[diali]

schau mal hier. Da könnte etwas dabei sein.

[Semeaphoros]

An den Wert kommt man weder mit Script noch mit C-API heran. Die von diali genannten Funktionen geben andere Werte zurück, an die "Verwaltungsdaten" des aktuellen, physischen Files gibt es nirgends irgend ein Herankommen. Ich habe gerade vor ca. 14 Tagen einen Enhancement-Request einiger Kollegen unterstützt, die die Offenlegung dieser Eigenschaft wünscht.

[koehlerbv]

Aus meiner Erfahrung bleibt Dir wirklich nur der Weg über die letzte Sicherungskopie. Diese bietet Dir aber sehr gute Chancen auf vollständige Heilung:

Vergleiche aus der jetzt "korrupten" DB jedes Dokument mit der Sicherungs-DB, mache dies via GetDocumentByUNID. Wenn ein Dokument nicht gefunden wurde: Ist es erstellt vor einem bestimmten Datum (dann ist das solch ein aus Versehen zurückrepliziertes Dokument), dann entferne es. Ist es neuer, dann wurde es erstellt nach Anfertigen des Backups.

Da ich von Natur aus zu extremer Vorsicht neige: Mache dies zunächst in einer abgeschotteten Umgebung und nicht produktiv, um nicht ggf. weitere Fehler hereinzubringen.

Weiterhin: Wenn in einer Applikation Leute solch weitgehenden Rechte haben (beliebig Dokumente erstellen, was ja erforderlich, um altes Zeugs zurückzureplizieren), dann musst Du für diese DBs die Replizierparameter erheblich restrikter handhaben als dies Notes als Default vergibt. Die Einstellung "Dokumente entfernen, die seit xx Tagen nicht verändert wurden" musst Du viel, viel höher setzen als 90 Tage. Ist der Haken dort nicht gesetzt, werden - und das halte ich für eine ganz üble Falle ! - nach einem Drittel der angegebenen Zeit die Deletionsstubs auch gelöscht, das heisst, dass dann - wie in Deinem Fall - Dokumente zurückrepliziert werden können aus eienr Uralt-Replik.

Good luck ! Was makaber klingt - Du hast den Ärger prompt am Freitag vor dem Start ins Wochenende bekommen.

Bernhard

[TomKet]

Erstmal ein schnelles Danke für die Beiträge,
ich lasse gerade einen Script-Agenten bauen, der die "Datensatzleichen" anhand der DOC-ID raussucht und löscht. Das ist wohl die eleganteste Löschung, bevor ich mir jetzt noch das Wochenende Vollständig verderbe!

Grundsätzlich haben wir bei allen Notebook Usern die Replikation periodisch aktiviert. Allerdings haben wir ganz offensichtlich dieses eine vergessen.

Der User hat mit dem Notebook mit notes noch nie offline gearbeitet, sonst wäre ja bereits mal aufgefallen, das seine Daten nicht aktuell sind.

Naja ich versuche es positiv zu sehen und halte mal fest, das uns das in der Art nicht noch einmal passieren wird.

Danke für die Beiträge und schönes Wochenende - bei mir wird es wohl noch etwas dauern bis ich hier das ThinkPad zuklappen kann.

Munter bleiben
Thomas

[Semeaphoros]

Aber bitte nicht anhand der Notes-ID sondern anhand der DocumentUNID, sonst klappt das nicht wirklich. DOC-ID sagt leider nicht, welche von beiden Du meinst .....

[koehlerbv]

Hallo Thomas,

ich wünsche erfolgreiche Verrichtung ! Mich hatte es (letztlich indirekt) auch schon mal erwischt: Die IT-Abteilung arbeitete mit Images auch in Bezug auf lokale Notes-DBs. Die wichtigsten wurden eben in einer (irgendwann sehr alten  ) Version von CD auf neue Notebooks gespielt. Passiert ist da nie was, weil es sich nur um DBs handelte, in denen "Otto-Normaluser" keine Erstellrechte hatte. Das ging solange gut, bis ich ein neues Notebook bekam ... Die Anzahl gelöschter Doks, die ich mit meinen Rechten dann "neu" erzeugt habe, hielt sich aber derart in Grenzen, dass sie noch durch die Ungelesen-Markierungen identifiziert und manuell entfernt werden konnten.

Auch wenn es Dir jetzt das Wochenende verzögert, denke ich, dass dieser Vorfall durchaus einen Vorteil bietet - der eine oder andere wird daraus eine neue Erkenntnis gezogen haben.

Viel (und schnellen) Erfolg wünscht
Bernhard

[koehlerbv]

Aber bitte nicht anhand der Notes-ID sondern anhand der DocumentUNID, sonst klappt das nicht wirklich. DOC-ID sagt leider nicht, welche von beiden Du meinst .....

Ich denke mal, statt "Notes-ID" meinst Du NoteID, oder ? Da produktive und Backup-DB physikalisch verwandt sind (und keine Notes-Kopien sind), würde auch dieses Verfahren klappen (auch wenn ich davon die Finger lassen würde - bin halt in solchen Sachen extrem vorsichtig), auch wenn ich ganz bewusst auf die UniversalID verwiesen habe.

DOC-ID: Vielleicht hat Thomas'DB genau solch ein eineindeutiges Item. Wenn Du schon spekulierst, hast Du definitiv eine Alternative vergessen.

Bernhard

[TomKet]

Um die Diskussion abzuschliessen, ich meinte die UniversalDocID der betreffenden Dokumente.

Aber ich programmieren den Agenten auch nicht selber sondern habe damit unserer Systemhaus beauftragt - die können das viel besser als ich
Ich habe heute morgen erstmal die Replikation der DB ausgeschaltet, und wollte das jetzt noch schnell übers Wochenende laufen lassen -  habe jetzt aber gerade festgestellt, das unser Admin die "saubere" Replik auf ein Laufwerk gesichert hat an das ich gar nicht ran komme  also kann ich den Agenten eh erst Montag laufen lassen, weil unser Admin sich schon ins Wochenende verdrückt hat.

Tja soviel dazu - ich werde dann jetzt auch um 16.00 in meinen Zug steigen, heute kann ich nix mehr machen.

Schönes wochenende Euch allen.
Thomas

 

[Semeaphoros]

Bernhard, natürlich meine ich die NoteID - es ist definitiv zu heiss hier ......