Hallo zusammen,
mit Hilfe vom IBM Support (Mein erster PMR) und Detektivarbeit haben wir das Problem
finden und lösen können. Im Grunde war es ein User – was auch sonst ;-)
Er hatte versucht 3 Emails mit jeweils einem sehr großen Anhang (427, 506 und 634 MB)
per Email zu versenden.
Da der User im Ausland bei einer unserer Tochter sitzt und seine Internetverbindung nicht
die Beste ist, hat das vermutlich nicht geklappt. Da wir in unserer Mail-Box am Server wie
empfohlen auch das DAOS aktiviert haben, hat sein Client immer wieder (seit 4 Monaten)
versucht diese Emails zu routen und die Mail-Box legte dafür jeweils eine NLO Datei an.
Zusätzliche Infos:
Laut IBM ist an der Endung P „xxxxxP.nlo“ zu sehen das es eine Temporäre NLO-Datei ist,
die „noch“ keiner DB zugeordnet ist. Somit war die Stundenlange suche über
tell daosmgr listnlo -o mymailobjects.txt MISSING mymail.nsf
bei allen DBs größer 400MB umsonst.
Zuvor hatte ich natürlich die großen NLOs wo anders hin geschoben.
Auch hatte der User mittlerweile die Großen Mails wegen der Mail-Quota gelöscht und
seine DB hatte eh nur noch 160MB.
Über den IBM Support habe ich auch noch erfahren mit welchem Befehl man "einfacher"
an die Info kommt, welche NLO in welcher DB ist.
Dazu muss in der Notes.ini zuerst folgender Eintrag gesetzt werden.
DEBUG_DAOS_DIAGNOSTICS=1
dann an der console folgendes eingeben
tell DAOSMgr DAOSdiag -a -as -v -o Dateiname.txt
Aber hier ist Vorsicht geboten da dieser Befehl lange dauert (Bei uns ca. 1 Stunde) und
eine große Textdatei erzeugt (Bei uns ca. 53MB). Auch soll man es nicht tagsüber tun.
Zwischen -a und -as kann man noch einen Pfad eingrenzen z.B.:
tell DAOSMgr DAOSdiag -a mail -as -v -o Dateiname.txt
Darin hatten wir aber auch nichts gefunden, da es ja Temporäre NLOs waren.
Mit dem Befehl
Tell DAOSMgr Prune 0
habe ich dann auch noch weiteren Platz frei schaufeln können. Backup ist natürlich vorher gelaufen.
mfg Christian