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?
promapAsked:
Who is Participating?
 
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
 
JaffaKREECommented:
Is the recovery model set to FULL ?
0
 
promapAuthor Commented:
Yes
0
Upgrade your Question Security!

Your question, your audience. Choose who sees your identity—and your question—with question security.

 
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
 
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
 
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
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.