October 21, 2011 at 12:12 pm
I need some opinions here.
I am using a backup solution (will remain nameless) that fails if a tlog backup is triggered during a full or a diff. This was not an issue in the last release. It just started breaking with the latest release of their software.
SQL Server allows this to happen and it handles it. I know it's a special case, BUT IT WORKS.
The vendor is suggesting that they dont need to fix it because it is a 'limitation' of SQL Server. I'm guessing that means I would need to put a special schedule in place to garuntee a log backup doesn't kick off during a full.
How would you all respond to this?
Thanks,
Kim
October 21, 2011 at 12:21 pm
The vendor doesn't have a frigging clue what they're talking about. I can run full, diff and log backups simultaneously, all will succeed. (the diff will wait until the full is complete, the log will run simultaneous). A backup failure should be a bug. SQL can handle it, their software should too.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
October 21, 2011 at 12:43 pm
GilaMonster (10/21/2011)
The vendor doesn't have a frigging clue what they're talking about. I can run full, diff and log backups simultaneously, all will succeed. (the diff will wait until the full is complete, the log will run simultaneous). A backup failure should be a bug. SQL can handle it, their software should too.
I'll say "Amen" to that. If this vendor's software is supposed to be compatible with Microsoft SQL Server, then perhaps involving the Microsoft CSS team could help. CSS will, no doubt, say pretty much the same thing as Gail (if they don't just break out in laughter instead).
I would think that this would apply pressure on the vendor to actually resolve the problem, because if their software can't handle this situation, then it isn't truly compatible. Of course, it could also be that the tech support person you talked to was full of it and just wanted to get you off the phone as soon as possible. In either case, I believe that involving Microsoft would force your vendor to give you a real solution.
October 21, 2011 at 12:52 pm
I've tested simultaneous full and log backups, never had a problem with it.
Every night, on my production servers, full backups run at midnight. So do log backups. Every night. Multiple servers. Never a problem once.
They're trying to shift blame for a flaw in their software and hoping you won't check their claims. That's all. Smoke and mirrors.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
October 21, 2011 at 1:53 pm
kstjacques (10/21/2011)
I need some opinions here.I am using a backup solution (will remain nameless) that fails if a tlog backup is triggered during a full or a diff. This was not an issue in the last release. It just started breaking with the latest release of their software.
SQL Server allows this to happen and it handles it. I know it's a special case, BUT IT WORKS.
The vendor is suggesting that they dont need to fix it because it is a 'limitation' of SQL Server. I'm guessing that means I would need to put a special schedule in place to garuntee a log backup doesn't kick off during a full.
How would you all respond to this?
Thanks,
Kim
Rattle the vendors cage. Check with your accounting dept. if any invoices from the vendor are outstanding, have accounting contact the vendor's accounts receivable dep. and inform them your firm is with holding payment of $xxx.xx until the problem is fixed.
Never fails to get attention focused on your problem.
October 21, 2011 at 3:21 pm
Agree with the other posts, I have seen and run tlog backups while the full is running, as a matter of fact one of my REALLY large databases could hardly be backed up without risk if I didn't have it that way. It just takes too long to risk losing that much data. And SQL handles it without problem.
Where I can definitely see an easy out to push it to the vendor is "It just started breaking with the latest release of their software." So the introduced a limitation not related to what SQL allows.
CEWII
October 21, 2011 at 3:32 pm
#5 on the +1.
This is my setup as well. I actually have 4 full backups running exactly at the same time + a log backup (all kicking off extactly @ midnight).
Never failed after 3 years and this is sql 2K5 so recent versions "should" also work :hehe:.
I'd ask them to call CSS. Should give the ms folks a good laugh at next xmas party :-D.
October 21, 2011 at 3:56 pm
Is this software somehow certified/validated by MS? I am guessing not if this is happening.
October 21, 2011 at 4:33 pm
The vendor may be thinking of a limitation in SQL2000 which was removed from SQL2005 on.
does not excuse the vendors advice though.
proof:
http://sqlskills.com/BLOGS/PAUL/post/Search-Engine-QA-16-Concurrent-log-and-full-backups.aspx
---------------------------------------------------------------------
October 21, 2011 at 4:41 pm
george sibbald (10/21/2011)
The vendor may be thinking of a limitation in SQL2000 which was removed from SQL2005 on.
Yeah, but that just made the log backup wait until the full completed. It didn't make the log backup outright fail.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
October 21, 2011 at 5:21 pm
going back a bit more I think it might have failed in SQL server 7. Been a long time though so not sure,
wouldn't be surprised if the vendor had a misunderstanding of an out of date piece of information.
---------------------------------------------------------------------
October 21, 2011 at 8:42 pm
Thank you for all your responses!
So the good news is the vendor is saying they will look into fixing the issue.
My favorite part of the latest response was: "if you can some how stagger the backups to minimize overlap that would hopefully minimize your failed backups."
I'm just really miffed that it was referred to as a 'limitation' in SQL Server. It's like calling my baby ugly 🙂
-Kim
October 22, 2011 at 10:34 am
kstjacques (10/21/2011)
Thank you for all your responses!So the good news is the vendor is saying they will look into fixing the issue.
My favorite part of the latest response was: "if you can some how stagger the backups to minimize overlap that would hopefully minimize your failed backups."
I'm just really miffed that it was referred to as a 'limitation' in SQL Server. It's like calling my baby ugly 🙂
-Kim
Why do you use that 3rd party "tool" in the first place?
Is there any real advantage over the "built-in" SQL Server backup method?
(Other than failing occasionally, of course 😉 )
October 23, 2011 at 5:59 am
LutzM (10/22/2011)
kstjacques (10/21/2011)
Thank you for all your responses!So the good news is the vendor is saying they will look into fixing the issue.
My favorite part of the latest response was: "if you can some how stagger the backups to minimize overlap that would hopefully minimize your failed backups."
I'm just really miffed that it was referred to as a 'limitation' in SQL Server. It's like calling my baby ugly 🙂
-Kim
Why do you use that 3rd party "tool" in the first place?
Is there any real advantage over the "built-in" SQL Server backup method?
(Other than failing occasionally, of course 😉 )
I just hope the vendor isn't one near & dear to my heart.
Yeah, there are lots of reasons to use a third party backup method. For example, we have better compression than native. Plus we offer compression in versions of SQL Server that don't do it natively. Add in stuff like storage compress, virtual restore... lots of reasons to use 3rd party software... assuming they work.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
October 23, 2011 at 6:08 am
Grant Fritchey (10/23/2011)
...I just hope the vendor isn't one near & dear to my heart.
Yeah, there are lots of reasons to use a third party backup method. For example, we have better compression than native. Plus we offer compression in versions of SQL Server that don't do it natively. Add in stuff like storage compress, virtual restore... lots of reasons to use 3rd party software... assuming they work.
I'm sorry Grant for being not precise enough...
I questioned the 3rd party tool mainly because of the error and the response by the vendor (blaming SQL Server).
I should have added that, if a 3rd party tool need to be used, it should be RedGates "SQL Backup Pro" or "SQL HyperBac" :cool::-D
And I agree, there are valid reasons to use it. 🙂
Viewing 15 posts - 1 through 15 (of 43 total)
You must be logged in to reply to this topic. Login to reply