Link to home
Start Free TrialLog in
Avatar of jmchristy
jmchristy

asked on

WSS 3.0 Sharepoint content log file size

Hello, recently my sharepoint server ran out of disk space. The SQL database is stored locally on it. I drilled down and found out that the Content LDF was consuming all of the hard drive space. I searched around the web and several sites recommended changing the recovery mode to Simple. I did make that change and I was able to shrink the log file database. That freed up about 17 gigs on the server. Further reading stated that this was not a good practice and that log files should be "dumped". I checked my 2005 SQL server manager and it doesn't appear that I have the capability to backup the log file anymore. I can still shrink it though. I'm not very familiar with Sharepoint. It's basically being used now as a knowledge base. I'm wondering if what I've done to the database will prevent it from expanding again, resulting in the same issue? Also, do I need to be backing up the log file? Any help would be greatly appreciated.
ASKER CERTIFIED SOLUTION
Avatar of zephyr_hex (Megan)
zephyr_hex (Megan)
Flag of United States of America image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of jmchristy
jmchristy

ASKER

Okay. That all makes sense. The only other thing I noticed was the autogrowth on the log file. Should that be turned off? By default it was set to 10% and 2GB when I changed it to Simple. Should I just leave that stuff alone?
leave the autogrowth alone.  changing the recovery model is enough.

autogrowth has to do with SQL "sizing" itself ...so that there is enough space for new data.  instead of constantly allocating space, it does it in chunks, and you don't want it to do that too often because it's a performance hit.
i also didn't use autoshrink because if it runs mid-day, it could be a performance hit.
more info here:
http://support.microsoft.com/kb/315512

in my environment, i changed sharepoint db's to Simple recovery, implemented weekly full backups, and i also occasionally manually ran a SQL defrag script.  i can't remember exactly which defrag script i used, but it was something similar to this:
http://support.microsoft.com/kb/943345
Okay. Thanks alot, you've been a HUGE help! Points awarded.
oh, i also ran nightly Sharepoint stsadm backups using something like this:
http://blog.integrii.net/?p=122


so:
nightly Sharepoint full farm backups, (and a library of 7 days of previous backup files) - scheduled in windows scheduler
weekly full SQL backups on Sharepoint databases - scheduled in SQL
about once every 3 months, i ran the SQL defrag script.  it was a small company, and sharepoint was used daily, but not used heavily.

and then i copied all backup files to offsite storage nightly.  so i had 2 copies of every backup file... one one onsite, and one offsite.

and i'd say that was overkill, but it wasn't interfering with performance or costing any extra money to do it, so i did it.