My good friend and colleague Cédric Oster has an excellent blog on his experiences with SharePoint 2007, InfoPath 2007 and more. Cédric is a SharePoint consultant of quite some standing.

You can read Cédric’s SharePoint Blog for his latest writing. I’ve just read his piece on SharePoint database growth rates, and how to deal with them. Very sound advice – Cédric writes:

“To free up space manually: after a full backup you can shrink and truncate the log file to any size you need by doing the following:

• Open SQL Server Management Studio
• Select the database you want to shrink the log file (e.g. MOSS_Intranet_Content)
• Click the “New Query” button
• and run the following command:
  dbcc shrinkfile (<LOGICAL LOG FILE NAME>,<SIZE IN MB>,truncateonly)

for example: dbcc shrinkfile (MOSS_Intranet_Content,2,truncateonly)

This applies to the Content Databases but also the Configuration and Search Databases.”

I should point out that this principle also applies to SQL Server development in general. If you’re developing using SQL Server, very often backup, restore and maintenance can be all too easily forgotten. The best side effect of which is that you end up with an enormous log file, or performance would eventually be degraded. The worst side effect could be that you might not have a database backup and maintenance schedule, which could put your data at risk.

Here’s what MSDN has to say about DBCC SHRINKFILE. Similarly, I should point you at Joel Oleson’s Blog – another noteworthy SharePoint blogger. He has an excellent article on Best Practice for SharePoint Backups.

I would side with Joel here, not just because we share a name, but because I, too, really rate Microsoft System Center Data Protection Manager as the best mechanism for WSS and MOSS backups. Here’s an informative webcast from Microsoft on backing up MOSS with DPM. This may well become a topic for a future blog entry for me.