Das Notes Forum

Domino 9 und frühere Versionen => ND6: Entwicklung => Thema gestartet von: dh-paule am 09.01.04 - 17:25:42

Titel: "ReplikationskonfliktvermeidungsStrategie" ???
Beitrag von: dh-paule am 09.01.04 - 17:25:42
Hallo,

nun ist es soweit, meine 2.te grosse DB steht unseren Usern im FirmenNetz zur Verfügung. Während bei der ersten DB relativ klar war wer welches Dokument wann bearbeiten kann, ist es nun so das ca. 100 Aussendienstler auf eine DB oder deren lokale Replik zugreifen. Dabei wird es jetzt sicherlich vorkommen das das ein oder andere Dokument von mehreren Useren zeitgleich lokal bearbeitet wird. Was geschieht dann bei der Replikation?

Was passiert wenn ein user längere Zeit nicht repliziert und sagen wir mal die letzten 2 Änderungen eines Dok.s nicht bekommen hat und nun dieses Dok. repliziert nachdem er es auch geändert hat?

Wie kann ich dadurch entstehende Probleme abfangen?  
Titel: Re:"ReplikationskonfliktvermeidungsStrategie" ???
Beitrag von: koehlerbv am 09.01.04 - 17:33:44
Oh ja, das wird wieder ein interessanter und lehrreicher Thread ... Bei dem aber DAS Kochrezept nicht herauskommen kann, da hier das "Prinzip Notes" immer wieder auf andere Situationen stossen wird.

Ich fange mal an, meinen Senf dazuzugeben;
1. In den Maskeneigenschaften einstellen "Replizierkonflikte mischen". Wenn dann User A die Telefonnummer ändert und User B die Postleitzahl, dann kommt es zu keinem Konflikt. Absolut wichtig dabei: Es darf keine Felder geben, die bei jeder Änderung angefasst werden. Systemfelder ($UpdatedBy und Konsorten) sind ausgenommen.
2. Organisation. Festlegen: Wer hat wann was zu tun.
3. Workflow: Wer darf wann was ändern.

Sehr gespannt,
Bernhard
Titel: Re:"ReplikationskonfliktvermeidungsStrategie" ???
Beitrag von: Glombi am 09.01.04 - 17:36:09
Du solltest folgendes machen:

1. Wenn Ihr mehrere Server habt, auf der jeweils eine Replik liegt:
Die Replizierpriorität der Datenbank auf Hoch setzen. Für diese Datenbank extra Replikations-Verbindungsdokumente erstellen mit einem sehr kleinen Replikationsintervall.

2. Einen organisatorischen Ansatz: Bevor User lokal arbeiten, sollten Sie zunächst replizieren, um den aktuellen Stand zu haben. Nach lokalen Änderungen wieder replizieren.

Andreas
Titel: Re:"ReplikationskonfliktvermeidungsStrategie" ???
Beitrag von: Glombi am 09.01.04 - 17:39:05
Das mit dem Replizierkonflikte mischen hat aber auch Nachteile: Es können Inkonsistenzen entstehen.
Beispiel:
User A ändert in dem Dokument das Feld Ort von Frankurt in München.
User B ändert im gleichen Dokument auf einem anderen Server die PLZ von 60000 in 60100.

Was dann?

In R6 gibt es übrigens die Möglichkeit, Dokumente zu sperren, die gerade von anderen bearbeitet werden. Das solltest Du auf jeden Fall einstellen.

Andreas
Titel: Re:"ReplikationskonfliktvermeidungsStrategie" ???
Beitrag von: Manfred Dillmann am 09.01.04 - 17:43:59
Hallo dh-paule,

vielleicht ist das auch noch mal einen Blick wert:

