Replikationsproblem: lokale Daten fehlen in Server-Replik?!

[Sascha Seipp]

Moin allerseits,

ich hab hier gerade ein Client-Problem, bei dem ich auf dem Schlauch stehe: Notes-Client 8.5.3 FP6

Ein User arbeitet auf einem Notebook auf einer lokalen Replik (mit "Hintergrundreplizierung" alle 10 Minuten, keine Managed Replica), außerdem mit einem VMware View-PC direkt auf der Server-Replik und per Good mit dem iPhone ebenfalls (indirekt) mit der Server-Replik seines Postfachs.

Soweit alles schön - nun stellt er zwischen den Jahren, von zuhause per VM View arbeitend, fest, daß ihm Mails / Kalendereinträge fehlen bzw. er welche eigentlich schon bearbeitet hat. Auch in Good sieht das so aus. Nur in seiner lokalen Notebook-Replik ist alles da und in Ordnung.

Heute habe ich mich dann mal remote bei ihm aufgeschaltet und mir das zeigen lassen: tatsächlich hat seine Notebook-Replik einen neueren Stand als die Server-Replik, obwohl die Replikation auf den ersten Blick fehlerfrei durchläuft. In den Replikationseinstellungen auf beiden Seiten kann ich nichts Verdächtiges sehen.
Um das etwas besser prüfen zu können, habe ich mir a) eine Notes-Kopie der lokalen, korrekten Replik gemacht und b) eine Notes-Kopie der "falschen" Server-Replik. Dann habe ich a) die Replica ID von b) gesetzt, damit die beiden zueinander wieder Repliken sind. Und dann habe ich repliziert. Im ersten Anlauf war das ratzfatz fertig und hat gar nix repliziert, dann habe ich es nochmal von Server-Seite angestoßen (also mit markierter Server-Replik), und dann wurden dann wohl 800 Dokumente Richtung Server übertragen (welche auch immer) - der Kalender zwischen den beiden Repliken sieht aber genauso, deutlich unterschiedlich aus wie auch im Original.

Bei genauerer Betrachtung scheint es so zu sein, daß eingehende Mails sowohl auf Server-Seite als auch lokal vorhanden sind (was mich beruhigt, denn sonst wüßte ich nicht, wo die lokal herkommen sollten, wenn sie auf dem Server nicht da wären), aber von ihm gesendete Dokumente bzw. von ihm im Kalender eingetragene Termine / Besprechungen sind nur lokal vorhanden und werden nicht auf den Server repliziert.
Er hat übrigens (Altlast) Manager-Zugriff auf sein Postfach, ebenso wie alle Server.

Ich kann Dokumente identifizieren, die es definitiv nur auf einer Seite (lokal) gibt, wo aber auf der anderen Seite kein Deletion Stub und kein anderes Dokument dagegensteht. Leserfelder sind keine gesetzt, daran scheint es auch nicht zu liegen. Und es gibt auch keine übermäßigen Deletion Stubs, also rein replizieren und gleich wieder rauslöschen scheint es auch nicht zu sein.
Auch in Sachen Space Savers oder Replikations-Formel kann ich nichts finden.

Ich habe gerade keinen Plan, was hier abgeht, und wäre für Ideen dankbar!

Ciao
Sascha

[Tode]

Was sagt der ScanEZ Replication Auditor zu dem Thema (ihr habt das ja im Einsatz, wenn ich das aus dem anderen Thread richtig in Erinnerung habe)...

[Ralf_M_Petter]

Häufigste Ursache mal mit der Uhrzeit bzw Datum gespielt. Hatten wir schon bei einigen Benutzern.

[Axel]

Hast du auf der Replikatorseite mal geprüft ob die Replikation für beide Richtungen eingestellt ist, also Dokumente vom Server empfangen und an den Server senden?

Ich hatte schon öfters den Fall, das Notes das "eigenhändig" verändert.

Axel

[Sascha Seipp]

Hallo allerseits,

@Axel: hab ich geprüft, stimmt so.

@Ralf: Denke nicht - zumindest bei meinem Test-PC stimmt die Uhrzeit, und auch die am Server. Und die fraglichen Dokumente haben auch keine ungewöhnlichen Timestamps.

@Torsten: Ich seh das doch richtig, daß der Replication Auditor auflistet, was bei der nächsten Replikation passieren sollte, richtig? Nach dessen Aussage müßten 261 Dokumente neu angelegt werden (siehe Bild) - passiert nur leider nicht. Wenn ich mir ein paar von den fraglichen Dokumenten anschaue, taucht deren UNID bei den "Differences" im Replication Auditor gar nicht auf.

Kann man die Replikation noch irgendwie tiefer debuggen? So im Sinne einer Meldung von "Dokument xy angefaßt und nicht weiter behandelt weil.."

Ciao
Sascha

[Tode]

das heisst, die "fraglichen" Dokument tauchen in dem Screenshot von Dir NICHT unter Push Create auf?

[Sascha Seipp]

Moin Torsten,

ich hab jetzt von den fraglichen Dokumenten nur wenige exemplarisch rausgepickt. Mir zwar so, als hätte ich diese beim letzten Mal in der Replication Auditor-Liste nicht gesehen, das war jetzt aber nicht so: alle der ausgewählten Meetings und gesendeten Mails finden sich entweder unter Push Create oder unter Push Update. Vielleicht bin ich beim letzten Mal mit der Liste der Unterschiede nicht weit genug in die Vergangenheit gegangen.
Nur, wenn ich die Replikation dann durchführe, werden die entsprechenden Dokumente auf der anderen Seite nicht erstellt oder upgedatet.

