We have database whose profile documents disappear every night. It all started when our server crashed one day. We realized a database had lost its profile documents.
Treating the effect:
We ran an agent that re-creates the documents (from the template). But every next day the documents are missing again. So we scheduled the agent to run once a day.
Treating the cause (all the options below were done after re-creating the documents using the agent):
we ran fixup and compact, trying to fix the database (as it seems corrupted)
we stopped the Domino server and ran ncompact
we created a replica of this database to another server and monitored it; while the original database continued to lose its profile documents, the replica behaved fine; so I created a new replica on the second server (to have the most up to date information), stopped the Domino servers on both machines, deleted the original database (the nsf file) and copied the replica (at file system level).
None of these worked. Sometimes one profile document disappears, sometimes both of them. Sometimes the documents are there, but their fields are missing.
Even after replacing the original database with its replica, it continues to behave in a strange way, while the replica (on the other server) works fine.
One thing to mention: the size of the database is about 500 MB.
Can anyone give us a hint for fixing this problem ?
Maybe something to look at is under the Design Tab there is an option to Copy Profile documents from the template.
Maybe if this is ticked, it not only copies but removes existing profile documents in the database. ie no profile docs in the template so after Design task runs each night, all profile docs in the database are removed.
Have not used the option, I would hope that it would not do that. But you never know.
Thanks for your reply, Tommy.The template does contain the two profile documents. As I mentioned, we scheduled an agent to run and restore the missing documents in the database (from the template) and it works fine.
On the other hand, there are lots of databases created from the same template, but the issue appears only for very few (large ones).
My question is how do we treat the cause, I mean what should we do to prevent these documents from disappearing. Why do they dissapear ?
We can put them back, but this is just a workaround, it’s not fixing the cause.
So I would remove the Design Task from the notes.ini if this is set to run (as a starter)
I am thinking that you could add to the Database Script - Querydocumentdelete event and code to capture if the document being deleted matches a value or unid of one or both of your profile documents. Then if so, record information about when, who is doing the action and try to tie it down to a piece of code in the database or an agent or other.
If you have SoftDeletions enabled and the deletion process is not hard deleting the document, then you can see deleted profile documents in a ‘Deleted Documents’ view. However the columns of the standard SoftDeletions view may not show the document properly so you can create your own and set the view columns to give you information like $UpdatedBy, @Modified etc to help you find more info.
Maybe check that the database deisgn elements do not have Disable Design refresh, which is causing issues with specific functions in the database.
What are your profiles providing? Maybe review the code that accesses the profile documents to see if there is a possibility that a scenario will not end up having the profiledoc being referenced for send or delete later in a code stream. This may not affect smaller databases due to the amount of usage scenarios, rather than thinking of it as relating to disk space used.
Use the NotesNoteCollection class to get a list of all profile documents and list out their item values. Possibly you have multiple profiles with the same name and need to delete some of them.
In that case, I think you need to write an agent to execute very often, check some field in the profile, and see when it changes. That will give you a date/time to check the server log and the user history of the database, to see what else was going on at around that time.