Replikationsproblem II

    Hallo Leute,


    muss leider das Problem nochmal posten, es ist schlimmer als angenommen. Repliziert wird generell nur mehr von den Repliken auf den PCs auf den Server rauf, runter vom Server nicht mehr ...


    Nochmal die Situation :
    Eine Datenbank (ca. 50.000 Dokumente, 12 GB groß ...) am Server, verschiedene Leute replizieren regelmäßig.
    Die Serverdatenbank hab ich neulich mal mit nfixup, ncompact und nupdall behandelt, dann gings kurz.
    Jetzt wie gesagt nur mehr in eine Richtung ...


    Weiß da jemand eine Lösung ?


    Danke


    Günther

    geh mal auf die relizier einstellungen der db, da gibt es die option, nur an server senden und einen weiteren haken...änderungen vom server beziehen(wortlaut)

    -*-*-*-*-*-*-*-*-*-*-*-


    woher soll ich wissen was ich denke, bevor ich höre was ich sage???

    An Replizierparameter & ACL-Einstellungen habe ich auch gedacht.
    Nur darf es dann nicht kurzfristig nach den Wartungs-Task funktionieren...


    Was sit denn das für eine DB?
    Kannst du hier nicht irgend eine Form von Archivierung implementieren,
    damit sie etwas geschmeidiger wird?


    Mach mal eine Kopie ohne Inhalt, kopiere dir ein paar Doks rüber und teste die Replikation mit dieser DB,
    um zu prüfen, ob die Größe oder das Design schuld hat.


    Gruß Steffen

    [color=0000CC]"Wir können Probleme nicht mit dem Denken lösen,
    das zu ihnen geführt hat." ( A. Einstein )[/color]

    Hallo Günther,


    hatten wir auch mal mit DBs, in denen viel gelöscht wird. Dabei entstehen deletion-stubs, die wie richtige dokumente auch immer mit repliziert werden. und plötzlich sind es nicht mehr nur 50000 Doks sondern 150000 oder mehr. Und die stubs werden nach meiner Beobachtung zuerst repliziert und kommt irgendwann ein Zeitabbruch.


    Über den replizierparameter "Dokumente entfernen, die seit xxx Tagen nicht geändert wurden." lassen sich die stubs entfernen.


    Auch wenn das Häkchen nicht gesetzt ist, greift die Einstellung und löscht alle stubs die 1/3 Tage alt sind, wie die Einstellung. Damit sinkt die Anzahl der zu replirierenden Doks erheblich.


    Das war zumindest bis Notes 5 so.


    Die stubs zeigt übrigens das Tool NotesPeak sehr schön an.


    Ich hoffe es hilft...


    Bernd

    Tja, danke für die zahlreichen Tipps.


    Ich hab jetz mal einen Script-Agenten reingebaut, der die Deletion-Stubs löscht (hab mit NotesPeek gesehen, da waren gute 18.000 drin).
    Hab den Agenten dann sowohl in einer lokalen Replik als auch auf der Datenbank am Server laufen lassen.
    Leider umsonst :
    Und noch immer werden keine Dokument vom Server an die lokale Replik runterrepliziert, umgekehrt schon.


    Komischerweise, beim allerersten Replizieren einer neuen Replik gehts ja auch, vom Server runter auf den Client.


    Ich fürchte, da wird nicht anderes übrigbleiben wie eine neue Kopie zu erstellen. Mit einer solchen läuft die Replizierung wunderbar.
    Muss halt an meine Externisten Flashdrives per Botendienst versenden ...
    Wie ich gesehen habe, bleiben bei einer Kopie eh die Document-IDs gleich, Gott sei Dank. Denn da setzte ich manche Links drauf ...


    Oder hat noch jemand eine rettende Idee, die Replizierung wieder "gängig" zu machen ?



    Danke


    Günther

    Die UNIDs der Dokumente bleiben zwar gleich, aber die Replica ID der Datenbank ändert sich.


    Wenn du also Notes Document Links verschickt hast dann sind diese funktionsunfähig nachdem du eine Kopie gemacht hast, weil die ja noch auf die alte DB zeigen

    Mal so ganz frei in die Runde geworfen:


    Könnte hier nicht ein Datumsproblem existieren? Denn bei der ersten Replikation ist die Relikationshistory ja noch Jungfräulich...
    Wenn da irgendwas quer ist glaubt die Datenbank doch das die Dokumente schon gesendet worden sind.
    Nur mal so als idee......