compact -S works…sometimes.

I’ve recently stumbled upon using compact -S5 in our weekly Saturday compact program document.

Like most shops, we run Fixup on Fridays and then Compact on Saturdays on all databases.

We found that a couple of servers that have about 400GB worth of mailboxes were not finishing their compact jobs. The compact was taking somewhere in the range of 36 to 48 hours. We weren’t sure how long it was taking because we had to shut it down on Monday morning when people got into the office and starting trying to access their databases.

I found the -S switch which will compact only database which will only compact databases with more white space than you specify in the .

Example: compact -S5 will only compact databases with more than 5% white space.

This dramatically cuts down on the time required to run compact because it will skip all of the databases that are already pretty much compacted, but which may be very large.

We went from 36+ hours to about 6 on two of the large servers. This is a great improvement which really works for us.

One strange thing that I noticed though is that is doesn’t always calculate the white space correctly while initializing the compact job. Sometimes databases that are 90% compacted are skipped when you use the -S5 switch.

We are using 6.5.6FP3 HF53 servers.

Does anybody else have experience with using the -S switch and seen the same anomalies?

6 Responses to “compact -S works…sometimes.”

  • Nikolay Krastev says:


    There is a problem described in the Knowledgebase with the -s compact switch. It was related with the inaccurate white space calculation. You better search for it on the IBM site.

  • Tim E Brown says:

    I have always used -S10. Your on a pretty old release, I bet it’s fixed in the R7 code stream, but I’m sure you have reasons why you have not upgraded yet.

    Tim E. Brown

  • Chris Mobley says:

    Nikolay is exactly right. I went round and round with IBM on the “% Used” calculation being flawed. I was getting users who would delete half their email, yet their mail file size would not go down the next day after the overnight compact was run.

    They gave me a workaround of running compact -b which would adjust the “% used” calculation to something more accurate, then the compact -B would work better. But still this didn’t always work.

    I can tell you that this issue is better in 7.0.3, but not totally fixed. My servers are on 8.0.2 now and I haven’t had any users complain as of yet, so maybe 8.0.2 is even better yet.

    Check out this technote:

  • Steve says:

    I saw the same issue here. Support told me to use 10 instead of 5 as it would be more accurate. Sadly, they were correct.

  • Randy says:

    According to this it’s only fixed in 8.0.2 and 7.0.4 which isn’t out yet.

    I’ve been burned by this on many occasions and try to run a compact -c once a month now on all servers. It’s nice to see that once I get them all to 8.0.2 I may be able to end this practice as it causes disk fragmentation.

  • Adam Osborne says:

    You could try doing a compact -b on Thursday – it is very fast and helps maintain the freespace tables.

    Also check how fragmented your drives are. This can make a big difference. If you like, have a look at our product – defrag.nsf

Leave a Reply


I'm currently available
for Lotus Notes / Domino consulting engagements.


Connect with me: