Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

We have had a couple of nasty experiences recently where a heavily used Lotus Notes database has gone over the 64gb limit.

The databases had some slack space which enabled us to run a database compaction to fix the problem, but taking the database offline long enough for a compaction to get exclusive use of the database was a real nightmare.

We tried:

  • Allowing users read-only access to the database while the database was compacting.
    (the compaction would fail after some time, saying that the database had been modified)
  • Removing access to all non-administrators for the database
  • Disabling replication for the database
  • drop database.nsf - to kick everyone off that database
  • dbcache flush - to Close all databases that were open in the database cache

Still users would show up as accessing the database, and not allow an exclusive mode compaction.

Eventually we resorted to:

  • Removing access to all non-administrators for the database
  • restarting the server
  • quickly typing into the server console: "compact -c databasename.nsf" before anyone tried accessing the database

Is there an easier way to kick everyone off a database and force an exclusive database compaction? We are running Lotus Domino Server 8.5.3

share|improve this question

5 Answers 5

compact -B is "In-place with file size reduction". Give it a try if you haven't yet.

In my understanding drop db.nsf does not work. Try Drop All and if that works you could write some code that drops only users accessing that db.

share|improve this answer
Tried that, but got this message: Error compacting databasename.nsf: Database is currently in use by you or another user –  Marcus Jan 29 '13 at 11:02
OK I added a little bit about drop in my answer. –  Panu Haaramo Jan 29 '13 at 11:12
Thanks Paul. I'll try the "drop all" command and let you know... –  Marcus Jan 29 '13 at 11:18
The command "drop all" under limited testing seems to have done the trick. I hope its a while before I have to test this under heavy load! –  Marcus Jan 29 '13 at 12:01

Why not implementing a cluster (configured for failover) then you could switch the users over the the other one. Then you have time to fix the DB and run a compact. You could then also delete the DB and let it re-create it from the 2nd server (the re-created DB will then be already compacted).

By the way. I would enable (if not already enabled) Document & Design Compression along with LZ1 that might help to shrink the DB a little bit (depends on the content).

share|improve this answer
Thanks for the ideas. I don't have access to a 2nd server for failover, but have asked for one. While the office still feels the pain of the last outage, it's a good time to renew the request. LZ1 compression is already enabled on our databases. We are also starting to look at DAOS to make the 64 GB limit a non-issue for us... –  Marcus Feb 3 '13 at 14:05

You can try an offline compact using ncompact utility from the Notes client. It has the same options as the compact command from Domino console but it works directly on nfs without opening Notes or running Domino.

If you don't want to move this huge nfs you can use a network share and run ncompact over it. I strongly suggest to run fixup over it, and convert it to ODS 5.1 if it use an old ODS version.

I also suggest to check nsf and not let them reach that size, archive documents moving them to new nsf copies. Try to maintain them around a few gigabytes, so you can run fixup and compact frequently be sure on their consistency.

share|improve this answer

Before replacing the replica on the primary server with a new one from the cluster, I suggest confirming that the number of documents is the same or reasonably close, and that there are no structural issues with the replica on the cluster server. I would check this by running compact on the database on the cluster, and parsing the console log on the cluster server for errors.

share|improve this answer
This is a comment, not an answer to the question. –  Deer Hunter May 12 at 19:55

I'm experiencing same problem with Compact -C -DAOS ON. it failed saying compact was stopped prematurely becasue another user modified it while it ws being compacted. Stopping the router, smtp and replicator task solve the issue. I don't know which task is reponsible at this time but is working

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.