Best Practices > Diskussionen zu Best Practices

Best Practice-Artikel zum Umgang mit zurückreplizierten Löschungen ?

<< < (2/3) > >>

Cookie:

--- Zitat von: Driri am 02.10.09 - 13:28:16 ---Okay, ich wage mal einen ersten Versuch. Ich werde allerdings die nächsten Tage nicht dazu kommen, Anmerkungen, Korrekturen, etc. umzusetzen (URLAUB !!!  :))
--- Ende Zitat ---

Du kannst ganz beruhigt in den Urlaub fahren oder sein, dass Ding funktioniert hervorragend und hat mir viel Arbeit abgenommen.

Vielen Dank.

Gruß

Driri:
@Cookie :

Freut mich  :)


@All :

Bin wieder dahaa ! Gibt es Anmerkungen, Verbesserungsvorschläge, Kritik, Gemeckere, etc. ?

LN4ever:
Lieber Driri,

nicht sehr viel umständlicher geht es "zu Fuß" mit einer nicht-hierarchischen (!!) Ansicht, die in der ersten Spalte nach @NoteID sortiert ist und als zusätzliche Spalten mit sekundären Sortierkriterien @Created und @Modified enthält.
Zusätzlich empfehle ich einen DELETE-Button, der das Datenbankscript-Event QUERYDOCUMENTDELETE umgeht, weil er als Agent ausgeführt wird.

In dieser Ansicht stehen die per "Altreplikation" hereingekommenen Dokumente nämlich dicht beieinander, weil Notes die NoteID als Hexadezimalzahl aufsteigend mit jeweils einer Lücke von 4 erstellt.

Wenn man dann die "Verdächtigen" in einen Ordner verschiebt, der seine Gestaltung aus dieser Ansicht übernimmt, kann man mit den sekundären Sortierkriterien die guten von den bösen Geistern trennen.

Normalerweise werden solche Dokumente ja nicht über weitere Serverrepliken gestreut, weil die existierenden Replizierprotokolle das verhindern. Dann hilft oft einfach das Abwarten der nächsten Replikation. Wenn man dann auf dem nicht infizierten Server in den Ordner schaut, so findet man nur die "guten" Geister, die man mit einem Schlag aus dem Ordner löschen kann. Dann noch ein Replikationsintervall abgewartet - und die schlechten bleiben auf dem infizierten Server übrig und können gelöscht werden.

In meinen großen Datenbanken habe ich immer eine solche Ansicht mit drin - und die funktioniert auch plattformunabhängig. Und manuell eingreifen muß man ja auf jeden Fall.

Aber vielen Dank für die ausführlichen Erklärungen. Die helfen vielen bestimmt weiter.

P.S.: Nicht nur alte lokale Repliken machen dort Ärger; ein ganz beliebter Anlaß für das Auftauchen dieser Dokumente ist immer das Nichtvorhandensein eines Replizierprotokolls, sprich: Serverumzüge von Datenbanken mit Initialreplikation oder auch (ohne Serverumzug) das explizite Löschen von Replizierprotokollen. Man darf den Admins vor einem Serverumzug also durchaus dringend ans Herz legen, VOR dem Umzug die Dokumentzahlen von Repliken der Datenbanken miteinander zu vergleichen. Wenn es eine solche Konstellation gibt, dann ist der Pfeil, der die Datenbank treffen wird, immer schon abgeschossen. In vielen Fällen ist er nur in der Luft und hat sein Ziel noch nicht erreicht.

Gruß

Norbert

Driri:
Hallo Norbert,

danke für die Anmerkungen. Ich überlege mir mal, wie ich das mit einbauen kann.  :)

dh-paule:
@diri @LN4ever

DANKE für die sehr gute Erklärung der Problematik und für das Aufzeigen einer Lösung.
Das hat mir soeben ...zig Stunden gespart. Danke, Danke , Danke

Im vorliegenden Fall waren alle "Geister" in einem klar umrissenen Zeitfenster von ca. 5 Minuten auf dem Server aufgetaucht. Deren Identifikation verlief recht einfach in dem ich das Fenster mit DocumentProperties aufgerufen habe, und mir dort alle 4 Daten anzeigen lies. Dann einfach durch die aufgelisteten NoteID scrollen bis man die Übeltäter findet und ab in den Folder damit. Über die Replikation wurden dann noch die "guten" von den "schlechten" getrennt und schwupps: so plötzlich wie die Geister erschienen waren sie auch wieder verschwunden (entfernt)

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete