There is a similar post here which I believe is misleading that does not relate to my issue. My MOSS content database is growing like crazy every week. It grows by almost 10GB a week! There are no errors posted in the logs. A few months ago I removed about half of the content but the database never went down even after I shrunk it. I indexed the database every night but lately I stopped doing that. The site has an average usage. The content DB is at about 160GB and by my estimate it should be less than 100GB. In comparison I have another site which is only WSS 3.0 and has 6x the sites and 3x the users but yet is smaller and growing at a steady rate. Any help would be greatly appreciated.

its not the number sites that matters, it's what the users are putting into the site. have you checked versioning settings as well as the recycle bin, those can swell up your sites pretty quickly.

1. after removing your content have you clean your recycle bin of site?, which still hold that content so that your db is not shrinking ;) 2. if you are working with document libraries, and if you don't use versining very frequently. then turn off versining as all version of docuemnts are stored in Site DB itself. 3 please let us know which type of content you are hosting in site?Regards, Vikas Patel.

Hi, Please can you check if you have audit logging enabled - as this can cause large content db's! (along with the suggestions above). Have you also checked to see what SQL is set to, with regards to DB shrinks and auto growth? RegardsAaron

The content I deleted were actually complete sites. From my understanding, once you delete a site, all the content in it is gone, isn't that so? Most of our document libraries do not have versioning turned on. From a quick analysis that I have done there is not a place where some one is uploading massive data. DB auto growth is set to 5% (log file). Even after shrinking, not much changed. Any other ideas? Is there a query that I can execute on the SQL DB to find out which sites have the most data?

I guess some simple DB maintenance goes a long ways. Did a transaction log backup. Then truncated the log Determined that data size was about 15GB. Then allocated 75GB to the log Changed the recovery model to simple. Now the size is stable. I still though, don't know why it was ballooning at that high of a rate.

Hi, transaction log files can be very large, and the only way they get truncated is only after they are backed-up. You should also look into other SQL maintenance tasks, such as defrags and shrinks. Regards Aaron