Solved

SQL Server 2005 - Backup Log Failure

Posted on 2010-09-15
16
317 Views
Last Modified: 2012-05-10
I am running SQL Server 2005 on Windows 2003 Standard.  I have a maintenance plan with two subplans.  The first subplan runs nightly and performs a full backup of all user databases.  The second subplan runs hourly and performs a backup of the transaction logs for all user databases.  I am getting the following error in the Application Log:

BACKUP failed to complete the command BACKUP LOG OPC. Check the backup application log for detailed messages.

This same error shows up in the SQL Logs, but I'm not sure where to find the 'backup application log'.  Can anyone shed some light on this error?  I've got four databases on this server, and all four are defined in the maintenance plan but only this one is throwing the error.

A little more information: This database had a log file of over 24Gb and was filling the data drive.  Last night I backed up the log file to another disk, then ran a SHRINKFILE and a BACKUP LOG <yourdatabasename> WITH TRUNCATE_ONLY.  This reduced the log file to about 20Mb.  Not sure if these commands affected the nightly maintenance plan.
0
Comment
Question by:jduehmig1
  • 7
  • 5
  • 4
16 Comments
 
LVL 142

Expert Comment

by:Guy Hengel [angelIII / a3]
ID: 33682163
the transaction log backup will only work for databases
* in full recovery mode, after at least 1 full backup
* in bulk-logged mode, after the last backup until the first bulk-logged operation

it will fail for databases
* in simple recovery mode
* in full recovery mode before the first backup
* in bulk-logged mode after a bulk-logged operation (BCP, BULK COPY ...)
0
 

Author Comment

by:jduehmig1
ID: 33711225
The database is in full recovery mode.  All user databases are setup the same way, but only this one is failing.  I noticed yesterday that the transaction log has grown from 300Mb to 3.2Gb within a week.  I need to figure out why the backups are failing to keep the log file size in check.
0
 
LVL 142

Expert Comment

by:Guy Hengel [angelIII / a3]
ID: 33711997
please check the output of DBCC OPENTRAN
it shall reveil the transaction that keeps the transaction log from being reused...
0
 
LVL 75

Expert Comment

by:Anthony Perkins
ID: 33712180
>>I need to figure out why the backups are failing to keep the log file size in check.<<
They would "keep the log file size in check" if they were successful.  Since they are not it will continue to grow indefinitely.
0
 

Author Comment

by:jduehmig1
ID: 33725018
When I run 'DBCC OPENTRAN' on the affected database, I get the following:
No active open transactions.
I then run a manual backup of the logs.  The backup job completes successfully but the backup file is only 412Kb in size.  The database .ldf file remains at 3.7Gb.  I also ran a manual backup of the database.  This backup was also successful but did not impact the size of the .ldf file.

Am I missing something in my maintenance plan?  With no open transactions what is preventing the .ldf file from shrinking?
0
 
LVL 75

Expert Comment

by:Anthony Perkins
ID: 33727235
>>This backup was also successful but did not impact the size of the .ldf file.<<
Backups have no effect on the overall size.  The only way it is going to shrink is if you use a DBCC SHRINKFILE or DBCC SHRINKDATABASE command.
0
 

Author Comment

by:jduehmig1
ID: 33734547
From a blog I found today:
"Another option is to have the database in full or bulk_logged recovery model and perform regular transaction log backups (BACKUP LOG). The transaction log is emptied when you backup the log. Note that the log is *not* emptied for other backup types (like BACKUP DATABASE)."
So this indicates that my maintenance plans that backup the database then run a shrinkfile should be keeping the log files in check.  (I run a nightly full backup of the database and hourly backups of the transaction logs.)  However, I noticed today that the subplan that performs the shrinkfile was scheduled to run BEFORE the subplan to backup the database.  I have changed the schedule and will see over the next couple of days if there is any improvement.
0
 
LVL 142

Assisted Solution

by:Guy Hengel [angelIII / a3]
Guy Hengel [angelIII / a3] earned 250 total points
ID: 33734684
>then run a shrinkfile
this should NOT be a regular action, though.
0
How to improve team productivity

Quip adds documents, spreadsheets, and tasklists to your Slack experience
- Elevate ideas to Quip docs
- Share Quip docs in Slack
- Get notified of changes to your docs
- Available on iOS/Android/Desktop/Web
- Online/Offline

 
LVL 75

Expert Comment