Ciao
Sascha

[Tode]

Dann geht jetzt die Analyse weiter: Du nimmst jetzt alle Dokumente im Audit und erstellst aus diesen eine eigene Collection in scanEZ... irgendetwas haben die Dokumente gemeinsam, so dass sie nicht repliziert werden: Erstell / Änderungsdatum in der Zukunft, Leserfelder, Replikationsformeln, irgendetwas... Und das musst Du jetzt rausfinden...

[Sascha Seipp]

Hab schonmal eine erste Erkenntnis, die mich aber auch etwas irritiert: es sind ja wie gesagt einige Dokumente, die bei "Push Create" aufgeführt werden, aber auch einige bei "Push Update". Dazu finde ich dann auch ein äquivalentes Dokument in der anderen Replik, also mit gleicher UNID - aber das ist leer! Also ein Notes-Dokument ohne irgendwelche Felder mit 0 Bytes, das aber kein Deletion Stub ist. Wie kann denn so etwas entstehen?

Nach weiteren Merkwürdigkeiten in den Dokumenten muß ich noch suchen - auf den ersten Blick fand ich noch nichts.

Ciao
Sascha

[Tode]

Nun: Wann werden Dokumente nicht repliziert? Dazu gibt es -mal auf den ersten Blick- Folgende Möglichkeiten:

1. Änderungsdatum älter als das Datum der letzten "erfolgreichen" Replikation.
Lösung: Dokument erneut ändern (einfach einmal abspeichern, oder per scanEZ ein Feld setzen), oder das Replizierprotokoll löschen

2. Dokument darf nicht in Ziel- Replik auftauchen wegen Replikationsformel.
Lösung: Replizierformeln prüfen (auf allen beteiligten Repliken)

3. Dokument darf nicht im Ziel auftauchen wegen Leser- Feldern
Lösung: Leserfelder des betroffenen Dokuments checken und ggf. korrigieren

4. Dokument ist "corrupt" und kann deshalb nicht repliziert werden
Lösung: ggf. Dokumente via lokalem Fixup "reparieren" (heisst im dümmsten Fall Löschung des Dokuments, also auf jeden Fall vorher ne Sicherung ziehen)

5. EIN Dokument kann nicht repariert werden, und die Replikation bricht dann komplett ab, und macht alle anderen auch nicht.
Lösung: Das Dokument sieht man normalerweise in den "replication events" in der lokalen log.nsf. ggf. muss man LOG_REPLICATION am Client hochsetzen...

[Sascha Seipp]

Hallo,

hab mal wieder ein Update: ich hab mir die Space Savers-Seite nochmal genauer angeschaut.
Zunächst sah ich das hier: (Screenshot "vorher").

Und dachte eigentlich, das ist auch ganz normal so, weil ja eigentlich kein "Selected documents" aktiv ist.

Dann hab ich mal (zunächst nur in meiner Testkopie, auf beiden Repliken) von "Those matching the selected criteria" auf "All" umgestellt und repliziert, und siehe da: ~660 Dokumente aktualisiert!

Das hat also scheinbar "den Knoten gelöst" - die Frage ist nur: soll das so sein? Soweit ich das sehen kann, ist "Those matching the selected criteria" doch eigentlich die Voreinstellung, wenn weiter nichts explizit gewählt ist, oder?

Bin noch nicht sicher, ob ich das dem User so als Lösung präsentieren soll oder noch tiefer nach der Ursache suchen sollte? (wenn in dem Dialog eigentlich keine einschränkende Option angezeigt wurde, kann es sein, daß diese trotzdem irgendwo in der DB drin war, aber nicht angezeigt wurde?)

Ciao
Sascha

[Sascha Seipp]

Moin allerseits,

um mein Problem hier nochmal mit einer konkreten Frage weiterzubringen: wo werden die Replikationseinstellungen bzgl. der "Retrieve these documents"-Einstellung in jener Maske abgelegt? Profildokumente? Teil der Replikationsformeln?
Denn da muß ja danach etwas anders gewesen sein als vorher, auch wenn die vorherige Einstellung der Optik nach eigentlich nicht falsch war.

Meine Vermutung wäre, daß da vorher etwas verkurbelt war, was aber so nicht richtig angezeigt wurde. Das würde ich nur gerne nachvollziehen und verifizieren können.

Ciao
Sascha

[Sascha Seipp]

Hallo allerseits,

da ich hier glücklicherweise auf der richtigen Spur war und das Problem abstellen konnte, hier nochmal der Abschluß dazu:
Mit replicationEZ konnte ich sehen, daß tatsächlich die Replikationseinstellungen korrupt waren (s. Screenshot) und daher die Replikation nicht richtig funktionierte. Ein Ändern der o.g. Einstellung hat zwar normalerweise keine Auswirkung auf die vorhandene Replikationsformel (weil die Auswahl ja eh nicht aktiv ist), führt aber offensichtlich dazu, daß die Replikationsdokumente neu geschrieben werden und dann wieder funktionieren.
Das muß man sowohl auf der lokalen Replik als auch auf der serverseitigen machen und dann lokal noch die Replication History löschen, und danach ist wieder gut.
(Das Löschen der defekten Dokumente mit replicationEZ hat leider nicht geholfen - nach einem Refresh waren sie wieder da).

Da ich das Problem jetzt in kurzer Folge bei drei verschiedenen Usern hatte, stellt sich mir nur noch die Frage, wodurch Replikationseinstellungs-Dokumente eigentlich kaputt gehen können.

Ciao
Sascha