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
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. TryDrop All
and if that works you could write some code that drops only users accessing that db.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).
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.
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.
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