Minimierung der Replizierkonflikte in der Praxis (http://www.madicon.de/id/5Q7B6B)

Gruss
Manfred
Titel: Re:"ReplikationskonfliktvermeidungsStrategie" ???
Beitrag von: dh-paule am 09.01.04 - 18:29:34
:-(
Titel: Re:"ReplikationskonfliktvermeidungsStrategie" ???
Beitrag von: dh-paule am 09.01.04 - 18:37:04
UUPS, da war der Text weg :-(

Also hier noch ein paar Details:

Die DB beinhaltet ca. 1600 Kunden und 12000 Geräte, das sind zusammen 13600 Dokumente. Alle diese Dokumente können voan allen >100 Usern aufgerufen und bearbeitet werden. Leider replizieren nicht alle User regelmässig (täglich) sondern nur wöchentlich oder unregelmässig... So kann es immer wieder passieren das ein Dokument lokal bearbeitet wird das zwischenzeitlich schon bearbeitet wurde.

Gibt es eine Möglichkeit das Datum der letzten Replikation abzufragen ($Feld) ??? Vielleicht liese sich daraus ein Hinweisfenster basteln:

"Achtung, Dokumente können nur geändert werden wenn die letzte Replikation nicht länger als xx h zurückliegt. Bitte replizieren Sie die Datenbank und bearbeiten das Dokument danach erneut."

Für eure Ideen danke ich schon im vorraus ;-) Spezielle Grüße übrigens nach Siegsdorf :-)

P.S: die ersten 396 Änderungen sind aktuell gelaufen, ohne das es zu Rep.Konflikten kam...
Titel: Re:"ReplikationskonfliktvermeidungsStrategie" ???
Beitrag von: koehlerbv am 09.01.04 - 20:44:23
Besondere Grüsse retour aus Siegsdorf ;-)

Zitat
Gibt es eine Möglichkeit das Datum der letzten Replikation abzufragen ($Feld)  Vielleicht liese sich daraus ein Hinweisfenster basteln:

"Achtung, Dokumente können nur geändert werden wenn die letzte Replikation nicht länger als xx h zurückliegt. Bitte replizieren Sie die Datenbank und bearbeiten das Dokument danach erneut."

Jo, da habe ich was in meiner Raupensammlung. Ich schreib' mir jetzt mal 'nen groooossen Zettel und mal das mal am Wochenende auf ;-)

Herzliche Grüsse nach Jena von
Bernhard
Titel: Re:"ReplikationskonfliktvermeidungsStrategie" ???
Beitrag von: dh-paule am 13.01.04 - 13:49:47
Hallo Jungs,

vielleicht hat ja einer von euch einen Tipp...
Gibt es ein Feld an dem ich das Datum der letzten Replikation erkennen kann? Ich möchte ein Hinweisfenster anzeigen lassen das dem Anwender mitteilt da eine Änderung nur möglich ist wenn die letzte Replikation nicht länger als xxx Tage (Stunden) zurückliegt.

Hat da jemand eine Idee ???
Titel: Re:"ReplikationskonfliktvermeidungsStrategie" ???
Beitrag von: koehlerbv am 13.01.04 - 13:53:32
In einem Setup-Dokument belegst Du auf Deinem Hauptserver mit einem periodischen Agent ein Feld jeweils mit dem aktuellen Datum. Wenn nun ein User so vor sich hin ändern möchte, wird vorab geschaut, um wieviel in seiner Replik dieses Datum zurück in der Vergangenheit liegt. Schmeckt Dir die Differenz nicht, verhinderst Du das Ändern.

