Solved

SQL Server 2005 LDF will not shrink

Posted on 2010-08-26
11
896 Views
Last Modified: 2012-05-10
I have a SQL 2005 database with a rapidly-expanding logfile that I cannot get to stay at a reasonable size.  

- LDF has already filled disk once, forcing me to Detach, delete & then re-attach db
- Two days later it's already back up to 12 gig and growing steadily.
- Recovery model is already set to Simple.  Switching to Full then back to Simple has no effect.
- Daily maintenance plan including a Shrink, which has no apparent effect.
- Manually executing dbcc ShrinkFile('hydroweb_log',2) also has no effect, but returns the following:

Dbld  Field  CurrentSize   MinimumSize   UsedPages    EstimatedPages
10       2        1409936       128                     1409936         128

I'm not seeing anything unusual in the logs, nor any unusual activity in the monitor.
0
Comment
Question by:hydrofarm
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 3
  • 2
  • 2
  • +3
11 Comments
 
LVL 143

Expert Comment

by:Guy Hengel [angelIII / a3]
ID: 33539502
please show the output of DBCC OPENTRAN on this database?
0
 
LVL 35

Expert Comment

by:David Todd
ID: 33540120
Hi,

If your running simple recovery model and log is still growing, then you have some very long running transactions. That is what AngelIII is getting you to look for.

Does a
backup log with no_log help any? I imagine not much if at all in this instance.

Regards
  David
0
 
LVL 49

Expert Comment

by:Vitor Montalvão
ID: 33540226
Can also be reindex job. Depends how big are the tables.
0
Optimizing Cloud Backup for Low Bandwidth

With cloud storage prices going down a growing number of SMBs start to use it for backup storage. Unfortunately, business data volume rarely fits the average Internet speed. This article provides an overview of main Internet speed challenges and reveals backup best practices.

 
LVL 12

Accepted Solution

by:
pastorchris earned 250 total points
ID: 33540886
Try looking up long running transactions which could be making your log file grow.
The size of the log file for a database in simple recovery mode is dependent on a number of factors like:
- Length of transactions (long running transactions will grow the logs)
- Nature of transactions (transactions with lots of looping before a commit will grow the logs)
- Type of transactions (database maintenance exercises like reindexing huge tables grow the logs)

The best way of understanding your database system is by looking at the transactions which grow so that you're able to identify which ones grow the log most.

Launch SQL profiler to look at the nature of your transactions.
View sessions in SMSS process monitor to see the long running sessions.

Look at tempdb
Query against sysprocesses table (master db) to see the long running queries possibly you could get a hint.

Later on you might realise that your database actually requires more disk spacer because of this nature of transactions.

Also note that choosing the recovery model of your database should not be based on the disk free space available but it should be based on how critical your data is and then let the business buy more space since it has critical data.

Regards,
Chris Musasizi

0
 
LVL 12

Expert Comment

by:pastorchris
ID: 33540905
I know you did not say this but if your log file has some space in it and you simply cannot free it by shrinking the file using DBCC SHRINKFILE, then you might have to first of all grow it by say 1 MB, then shrinking will work for you.

All the best.

Regards,
Chris Musasizi.
0
 

Author Comment

by:hydrofarm
ID: 33543099
Here is the output of DBCC OPENTRAN:

Replicated Transaction Information:
        Oldest distributed LSN     : (0:0:0)
        Oldest non-distributed LSN : (799344:175:1)
DBCC execution completed. If DBCC printed error messages, contact your system administrator.

One recent change that might be a suspect here is replication - I recently configured snapshot (not transactional) replication of some tables to another server.  Could that be the issue, even though I configured to create a snapshot only once a day?

sysprocesses.csv
0
 
LVL 49

Assisted Solution

by:Vitor Montalvão
Vitor Montalvão earned 250 total points
ID: 33543225
Databases that are in replication process need to be in full recovery mode, so that's explain why your transaction log grows a lot.
You need to make regular transaction log backups so you can empty LDF file.
0
 

Author Comment

by:hydrofarm
ID: 33543904
Ok, thanks for the info regarding replication vs. recovery mode.  However, when running the following:

BACKUP LOG hydroweb WITH TRUNCATE_ONLY
DBCC SHRINKFILE(hydroweb_log, 1)

I get this error -

Cannot shrink log file 2 (hydroweb_log) because all logical log files are in use.

Is the replication process preventing nightly shrink and ultimately causing my bloated LDF?
0
 
LVL 75

Expert Comment

by:Anthony Perkins
ID: 33544382
>>LDF has already filled disk once, forcing me to Detach, delete & then re-attach db<<
This is a very bad idea.  You are risking corrupting your database.

>>Is the replication process preventing nightly shrink and ultimately causing my bloated LDF?<<
It is likely or the absense of any type of Transaction Log backups would also do it.
0
 

Author Comment

by:hydrofarm
ID: 33546113
Ok, I think I may have this resolved.  I cleared the replication queue on the db I was having trouble with (which also recently became a replication publisher.)

EXEC sp_repldone @xactid = NULL, @xact_segno = NULL,  @numtrans = 0, @time = 0, @reset = 1

Then did a log backup & shrink, which emptied my LDF.  I'll give it a few days and see if it was just a replication glitch that occurred while I was setting things up.  If not I'll re-post as a question re: replication.
0
 
LVL 75

Expert Comment

by:Anthony Perkins
ID: 33547725
>>Then did a log backup & shrink, which emptied my LDF.<<
Because of the number of times you have had to shrink the Transaction Log it must be highly fragmented, I would recommend you get that resolved as soon as possible or performance will not be optimal.
0

Featured Post

Industry Leaders: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Suggested Solutions

by Mark Wills PIVOT is a great facility and solves many an EAV (Entity - Attribute - Value) type transformation where we need the information held as data within a column to become columns in their own right. Now, in some cases that is relatively…
In this article we will get to know that how can we recover deleted data if it happens accidently. We really can recover deleted rows if we know the time when data is deleted by using the transaction log.
Are you ready to implement Active Directory best practices without reading 300+ pages? You're in luck. In this webinar hosted by Skyport Systems, you gain insight into Microsoft's latest comprehensive guide, with tips on the best and easiest way…

733 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question