[Webinar] Streamline your web hosting managementRegister Today

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 977
  • Last Modified:

SQL Server not truncating logs after BACKUP LOG command

I've been reading through a lot of old posts and other resources on the internet, but I'm still having a problem getting my transaction logs to truncate correctly.

I'm trying to set up log shipping for my SQL 2000 standard server and I'm using Microsoft's Simple Log Shipper stored procedures included on the SQL Resource Kit.  According to everything I'm reading from Microsoft and the internet whenever a BACKUP LOG command is issued the transaction logs are supposed to truncate on their own.  However my logs continue to increase in size and the only way I've found to get them to come back down is to manually issue a shrink command against the log files.  

I've read a lot of posts where people are saying run the command with a TRUNCATE_ONLY tag on the end, but others are saying if you do that log shipping won't work.  The command Microsoft uses in their procedure is BACKUP LOG TO DISK but they don't have a TRUNCATE_ONLY tag anywhere.

Can anyone help?
0
promap
Asked:
promap
  • 5
  • 4
  • 3
  • +2
1 Solution
 
JaffaKREECommented:
Is the recovery model set to FULL ?
0
 
promapAuthor Commented:
Yes
0
 
JaffaKREECommented:
Are you sure that the log shipper procedures contain a "backup log" statement ?  

We use the full log shipping through SQL here, and I know the logs get backed up and truncated when it  happens.
0
Get expert help—faster!

Need expert help—fast? Use the Help Bell for personalized assistance getting answers to your important questions.

 
promapAuthor Commented:
Yeah, I printed out the stored procedure Microsoft is using and it has:

BACKUP LOG @dbname TO DISK = @backupfilename

I've looked and files are moving from server a to server b I just can't figure out why it isn't truncating anything.

0
 
mastooCommented:
If you run:

dbcc sqlperf( LOGSPACE )

I presume you are saying the Log Size is growing, but what about the Log Space Used?  Since you say shrink makes the log smaller, I'm assuming you'll see essentially 0 Log Space Used immediately after a transaction log backup.
0
 
promapAuthor Commented:
I ran that command and on the databases I recently switched to Full recovery mode the log size is growing (on average my other database log sizes are ~1MB).

For example, my biggest databases are as follows:

Log Size: 2914MB
% Used: 57.79

Log Size: 1109MB
% Used: 74.23

This may be a stupid question, but what exactly does the % used mean?  I thought the log files would just grow as needed with no set limit?
0
 
JaffaKREECommented:
There is an allocated space for both data files and log files.  SQL takes this space from the OS as soon as the log/data files are created.  So if you have a tiny database and specify a 10GB log, SQL will reserve that 10GB, even though the log file may actually only contain 100K of data.

0
 
mastooCommented:
and on those two examples you gave, you're saying the log size continues to increase and the %used does or does not drop to near 0 after you do your log backup?
0
 
JaffaKREECommented:
The Log size will not increase or decrease, unless the log becomes completely full and is forced to auto-grow.

The % used should become close to zero after a backup log statement is executed.
0
 
MichaelSFullerCommented:
0) Always make a backup before you do this.
1) Put the database in simple recovery model.
2) Issue a DBCC SHRINKFILE or DBCC SHRINKDATABASE command.
3)Once completed look at the log files again. If they have not shrunk issue a a DBCC CheckDB() and depending on your evironment, you should use either estimate or repair options. Once complete issue the shrinkfile command.

This happens frequently with replication. Oh ya, make sure you have your most recent service pack on when you do the backup, to avoid the stuck in loading bug  
0
 
arbertCommented:
Agree with MichaelSFuller, the logfile usually doesn't reclaim space on its own--use DBCC SHRINKFILE (dbcc shrinkfile(yourdatabase_log,0) ) after your backup.

Brett
0
 
promapAuthor Commented:
Well the first couple times I ran the BACKUP LOG statement manually it didn't appear that the % used was dropping that much but I've been watching it and it is now dropping close to 0 after a BACKUP LOG statement.  I was also able to issue a SHRINKFILE command via Query Analyzer but if I want to automate that part how can I put it into a stored procedure?  The log shipping one MS uses runs in the master table and every time I try to tell it to shrink another database it tells me it can't find the file.

0
 
MichaelSFullerCommented:
1) You could use shrinkdatabase and it will work fine.
2) Have that stored procedure, call a stored procedure in the database your shrinking that executes the shrinkfile command.
3) Make the next step on your job issue the shrinkfile command
0
 
arbertCommented:
"shrinkdatabase and it will work fine"

I wouldn't shrink the size of the database unless you have a requirement too--slows down when the data files have to regrow--that's why I would recommend DBCC Shrinkfile and just the logfile...
0
 
MichaelSFullerCommented:
That's very true, it could cause a performance degrade, I was thinking more along the lines of a truncate only.
0
 
promapAuthor Commented:
I'm gonna give this one to Michael because adding a shrinkfile as the next step finally got this entire thing to work correctly.
0
 
arbertCommented:
"I'm gonna give this one to Michael because adding a shrinkfile"

Like I said on my post dated 10/16/2004 10:43AM MDT.....
0

Featured Post

Free Tool: Path Explorer

An intuitive utility to help find the CSS path to UI elements on a webpage. These paths are used frequently in a variety of front-end development and QA automation tasks.

One of a set of tools we're offering as a way of saying thank you for being a part of the community.

  • 5
  • 4
  • 3
  • +2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now