DBMT- Task stirbt, nachdem die Threads auf Fehler laufen

[Tode]

Wir haben hier am Wochenende einen DBMT am laufen mit einer Stoptime (wegen Datensicherung) mit folgenden Parametern:

Code

-stoptime 9:30PM -compactThreads 4 -updallThreads 4 -ftiThreads 4 -compactNdays 10

Im log sehen wir, dass kurz nach dem Start der DBMT in 4 Datenbanken auf Fehler läuft, und danach stoppt der Compact komplett:

11.05.2019 10:16:08   Compact of mail\atest.nsf failed: One or more of the source document's attachment are missing.  Run Fixup to delete the document in the source database.
11.05.2019 10:17:09   Compact of mail\btest.nsf failed: One or more of the source document's attachment are missing.  Run Fixup to delete the document in the source database.
11.05.2019 10:20:08   Compact of mail\ctest.nsf failed: One or more of the source document's attachment are missing.  Run Fixup to delete the document in the source database.
11.05.2019 10:21:58   Compact of mail\dtest.nsf failed: One or more of the source document's attachment are missing.  Run Fixup to delete the document in the source database.

11.05.2019 10:21:59   Database compactor process shutdown

Für mich sieht das wie ein Design- Fehler aus, dass der DBMT keine neuen Compact- Threads startet, wenn einer auf einen Fehler läuft... Hat das schonmal jemand gesehen? Oder gibt es vielleicht einen Parameter, der einen "Neustart" des Threads veranlasst?

Durch den Fehler wurden viele Datenbanken schon ewig nicht mehr komprimiert, weil er jede Woche mit den selben wieder anfängt, und wieder auf den selben Fehler läuft... Und der automatische Fixup durch den DBMT funktioniert nicht, weil der nicht rund um die Uhr läuft.

Klar: Wir werden jetzt die Datenbanken reparieren und hoffen, dass der Task danach durchläuft, aber da muss es doch eine bessere Lösung geben...

[Pfefferminz-T]

Hi Torsten,

welche Serverversion. Habe bei Kunden mit Domino 9.0.1FP10HF361 den DBMT auf einer grossen Anzahl an Servern laufen, auch mit Stoptime und Start immer am Samstag - bisher nur den Fehler, dass ein nocompactlimit dazu führt, dass Datenbanken in der dbmt_compact_filter.ind einfach nicht beachtet werden. Ansonsten laufen die eigentlich wirklich gut durch.

[Tode]

Serverversion ist 9.0.1FP6.

[Pfefferminz-T]

Ok, in FP7 und FP10 waren auf jeden Fall Fixes für DBMT drin. Aber verwendet ihr absichtlich kein -Force beim DBMT? Dann würde ja der Fixup laufen.

[Tode]

Das mit dem fehenden -Force ist dem letzten Admin geschuldet, ich hatte die Doku dazu so gelesen: Wenn der Force nicht angegeben wird, dann passiert das immer am Sonntag... Meine Vermutung war nur: wenn der Task nicht rund um die Uhr läuft, verliert er vielleicht den Track auf die Anzahl fehlgeschlagenen Compacts und macht deshalb NIE den Fixup.

Wir werden aber den Force- Parameter mal ergänzen. Danke für den Hinweis. Die Fixes für DBMT in FP7 schaue ich mir mal an.
Die Firma ist grade (bzw. schon länger) in einer Migration von Domino auf Exchange, deshalb sind seit längerem keine Server- Updates mehr eingeplant worden...