HTH,
Bernhard
Titel: Re:"ReplikationskonfliktvermeidungsStrategie" ???
Beitrag von: dh-paule am 13.01.04 - 14:41:00
uiuiui... periodische Agenten auf unseren "superschnellen" Servern :-( Von soetwas ist unsere Informatik überhaupt nicht begeistert ;-(

Ein $ Field gibt es dazu nicht ???
Titel: Re:"ReplikationskonfliktvermeidungsStrategie" ???
Beitrag von: Semeaphoros am 13.01.04 - 14:44:47
Nana, also das Ding, das Bernhard da vorgeschlagen hat, ist nun wirklich nicht resourcen-hungrig. Der James muss ja nur einmal am Tag rennen.
Titel: Re:"ReplikationskonfliktvermeidungsStrategie" ???
Beitrag von: koehlerbv am 13.01.04 - 14:45:07
Ein Systemfeld gibt es nicht ...

Zum anderen: Wenn Euer Server keinen Agent verträgt, der alle x Stunden ein einziges Doc anfasst und dort ein einziges Feld updated, na, dann weiss ich nicht ...

Bernhard
Titel: Re:"ReplikationskonfliktvermeidungsStrategie" ???
Beitrag von: dh-paule am 13.01.04 - 14:48:18
Ach bei unserer Informatik ist das weniger die Performance als die "Angst" vor den automatischen Agenten in DB's
Titel: Re:"ReplikationskonfliktvermeidungsStrategie" ???
Beitrag von: Semeaphoros am 13.01.04 - 14:49:28
hmm, da müsste man jetzt eigentlich eine böse Frage stellen ....
Titel: Re:"ReplikationskonfliktvermeidungsStrategie" ???
Beitrag von: Glombi am 13.01.04 - 14:53:27
Es könnte ja einer von der Informatik das Profildokument jeden Tag einmal speichern  ;D
Das nimmt dann die Angst vor den Agenten und gibt einem ein Gefühl, eine verantwortungsvolle Aufgabe zu haben.  ;)

Andreas
Titel: Re:"ReplikationskonfliktvermeidungsStrategie" ???
Beitrag von: Semeaphoros am 13.01.04 - 15:29:35
Genial!

Den Mitarbeiter kann man dann auch nicht nach Indien auslagern .....


 ;D
Titel: Re:"ReplikationskonfliktvermeidungsStrategie" ???
Beitrag von: Glombi am 13.01.04 - 15:54:35
Man braucht natürlich noch einen zweiten verantwortungsvollen Mitarbeiter, der den anderen kontrolliert. Und natürlich Vertreter für Urlaub etc.
Das ganze wird in einem 10köpfigen Projektteam als Prozeß erarbeiten und ISO zertifiziert. Ein entsprechendes SLA muss natürlich auch erstellt werden.

Damit hätten wir zumindest mittelfristig so ca. 20 Arbeitsplätze gerettet.  ;D
Titel: Re:"ReplikationskonfliktvermeidungsStrategie" ???
Beitrag von: dh-paule am 15.01.04 - 13:41:05
Hallöle,

die Idee mit den Arbeitsplätzen verlagern ist nicht schlecht. Ich werde das dann wohl zukünftig selbst machen und dazu extra nach Sydney ;-) umziehen um den Refresh mitternachts (MEZ) durchzuführen. :-)

Ich habe "meine" User jetzt angewiesen Änderungen erst nach einer aktuellen Replikation vorzunehmen und hoffe so das Maß der Konflikte niedrig zu halten... Evtl. reicht ja schon das "mischen" durch Lotus selbst.

DANKE trotzdem für eure Unterstützung !!!
Titel: Re:"ReplikationskonfliktvermeidungsStrategie" ???
Beitrag von: dh-paule am 19.01.04 - 16:19:05
Vielleicht könnt Ihr mir doch noch helfen...

Ich möchte die User nicht mit dem permanenten Hinweis nerven das Sie erst dann Dokumente ändern dürfen wenn aktuell repliziert wurde. Wenn man den Replikator aufruft dann sieht man in der ReplikatorView in der 4.ten Spalte den Zeitpunkt der letzten Replikation. Welche Variable ist das denn? Wie kann ich diese abfragen?

DANKE für eure Hinweise, mit besten Grüßen, ANDRE
Titel: Re:"ReplikationskonfliktvermeidungsStrategie" ???
Beitrag von: koehlerbv am 19.01.04 - 17:51:29
Hallo, Andre,

wie ich schon geschrieben hatte: Du kannst den Zeitpunkt der letzten Replikation einer DB nicht mit Bordmitteln abfragen.

Dürft Ihr wirklich nicht einen einzigen scheduled agent auf einem Server laufen lassen ? Ich sehe einfach keine andere Möglichkeit ...

Viele Grüsse nach Jena,
Bernhard
Titel: Re:"ReplikationskonfliktvermeidungsStrategie" ???
Beitrag von: Alessandro am 20.01.04 - 09:28:34
Hallo Andre,

welche Notesversion setzt ihr ein ??

Vermutlich noch R4/5.
Solltet ihr aber schon 6.x einsetzen kannst du in der Arbeitsumgebung einstellen "Replizieren beim Start von Notes" mit der Option "Nicht Nachfragen" und dann noch "Beim Herunterfahren von Notes fragen ob repliziert werden soll".

Damit ist die "Last" der "von Hand Replizierung" von den Mitarbeitern genommen ;D
Titel: Re:"ReplikationskonfliktvermeidungsStrategie" ???
Beitrag von: koehlerbv am 20.01.04 - 16:09:53
So richtig hilft das dann aber auch nicht - die User müssen sich nicht daran halten oder wollen Eingaben machen, wenn sie off-line im Hotelzimmer hocken oder ...