5

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

Marcus
  • 151
  • 1
  • 1
  • 6

5 Answers5

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

Panu Haaramo
  • 343
  • 7
  • 20
  • 1
    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
1

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).

BastianW
  • 2,848
  • 4
  • 19
  • 34
  • 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 03 '13 at 14:05
0

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.

Tasslehoff Burrfoot
  • 1
  • 1
0

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.

DovidM
  • 1
0

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

Rony
  • 1