ADSM-L

Re: [ADSM-L] SQLServer TDP diff backups failing

2011-01-04 09:32:52
Subject: Re: [ADSM-L] SQLServer TDP diff backups failing
From: Del Hoobler <hoobler AT US.IBM DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Tue, 4 Jan 2011 09:29:11 -0500
Hi Steve,

It is difficult to diagnose this with the information provided.
I agree it is strange that some backups work and other do not,
but I suspect that things aren't configured quite as you expect.

The one idea that comes to my mind is if an "out of band" backup
was done on a few of the databases as some point. If that backup
did not use the correct management classes, it could have
introduced the "merge test" problem.

The best thing at this point is to have the IBM service team
closely examine your configuration and results to help you.
I recommend placing a call with IBM support.

Thanks,

Del

----------------------------------------------------

"ADSM: Dist Stor Manager" <ADSM-L AT vm.marist DOT edu> wrote on 01/03/2011
02:57:47 PM:

>> From: "Schaub, Steve" <steve_schaub AT BCBST DOT COM>
>> To: ADSM-L AT vm.marist DOT edu
>> Date: 01/03/2011 02:58 PM
>> Subject: SQLServer TDP diff backups failing
>> Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT vm.marist DOT edu>
>>
>> TSM Server 5.4.3.2
>> TSM Client 5.5.1.0 on Windows 2003 SP2 x64 w/SQLServer 2005
>> TDP Client 5.5.2.0
>>
>> When a restore request came in for a particular SQLServer instance,
>> I discovered that the daily diff backups of all but 2 databases in
>> that instance had been failing since last October, with the
>> following error message:
>> ANS0328E (RC45)   The specified objects failed the merge test.
>>
>> I have encountered this before, so I know about the limitation of
>> not changing mgmtclasses on these types of clients.
>> Here are the things that puzzle me about this:
>>
>>
>> 1.       All of my SQL Server nodes backup under a common nodename
>> (in order to make cross-server restores easier).  I use client
>> option sets to control the mgmtclasses, so how could every other
>> SQL backup be working except this one, since they are all using the
>> same nodename and policy?  Note - they each have their own nodename
>> for scheduling, the script they run then uses an optfile that
>> contains the common nodename for the backup itself.
>>
>> 2.       Why would the full backups work, and the diffs fail?  Why
>> is one instance failing, and the other one working?  And then, why
>> are 2 of the databases working, and all the rest failing?  I would
>> have thought that this problem would lead to any backup failing?
>>
>> 3.       According the the DBA's, SQLServer is recording a
>> successful backup every time - this is the most disturbing, since
>> it prevented us from detecting this failure until too late.  Part
>> of the problem is that the error code (402) is the same one that we
>> see for offline databases, which led to the failures being
>> dismissed by our Admin team as "normal".
>>
>> TIA,
>>
>> Steve Schaub
>> Systems Engineer II, Windows Backup/Recovery
>> BlueCross BlueShield of Tennessee
>>
>>
>> -----------------------------------------------------
>> Please see the following link for the BlueCross BlueShield of
>> Tennessee E-mail disclaimer:
http://www.bcbst.com/email_disclaimer.shtm

<Prev in Thread] Current Thread [Next in Thread>