We have one large database in that sometimes the $Revision resp. LastModified field “hangs”. i.e. if we create a document at 8:00 the $Revisions field shows 13:02. So for 5 hours the $revision fields of all new documents show a time between 13:02 and 13:06.The time on the server is ok and on other databases on the same server there is no problem.
When the real time has reached (13:06) the problem is gone and the time is correct.
Does sombody have entered a similiar problem ?
Subject: RE: LastModified Time sometimes hangs
Do you maybe have an agent that’s creating a great many documents? Is that really necessary?
Subject: RE: LastModified Time sometimes hangs
Hello Andre,thanks for your quick response.
This database has a long history. It is a multilanguage ticket system and the database exists since 2000. Last month we made a new design version and we added 6 more languages, so now there are 11 languages in.
After the upgrade we had some server crashes when we entered the database by http. Fixup and compact didn’t help, so we decided to copy all documents in a new database by agent.
This didn’t solve the problem anyway, but the size of the database minimized from 40 GByte to 10 GByte.
At least we detect that we have to upgrade to version 7 because of the maximum length resp. volume of view names.
However, since the upgrade which is one week ago we had one crash (nsd dump said nothing special) and the trouble with the $Revision.
Do you have a special thing in mind, because you asked about an agent ?
regards,
Michael
Subject: RE: LastModified Time sometimes hangs
I just blogged about the Notes quirk which I think it the cause of what you’re seeing (if the new entry isn’t there, check back in an hour).
That’s what I think is happening in your case. If it just happened once, it might be because of your one-time copy. But if it happens regularly, you must be creating lots of documents every day.
I suspect it’s a “delete everything and create new documents from some data source” agent.
One effect of such an agent is to create many, many deletion stubs – many times more than you have documents. The fact that the database got so much smaller when you copied it, is further evidence of this. The documents copy – the deletion stubs do not. Deletion stubs are small, so if they occupied 3 times as much space as your documents, you had an awful lot of them.
Useful blog: Best Practice Makes Perfect
Subject: RE: LastModified Time sometimes hangs
Thanks for getting me in the right direction.On a other database on that server there are some agents which are running once a week (monday, and on tuesday we detect the problems). They delete and create a lot of documents from the host. Unfortunately they do no update.
However, in the database where the timestamp goes wrong there are no such agents. Does this timeshifting problem affecting all databases on the server or only the one where the agent run ? And under 6.5.x we hadn’t such problems.
Subject: RE: LastModified Time sometimes hangs
I’m not sure whether the effect extends to other databases on the server. I would’ve guessed not, but perhaps this has changed, and it’s possible the change was deliberate. After all, if an agent does operations in multiple databases, you may want to compare the modified time of a document in database A with that in database B, and they should really not be out of order with the actual sequence in which these operations occurred. This may also have been an effort to address issues of duplicate UNIDs in file-copies of databases on the same server running the same agent at the same time to create documents in themselves, which later replicate in a confusing way.
Fix that batch agent, in any case. It’s dragging down the performance of your server.