Manage Learn to apply best practices and optimize your operations.

Reduce the size of your database

Resident administration expert Michael Lazar offers his tips on reducing the size of your databases.

Resident administration expert Michael Lazar offers his tips on reducing the size of your databases.

View member feedback to this tip.

Here are a few tips that I've found useful in keeping the Database Monster under control.

  1. Schedule a weekly compact program document. The standard switch is "-S10", which tells the compacter to run against any database with more than 10% white space. This performs a copy style compact.

  2. Archive documents. Whether it is a mail file or some other database, archiving old (but still needed) documents to another server will keep your production database small (once they are compacted). Remember, large databases are often slower and more prone to corruption than small databases. Keeping databases small has added benefits other than just freeing up disk space.

  3. Educate your users on how to properly store and respond to mail. (This is for mail databases.) Nothing kills space faster than someone who sends a message to a bunch of people with an attachment, and then someone replies to all with history and resends the attachment. The cycle continues, and the next thing you know someone has six copies of the same attachment. I can't stand it when this happens. Thankfully, this is addressed in ND6 with the new "Reply w/out attachments" feature. However, this leads back to educating your users. They need to know how to be good corporate citizens.

  4. Keep views to a minimum. (This one is most likely for non-mail files.) The more views you have, the more space you will use. This is because the view indexes have to be built and maintained by the server. In large databases with many views, the indexes can often take up more space than the actual documents!
I have some bad news for folks running transactional logging. Items 1 and 2 cannot be used to help reduce file sizes without some very careful planning. You should not use copy style compacts with transactional logging. Doing so renders all prior log extents for that database useless since a copy style compact changes the DBIID. The rule is that you should take an immediate full backup after running a copy style compact on a transactionally logged server. I have seen people run a compact on Saturday night, and then take a full backup on Sunday. They were willing to risk the potential loss of data due to a crash/corruption for that short, off-hours timeframe. Only do this if you understand the risks and are willing to take them.


Regarding keeping a small mail file, here is what I tell my users: Follow these three practices to keep your mail file small without having to deal with archiving.

  • Periodically remove the largest 50 messages or attachments.
  • Zip files before attaching when appropriate. (We use the Zipmail product to simplify this.)
  • Use a Notes database rather than e-mail for sharing attachments to groups of people. (A central document library or discussion DB customized to allow assigning readers and editors to each document works great.)
How to remove the largest messages or attachments:
  1. Open the All Documents view.
  2. Click on the column header to sort by size.
  3. Remove the attachments from the largest 50 messages (first two screens) or delete the messages entirely.
  4. Repeat monthly.
Following these steps will return huge amounts of space with minimal effort and without the need to archive. (For legal reasons some people may still need to archive.)

-- David H.

Do you have comments of your own? Let us know.

Dig Deeper on Lotus Notes Domino Database Management

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.




  • iSeries tutorials's tutorials provide in-depth information on the iSeries. Our iSeries tutorials address areas you need to know about...

  • V6R1 upgrade planning checklist

    When upgrading to V6R1, make sure your software will be supported, your programs will function and the correct PTFs have been ...

  • Connecting multiple iSeries systems through DDM

    Working with databases over multiple iSeries systems can be simple when remotely connecting logical partitions with distributed ...