- Back -

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.