I'm starting to worry about my log.nsf file. I've never really paid much attention to this thing, but I recently did a scan for big files on my server and discovered log.nsf was more than 11 gigabytes!

We've been running the server for a long time, but I just don't feel good about a log file that size. Shouldn't the server be purging the file on a pretty regular basis?

Jelani is right. Your log.nsf file should never be that large. In fact, your log file should be purged on a very regular basis.

Log file purging is generally managed by the "Log=" parameter in Notes.ini. A few weeks ago, we gave a Site of the Month award to lntoolbox.com's .ini reference and today, I'm making use of it to answer Jelani's question.

According to the .ini reference, the format for the "Log=" parameter is:

The fourth parameter, "days", is what's important here. Most often, you'll see that set to 7, for 7 days. Sometimes, you'll see it set to 30. But either way, you shouldn't have more than about 30 days in your log.nsf file.

So, the first thing to do is check your Notes.ini and see if somehow that parameter is inflated, for example, if it says something like 365 or even 20000. If so, then your log isn't being purged because Notes has been told not to purge it.

By the way, if it turns out you don't have a "Log=" parameter, that doesn't mean the log file is allowed to grow. The default setting for log file purging is 7 days, so if you have no "Log=" at all, 7 days is the assumed value.

One thing to note is that Notes doesn't purge the entire log at once. According to IBM:

Purging is done at one-third of the purge interval time. (i.e. If the interval is set to 30, then every 10 days, all deletion stubs older than 30 days are purged from the database)

It's also possible that the "Log=" parameter is being ignored in Notes.ini. There was a problem in Domino 6.0, 6.5, and 7.0 where Domino ignored the parameter under certain circumstances. I honestly don't know if the problem still exists in current releases, but I haven't seen any mention of it, so it might have been fixed.

There is a workaround. Find the Replication->Space Savers tab and look for the checkbox "Remove documents not modified in the last N days". Check it. This should help you get around the problem.

Good luck!

Joe is a ZATZ associate editor. Prior to this job, he was customer support manager for the FileFlex database engine.