Some of my users mail files have grown to over 2Gb and the usual compact processes are not having any effect…Whilst looking through the mail files on my server I noticed an unusual number of quite large files. Database properties showed that the % used was over 90% but the number of documents was quite low (say less than 2000). A view of ‘all docs’ didn’t show up any large attachments, there was nothing much in trash and the view indexes were all quite small. A manual fixup and compact (both copy style and in-place) didn’t reduce the size, but replicating local, deleting the server copy and then replicating back gives a file size of around 300-500Mb.
Lotus has yet to figure this out correctly. The problem is with deletion stubs not being deleted when you run the Compact Task. Replicating the DB to another server removes those stubs, thus reducing the size. I went through two months of support calls with Lotus to be told to use a third party tool. You run this tool first, compact the DB, and bingo, your DB is small again. Email me if you want me to send you the tool.
There must be something more to the actual cause. Deletion stubs are tiny (<1Kb). After deleting a large document, the compact should be able to release most of the space. Also, deletion stubs DO replicate to all replicas (including new replicas), though they will not be copied to a new database.
I would suggest that you use a program document to compact the files during off hours with the option -B and verify in the log that compact had completed. Also check the start and end times. If it finishes too soon, you may need to run a fixup to clear any corrupt documents which might be affecting the compact process.I would also suggest trying to run the compact on the db during maintenance when the server is down.
Another option is to run compact -D and then a compact -B to reduce the file size. After compact completes, run updall -R to rebuild the views.
If % used was over 90% this would be why compact wouldn’t do much. We only run compact on dbs that are under 90% used. As far as the dbs size going down after creating a new replica, this is typical because the view indexes do tend to take up alot of space. As the user opens all of the views and folders you will see the db size creep back up again.
was just pointing out that compacting a db over 90% used won’t recover much but I suppose 10% of 2GB could be considered a sizeable difference to some.
Re-reading the earlier response, I decided to soften my reply. You are right. It wouldn’t do “much”, but it would do some good.
I have found that view indexes can take multiple times the space of the data. Typically though, you will see that in the index size in the log.nsf. My next bet is either that the compact did not complete because the database was in use or addition options should be used to free up diskspace. It would be worth checking the log.nsf to see if the compact failed. Create a PROGRAM document to schedule the compact after hours. You might even do a DROP ALL and DBCACHE FLUSH beforehand to reduce any open connections to that NSF. You might also add either -B or -c as well as -D. The next likely causes are the size of trash docs (which purportedly is not large) or deletion stubs (which are unlikely to consume much space).