Replizierprobleme mit großer DB

[fsinani]

Hallo domino - jünger,

nachdem ich mich erstmal gefreut hab, wieder mit notes zu tun zu haben, kommt auch schon der erste Ärger.

Habe hier eine DB mit 17 GB (ca. 660.000 Docs). Es gibt viele Homeoffice User, demnach also auch viel Replikationstraffic (über selektive Replikation!).

Leider gibt es historisch bedingt eine Menge Ansichten (für jeden Sch..ss) also sind die Ansichtsindizes auch verdammt groß. KLar, am besten nur einige wirklich wichtige Ansichten behalten und den Rest rausschmeissen.

Was kann man aber sonst tun, um die Performance zu steigern? Es ist übrigens in den Grundzügen eine Gedys Applikation mit sehr viel eigenzeugs drin.

Das Problem ist, dass es immer wieder vorkommt, dass einige Dokumente einfach nicht repliziert werden, obwohl die sich an der Quelle ändern. Ytria zeigt an, dass eine Änderung anliegt und dass dieses docs eigentlich zum replikationspartner repliziert werden müsste, aber es tut sich nichts.

Hat jemand sonstiges auich ähnliche Erfahrungen machen dürfen?

Bringt ODS 48 vielleicht etwas abhilfe?

Wer hat denn schon mal ne notes nsf in DB2 migriert?? Welche Schwierigkeiten?


Danke und noch ein paar schnell endende Arbeitstage bis zum Wochenende :-)

[fsinani]

Wollte den Thread unverschämterweise nochmal nach oben bringen :-)

Hat jmd. von euch große (> 5 GB; > 500.000 docs) im dauereinsatz? Wie handelt Ihr die Performance?


Danke

[WernerMo]

Hallo,

wir haben zwar eine DB mit > 25 GB und rund 350.000 Dokumenten, aber wir replizieren nur vollständig und nur zwischen Servern.
Da geht das repl. ohne Probleme.

Gruß Werner

[Thomas Schulte]

186 tsd Dokumente >20 GB. Teilweise selektive lokale Repliken, geclustert, zusätzlich mit jeder Tochtergesellschaft auf deren Server repliziert. Hochgradig Änderungsanfällig zusätzlich mit Erzeugung und Änderung von Dokumenten über ein angebundenes Fremdsystem. Keine Probleme mit der Performance. Es sei denn man zieht eine neue vollständige lokale Replik dann dauert der Aufbau der Indices locker mal eben 14 Stunden. 294 Views und nicht gerade welche von der einfachen Sorte. 196 Forms, 133 Agents, 133 Script Libraries. Richtig komplexe Anwendung.

272 tsd Dokumente > 3 GB. Auf alle Tochtergesellschaften verteilt, Erzeugung der Dokumente über Webservices. Abarbeitung im Workflow. Statistische Auswertungen laufen zusätzlich jeden Tag/Woche/Monat. Hochgradig Änderungsanfällig. Keine Probleme mit der Performance. 58 Views, 22 Forms, 13 Agents. Die Anwendung selber ist eher schlicht.

107 tsd Dokumente > 12 GB. knapp 203 Views 38 Forms aber nur 27 Agents. Auch keine Probleme mit der Performance. Mittelkomplexe Anwendung.

Wenn du Gedys sagst, dann meinst du die "alte" Gedys struktur. Richtig? Und dann ist an der Anwendung vermutlich seit 19hundertfeuerzeug nichts mehr grundlegend renoviert worden. Korrekt? Da würde ich den Haken genau an dieser Stelle einfädeln.
Was die Ansichten angeht. Man kann ja mal ein Ansichten Profiling schreiben das einfach über einen Zeitraum X mitloggt welche Ansichten überhaupt benutzt werden. Dann hat man zumidest schon mal einen Ansatzpunkt was man unter Umständen nicht mehr braucht oder wo man die Priorität bei der Pflege der Ansichtsindices zurückschrauben kann.

[fsinani]

Danke WernerMo und Thomas Schulte,

habe hier die CRM App von Gedys (basiert noch auf 4.6er). 660.000 docs. Wird ständig benutzt.

Werde mal schauen, was da alles gehen kann.

Melde mich dann mit dem Resultat


fsinani

[fsinani]

Ach übrigens,
Thomas Schulte....

was genau meinst du mit Ansichten Profiling, das klingt nämlich sehr interessant.

Müsste ich mir etwas selbst programmieren, oder gibts da was schon fertig?

danke

[Thomas Schulte]

Selbst programmieren.

[Driri]

Wer hat denn schon mal ne notes nsf in DB2 migriert?? Welche Schwierigkeiten?

Ich habe in letzter Zeit öfters gelesen/gehört, daß die DB2-Integration wohl nicht weiterentwickelt wird und somit vermutlich auch sterben wird. Offizielle Aussagen habe ich dazu nicht, aber das würde ich mir vor dem Hintergrund gut überlegen.