“unique fields names table size” error in Lotus Domino

I recently had an issue where the mail boxes on one of my Domino servers were not compacting at all during their normal window.

My logs showed

09/03/2009 04:00:01 AM  Router: Beginning mailbox file compaction of mail1.box
09/03/2009 04:00:01 AM  Switching to copy-style compaction for E:\Lotus\Domino\Data\mail1.box due to unique fields names table size
09/03/2009 04:00:02 AM  Router: Shutdown is in progress
09/03/2009 04:01:49 AM  Router: Unable to compact mailbox file mail1.box: Database is currently in use by you or another user
09/03/2009 04:01:49 AM  Router: Completed mailbox file compaction of mail1.box
09/03/2009 04:01:49 AM  Router: Beginning mailbox file compaction of mail2.box
09/03/2009 04:02:02 AM  Router: Completed mailbox file compaction of mail2.box
09/03/2009 04:02:02 AM  Router: Beginning mailbox file compaction of mail3.box
09/03/2009 04:02:02 AM  Switching to copy-style compaction for E:\Lotus\Domino\Data\mail3.box due to unique fields names table size
09/03/2009 04:03:49 AM  Router: Unable to compact mailbox file mail3.box: Database is currently in use by you or another user
09/03/2009 04:03:49 AM  Router: Completed mailbox file compaction of mail3.box
09/03/2009 04:03:50 AM  Router operation resumed.

Since I haven’t had the need to monitor for failure of mailbox compaction, I was not aware of this issue until I received complaints of Non Delivery Errors. Specifically “554 Error writing message to safe storage; message could not be stored to disk“.

I was unable to find anything useful either from Lotus’ technotes online, their forums or using Google in general so I thought I’d post something to help out others who travel this path.

I contacted Lotus and opened a PMR but they were clueless as well. I really wanted to know what the “unique fields names table size” error was all about but they really didn’t know and tossed me a technote pertaining to “Database has too many unique field names” which really didn’t apply. They also focused on database corruption caused by  anti-virus programs. I figure that, if this was the issue, this should  have come up in the past 5 years on some of the 30+ other servers I’m working with so I was pretty sure this was also not a cause.

Long and short, I still don’t have an effective means to generically monitor for mail box compact failure. I *could* set up a monitor for the “unique fields names table size” string but it seems that seems like overkill.

To resolve the issue is simple enough:

  • shut down the server,
  • rename all the mail boxes,
  • restart the server (allowing new mail boxes to be created),
  • copy over any not-dead messages to one of the newly created mail boxes and
  • delete the old mail boxes

A side-effect of the above is that my name becomes the “from” address for all the copied messages.  Anybody have a simple solution for that? I haven’t actually researched it yet since it comes up so infrequently but it would be handy to know.

5 thoughts on ““unique fields names table size” error in Lotus Domino”

  1. Hey Marc,
    How are you doing???
    You don’t know how much I miss your help.
    None else knows lotus domino as you!
    I want know if you could help me with a LotusScript code to remove old emails on a specific server.
    Here is the code I have built. But it doesn’t work and I don’t know why?
    Any help will be very appreciated. I haven’t any more ideas…

    Sub Initialize
    Dim s As New NotesSession
    Dim db As NotesDatabase
    Dim dc As NotesDocumentCollection
    Dim doc As NotesDocument
    Dim nextdoc As NotesDocument
    Dim olddate As New NotesDateTime(“”)
    Dim currentdate As New NotesDateTime(“”)
    Dim current As NotesDateTime
    Dim servername As New NotesDbDirectory(“”)
    Set servername = New NotesDbDirectory(“Golan/Veraz”)

    Dim dbdir As New NotesDbDirectory(“servername”)
    Set db = servername.GetFirstDatabase(DATABASE)

    While Not db Is Nothing
    If Instr(db.FilePath,”mail\”) Then
    Call db.Open(“”,””)
    Set dc = db.AllDocuments
    Set doc = dc.GetFirstDocument

    While Not doc Is Nothing
    Set nextdoc = dc.GetNextDocument(doc)
    Set currentdate = New NotesDateTime(doc.DeliveredDate(0))
    Set current = New NotesDateTime(currentdate.DateOnly)
    Set olddate = New NotesDateTime(“01/01/2009”)

    If currentdate.LSLocalTime < olddate.LSLocalTime Then

    Call doc.Remove(True)

    End If

    Set doc = nextdoc
    Set nextDoc = Nothing

    End If

    Set db = dbdir.GetNextDatabase
    End Sub

  2. @David Montenegro – Hi David, it’s been a long time! Sorry for not responding sooner but I’ve been VERY busy with my new job and have been falling behind on some of my personal pursuits lately as a result.

    I think you’ll find the code you’ve created above a little simpler than you want. You should have your agent configured to ignore things such as Draft messages and probably tasks and calendar entries as well.

    If you *do* want to remove calendar entries you should be checking for other dependencies (i.e. repeating meetings) where you may not be able to remove a meeting notice because one or more of its children (depending on your version of domino) is still outstanding.

    I’m pretty sure, since some of the documents you’ll end up picking up with the current code will not have a “DeliveredDate”, that this will end up defaulting to some low value (if it doesn’t outright throw an error). You will want to test for forms that you are interested in (“Memo”, “Reply”) and THEN start looking at dates. And if you are not using dates that are guaranteed to be there (such as Created or Modified), then you need to test that the date field 1) actually exists and 2) is a valid date BEFORE you assign it to the date time value field and try to use it for comparison. Especially where you will be deleting documents as a result.

    You should also be logging your activity, either to an agent log on the server or to an email sent to yourself when the process is completed. In it you want to indicate the name of the server and the filename of the file you are currently working on as well as how many documents you have removed.

    And don’t forget your error handling. You WILL encounter databases where the permissions are set so the ID you run this agent under will not have access, or you’ll encounter index corruption that will cause a failure when you try to access a document, etc. These all need to be captured and either cause the agent to abort or be handled gracefully such that you can continue on to the next document or mail database as appropriate.
    Also, your log needs to be robust enough to be preserved if your agent is terminated prematurely either because it has aborted, exceeded the maximum time allotted for agents to run or because the server is being recycled or even because someone kills the task.
    If at all possible you want the agent to run on the server rather than from your desktop. It will be MUCH faster.

    In the past the agent I wrote to help purge old emails from your system was run from a database called “Admin Agent Repository”. You should find it in the admin folder on your Domino server. The agent name is something descriptive like “Purge old emails” or similar.

    If you can find it use that agent, or get one of the North American admins to send you the agent from their copy of the agent repository so you can use it as a starting point.

    Be very careful and test a LOT before you go after people’s mail files. I suggest running the agent against a subset of files first with the actual document delete line remmed out so you can inspect the report (and even watch what is happening using the debugger) so you can be sure you are removing ONLY what you have said you were going to remove.

    Good Luck!

  3. Marc, I had to tackle UNK table errors in mail.box files also. It was one of the first problems I dealt with after taking my current position as a Domino admin. I can even show you how to examine the fields stored in the UNK table so you can identify the root cause.

    This is a problem that Lotus is trying to keep hush hush, the senior level tech I worked with even told me to keep it on the down-low, it requires using undocumented ini settings that activate new MIME to CD conversations functionality introduced in 8.5.3.

  4. My solution to this type of problem has always been to bring down Domino and create new replicas using a client mapped into the server. It has work for numerous corruptions of the mail.box files.

Leave a Reply

Your email address will not be published. Required fields are marked *