FT Index einer DB regelmässig kaputt

[DAU-in]

In einer Applikation, die ich betreue, wird sehr viel mit Dokumentlöschungen gearbeitet. Der FT Index ist in regelmässigen Abständen korrupt. Teilweise stürzt dann bei Suchen auch noch der Server mit ab.
Gibt es etwas, was ich machen kann, damit der FT stabiler wird (ohne die  Applikation neu zu schreiben)?
Die Admins legen den Index jetzt jede Nacht neu an als erste Hilfsmassnahme.

grüsse

Dau-in

[WernerMo]

Hallo,

jeden Morgen (z.b. um 5:00 Uhr)  oder jeden Sonntag im Admin einen Prozess laufen lassen, der den Index löscht und neu aufbaut?

Gruß aus Nürnberg (Nießelregen) nach München
Werner

[DAU-in]

ich glaube schon, dass die Admins das über einen Agenten erledigen und nicht selbst nachts am Server sitzen 

Ich denke, das hat mit den vielen Dokumentlöschungen zu tun, aber die kann ich leider nicht abstellen.

grüsse

dau-in

[koehlerbv]

In fast allen Fällen, die ich in mehr als 15 Jahren Notes kennengelernt habe, gab es für permanente und übermässig viele Löschungen von Dokumenten vorrangig zwei Gründe (eigentlich "immer"):
- Das Konzept der Notes-Lösung war völlig falsch
- Notes war für die Aufgabe das falsche System.

Bernhard

[ata]

... so viele Löschungen können durchaus die Ursache sein - warum müssen die Dokumente denn gelöscht werden - warum kein Update im Bedarfsfall?

toni

[m3]

In einer Applikation, die ich betreue, wird sehr viel mit Dokumentlöschungen gearbeitet.

Deleting a document and then recreating “the same” document is three times as bad in terms of performance, as just modifying the existing document.

Andre Guirard in "Performance basics for new developers"

Ich würde hier ein Redesign andenken.

[DAU-in]

Ich würde hier ein Redesign andenken.

Lieber nicht.
Fürs erste werde ich mich aufs Beten verlegen, und dreimal täglich den Server streichelnn

[Gandhi]

Um das ganze mal ein bisschen aufzulösen (schliesslich bin ich der Verbrecher, der das ganze entwickelt hat)

- Die Löschungen sind tatsächlich konzeptbedingt
- Domino war in dem Fall das einzig verfügbare System mit entsprechenden Ressourcen (mir)

Die Löschungen sind aus folgendem Grund notwendig:
Es soll von mehreren Personen gleichzeitig auf das gleiche Dokument (via Browser) zugegriffen werden. Alle diese Personen greifen dabei auch auf gleiche Felder zu.
Hierzu wird dann für jeden Anwender eine Arbeitskopie des Dokumentes für einen Teilbereich erstellt. Bestimmte Felder benutzen wie gesagt alle gleichzeitig.
Beim Speichern dieser Kopie werden die Felder aus dem Bereich in das Original übertragen, die Werte der gemeinsam genutzten Felder (z.B. History) an die Felder des Originals angehängt.
Die Arbeitskopien werden in einen nichtsichtbaren Status versetzt und dann mittels eines periodischen Agenten gelöscht.
Man kann natürlich auch alle Daten auf dem Dokument löschen und einen Pool von leeren Dokumenten halten, die dann wieder als Arbeitskopie benutzt werden können.
Das war in der Phase, in der ich entwickelt habe schlicht nicht nötig - da es zum einen noch keinen FTI gab und zum anderen keine Performance- bzw. Stabilitätsprobleme aufgetreten sind.

Da ich zwischenzeitlich den Arbeitgeber gewechselt habe bin ich nicht mehr auf dem allerneuesten Stand - aber:
- ich bezweifle, dass der FTI überhaupt notwendig ist
- die Applikation ist lange sehr stabil gelaufen (nicht besonders performant aber stabil)
- ich vermute eher, dass die Probleme mit dem Serverumzug zu tun haben - vorher wars ja relativ ruhig. Da gibt es schon einen signifikanten zeitlichen Zusammenhang oder?

Btw.: Die DB ist wirklich SEHR komplex. Xanthi hat das mehr oder weniger unfreiwillig übernommen - grösseres Redesign ist nicht zu empfehlen wenn dann schon eher ein Neuaufbau mit einem anderen, mächtigeren System (J2EE, .NET) - wobei das Teile des Kunden sicherlich nicht freuen wird.

[DAU-in]

Seit dem Serverumzug ist jetzt gerade Ruhe (vermutlich die vor dem Sturm).

Ich habe inzwischen den Verdacht, dass eine Kombination aus dem FTI und den nicht löschbaren Dokumenten der Auslöser war.
Aber ich starte jetzt keine Versuchsreihe für die Verifikation dieser Theorie.

Edit: die Servercrashes waren auf dem alten Server. Die Admins konnten immer 2 DBs (mit FTI und immer wieder nicht löschbaren Dokumenten) als Schuldige identifizieren.  Die dritte nahezu identische DB (mit FTI, ohne unlöschbare Dokumente) hat nie einen Servercrash ausgelöst.