Jeff Moden (10/28/2016)

---

Siberian Khatru (10/28/2016)

---

Thanks all for the excellent advice and pointers. I am slowly altering all these databases to be of the SIMPLE recovery model and shrinking the LOG files to 50mb on those that have grown into the multiple GB range. There is plenty of room with still about half the total space available and I'm shrinking them only to (hopefully) streamline the external backup processes. This seems a fair trade off in space savings and I'll be monitoring the log files for any signs of unusual growth. Anything is an improvement over what I got handed.

For the truly SharePoint savvy among us here, are there any specific SharePoint databases that require special attention or handling? Most of these are named "WSS_Content_<some name>" which seem to correspond to the various SP sites, but there are others with names like "Search_Service_<some name>" and "User_Profile_<some name>" and still others with more cryptic names so before I mess with those, I just want to make sure (if I can) that there isn't some arcane unwritten rule about certain SharePoint generated databases. It would be my guess that a database is a database is a database, but I've been wrong before -- and so I ask the experts here. Any worries, or just get on with it?

Just to be clear, shrinking the log files won't steamline the BACKUP process. It will streamline a RESTORE process, if ever needed.

Can't help with your SharePoint questions. We're in the process of getting rid of it. 😛