by:Anthony Perkins
ID: 33740158
>>From a blog I found today:<<
I am not sure what is your point.  Again backups have no effect on the overall size. Period.

I trust you do not think that this "The transaction log is emptied when you backup the log" means your Transaction Log is going to get smaller.  What it means is that frequent transaction log backups will prevent your Transaction log file from increasing in size.  The reverse is simply not true.
0
 

Author Comment

by:jduehmig1
ID: 33744050
OK, I did interpret the statement that "the transaction log is emptied" to mean that it would be reduced in size.  I see that the log file in question is back to 3Gb after the shrinkfile yesterday.  Based on these comments, as long as the log file doesn't grow beyond that, everything should be considered 'stable'.

However, angelIII above mentioned that a shrinkfile should not be a regular action.  The dba that setup most of the maintenance plans here included a shrink database task in the nightly plan for all databases.  The plan includes: integrity check, rebuild index, reorganize index, shrink database, and update statistics.  Is there any reason I should modify this plan?
0
 
LVL 142

Expert Comment

by:Guy Hengel [angelIII / a3]
ID: 33744348
yes: performance.

if you do a daily shrink, sql will need to grow it again. ... and that is a cost operation, as it will need to occur during (read for) the transactions.... makes slow application.


0
 

Author Comment

by:jduehmig1
ID: 33744470
angelll, interesting.  What frequency would you suggest for a shrink task?
0
 
LVL 142

Expert Comment

by:Guy Hengel [angelIII / a3]
ID: 33744546
as I wrote already:
frequency for shrink task: manual

you should have some automated task to monitor file/database sizes, so you can fix issues which make the (log) file sizes just grow. but it should NOT be shrinked automatically.
0
 
LVL 75

Accepted Solution

by:
Anthony Perkins earned 250 total points
ID: 33749856
>>The dba that setup most of the maintenance plans here included a shrink database task in the nightly plan for all databases. <<
We can only hope that "dba" is no longer working there. He/she simply has not got a clue.  Any DBA who relies on maintenance plans is suspect to say the least.

The other problem with doing frequent DBCC SHRINKFILE() of your Transaction Log is that it becomes fragmented.  But don't take my word for it, see for yourself.  If the result of the following returns more than 50 rows then it is fragmented:
USE YourDatabaseNameGoesHere
DBCC LOGINFO()
0
 

Author Comment

by:jduehmig1
ID: 33779225
I use the term dba loosely.  He was actually a programmer.  As a network guy myself, I consider all programmers as suspect.  :-)

I ran the DBCC LOGINFO() query and it returned 273 rows.  All other databases on this server returned less than 50, even though they all use the same maintenance plans.  Guess I will do some research on defraging the database.

We're getting a bit off track from the original question.  I think I understand enough about what is going on that I can monitor things from this point and take actions as necessary.  I will be removing the 'shrinkfile' command from my nightly maintenance plans.  Thanks for everyone's help.
0
 

Author Closing Comment

by:jduehmig1
ID: 33779256
I will be monitoring the situation and will open a new question of other issues come to light.
0

Featured Post

What is SQL Server and how does it work?

The purpose of this paper is to provide you background on SQL Server. It’s your self-study guide for learning fundamentals. It includes both the history of SQL and its technical basics. Concepts and definitions will form the solid foundation of your future DBA expertise.

Join & Write a Comment

Suggested Solutions

Title # Comments Views Activity
Need help with a query 7 60
SQL HELP 2 75
Insert statement is inserting duplicate records 15 52
Testing connection to sql 7 52
Recently, when I was asked to create a new SQL 2005 cluster, Microsoft released a new service pack for MS SQL 2005 what is Service Pack 3. When I finished the installation of MS SQL 2005 I found myself troubled why the installation of SP3 failed …
I've encountered valid database schemas that do not have a primary key.  For example, I use LogParser from Microsoft to push IIS logs into a SQL database table for processing and analysis.  However, occasionally due to user error or a scheduled task…
Access reports are powerful and flexible. Learn how to create a query and then a grouped report using the wizard. Modify the report design after the wizard is done to make it look better. There will be another video to explain how to put the final p…
This video gives you a great overview about bandwidth monitoring with SNMP and WMI with our network monitoring solution PRTG Network Monitor (https://www.paessler.com/prtg). If you're looking for how to monitor bandwidth using netflow or packet s…

744 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

Need Help in Real-Time?

Connect with top rated Experts

11 Experts available now in Live!

Get 1:1 Help Now