Solved

SQL Server 2005 - Backup Log Failure

Posted on 2010-09-15
16
318 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
PRTG Network Monitor: Intuitive Network Monitoring

Network Monitoring is essential to ensure that computer systems and network devices are running. Use PRTG to monitor LANs, servers, websites, applications and devices, bandwidth, virtual environments, remote systems, IoT, and many more. PRTG is easy to set up & use.

 
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.

Question has a verified solution.

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

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…
So every once in a while at work I am asked to export data from one table and insert it into another on a different server.  I hate doing this.  There's so many different tables and data types.  Some column data needs quoted and some doesn't.  What …
This Micro Tutorial demonstrates using Microsoft Excel pivot tables, how to reverse engineer competitors' marketing strategies through backlinks.
Learn how to create flexible layouts using relative units in CSS.  New relative units added in CSS3 include vw(viewports width), vh(viewports height), vmin(minimum of viewports height and width), and vmax (maximum of viewports height and width).

864 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

24 Experts available now in Live!

Get 1:1 Help Now