Logo 
Search:

MOSS Forum

Ask Question   UnAnswered
Home » Forum » MOSS       RSS Feeds

Databases logs and logs growing too

  Asked By: Ariel    Date: Mar 04    Category: MOSS    Views: 3469

I have been exploring migration approaches in my laptop for the last
month.
Today I noticed a strong slowdown and went to check.
I was running out of space.
With the help of Treesize (an highly recommended tool) I quickly
realized that the .ldf files for the Sharepoint databases grew out of
control. My _SITE database is 11,731 MB and its log file is 35,635 MB.

I installed a bunch of updates from Microsoft yesterday, between them
some SPs for SQL and VS 2005, that may be the culprit. Again this is
my personal laptop an I have been testing migration approaches there,
SharePoint user activity has been negligible.

What are the best practices for limiting the log file sizes?
Are there out any links that can help me on this?

In the same line, I just cleaned up our Production SPS server of up
to 30 gb of log files on the C:\WINDOWS\system32\LogFiles\STS\ and
subfolders. How do I limit those in our future MOSS deployment where
I'm planning to go with 4 VMs on two blades?
Are there best practices defined on this topic as well?

Share: 

 

6 Answers Found

 
Answer #1    Answered By: Chelsey Watts     Answered On: Mar 04

First, let's be clear that this issue has nothing to do with SharePoint at all.
This falls 100% in the SQL admin realm. I only mention this so that if you do
any followup research that you don't throw SharePoint into your search and
potentially limit your results.

SQL writes every transaction to the the transaction log (the LDF file) in real
time, then as it has a chance it commits them to the database  file (the MDF
file). LDF files  are basically flat files with sequential lines, MDF files are
much more complicated, so in the interest of speed SQL does not write directly
to the MDF file. Now, what it does with that transaction file after the changes
are committed to the MDF file are up to you. You didn't mention which version
of SQL you're using. That's pretty important since this is an SQL issue. In
general terms you need to do a backup of your MDF and LDF files with an SQL
aware process (either in SQL or using a back up program that is SQL aware). You
should be able to shrink your LDF file after that. You can also set the
Recovery Mode of your databases  to Simple. That means that SQL flushes the
transaction from the LDF file once they are committed to the MDF file. It
doesn't automatically shrink the LDF file, but it is less likely that it will
grow as large. You can also set SQL to autoshrink the LDF and MDF files, but
I would not suggest it.

 
Answer #2    Answered By: Vinay Thakur     Answered On: Mar 04

I'm clear it falls in the SQL Admin realm, and we are madly in love
with SharePoint. Precisely because we love it, I want to all "i"s
dotted for our MOSS deployment.

We are using SQL Server 2000 for our actual SPS/WSS 2003 and will use
SQL Server 2005 64 bit for our future MOSS/WSS 2007.
In my laptop I have SQL Server 2005 32 bit.
We do use backup exec for the production environment but obviously
not for my laptop. I guess the backup process in our production
server have been taking care of the growth of the ldf files.
For my laptop I'm going to change the recovery model to Simple as you
suggested and will shrink the logs  files too.

>"You can also set SQL to autoshrink the LDF and MDF files, but I
would not suggest it..."
Why is this not recommended? Is it not a best practice?

What about the 30 gb of log files  on the C:\WINDOWS\system32
\LogFiles\STS\ and subfolders in our production server?
Those are not sql server logs. How do I limit those in our actual SPS
server and in future MOSS deployment? Again, are there best practices
established for limiting those? Are there any links available?

 
Answer #3    Answered By: Jonathan Scott     Answered On: Mar 04

LDF and MDF files  grow by nature. As time goes by you have more content, not
less. Every time you shrink an MDF or LDF file you force it to grow the next
time you add content. Each time it grows you run the risk of it getting
fragmented in the file system. Fragmented MDF and LDF files mean slow access
for SQL.

 
Answer #4    Answered By: Asia Meyers     Answered On: Mar 04

Do you have any advice about the 30 gb of log files  on the
C:\WINDOWS\system32
\LogFiles\STS\ and subfolders in our production SPS 2003 server?

Those are not sql server logs. How do I limit those in our actual SPS
server and in future MOSS deployment? Again, are there best practices
established for limiting those? Are there any links available?

 
Answer #5    Answered By: Shelley Reese     Answered On: Mar 04

Those are IIS log files. Generally, I just prune those using custom built
scripts to delete based upon age.

 
Answer #6    Answered By: Omar Arnold     Answered On: Mar 04

I don't know if the files  in the STS directory are IIS logs  or not.
Regardless they probably compress really, really well. J For my IIS
logs I zip them up. The web log analyser I use, Analog, can read ZIP
files, so that's not a problem. I would guess you can also delete the
old ones, but I like to keep them around, myself.

 
Didn't find what you were looking for? Find more on Databases logs and logs growing too Or get search suggestion and latest updates.




Tagged: