On my mailserver, virtually everytime I run the “tell daosmgr status” command it tells me the catalog needs resync. Running “tell daosmgr resync” doesn’t seem to resolve it.
On top of that after running compact with archiving switch last night (we do this twice a week for server-based archiving) when I run the “tell daosmgr dbsummary” command it reports most of my mail databases display “New DB DETECTED”
Subject: Re: cannot keep in sync
I did some experiments with the 8.51 code, and compact with the archive switch did not cause an NR condition. I’ll see if I can determine if the fix for that was included in 8.5 FP1.
Just to make sure I’m attempting to repro this correctly, what exact flags are you specifying on your compact operation?
There was a fix that went in to 8.51 that corrected the handling of some mail.box situations that would cause an NR state. That may be the root of the problem in your case. A workaround is to remove any stranded documents in mail.box that have attachments stored in DAOS, and then resync.
Subject: compact switches
I’ve been running compact via a program document every night like this
load compact -b -a
The documentation says that -b is for transaction logged databases.
-a is to do server-based archiving
I’ll remove the -b and see.
Subject: Not related to nightly compact
I resynced the catalog in the morning and by afternoon it was out of sync again. This is repeatedly the case. I did not run compact in the this time frame so its not a factor.
One observation that is notable is that all the databases that report NEED RESYNC are used by Notes 7.0.1 users. This is consistently the case, so I don’t believe its a coincidence.
I cannot upgrade those users due to their hardware restrictions (old machines that cannot be replaced at this time). I am tempted to just unDAOS any user’s mail who is using a client older than Notes 8.
Subject: Re: Not related to nightly compact
DAOS does not know (or care) what version or type of client is making the request, so that is a curious result. There should be messages on the console indicating when each of the NSF files are going NR initially. Perhaps some other messages just prior could provide some context for the problem?
Subject: Passed DAOS logs to Support
I agree, DAOS is supposed to be client-agnostic. But the fact remains that the only mail files that are going out of sync are used by Notes 7.0.1 users. They are using the DWA7 mail template.
Anyway, I’ve opened a PMR and IBM has been sent logs created thought some special debug settings in notes.ini.
Subject: Development reviewing
I believe this has been fixed but will confirm
Subject: Cannot keep DAOS in sync
Darn thing comes out of sync even before the sync is done!
11/16/2009 11:16:31 Informational - The database /NOTES03/NOTES/DATA/mail/jpelfrey.nsf has caused the DAOS catalog to become out of sync. Deletions will be postponed. Please run ‘tell daosmgr resync’ at the next convenient opportunity to re-synchronize.
show statistic DAOS.Engine.Catalog
DAOS.Engine.Catalog = Needs Resync
tell daosmgr resync
11/16/2009 14:12:22 DAOSMGR: Resync started
11/16/2009 14:12:22 Rebuilding the DAOS Catalog.
11/16/2009 14:16:39 Informational - The database /NOTES03/NOTES/DATA/mail/ctrigg.nsf has caused the DAOS catalog to become out of sync. Deletions will be postponed. Please run ‘tell daosmgr resync’ at the next convenient opportunity to re-synchronize.
11/16/2009 14:16:39 The DAOS catalog cannot be resynchronized. DAOS deletions will be postponed.
11/16/2009 14:16:39 DAOSMGR: Resync completed
Lotus Domino (r) Server (Release 8.5.1 for i5/OS)
PTF
ID Status
L502633 Temporarily applied
IBM i 6.1
Subject: tell daosmgr databases
Running this command tell daosmgr databases
shows the database in question listed twice. This was supposed to be fixed by that hotfix, L502633.
pmr 12466,500,000