Anyone know if this is fixed?

[GregE]

TDP SQL 5.5.5.0

Not long ago I changed a mgmt class then backed up an existing database (I was trying to change it's retention without affecting all DBs on that node). Then I changed the mgmt class back to what it was, and noticed that now full backups of this database generate this error........

ANS0328E (RC45) The specified objects failed the merge test.
http://www-01.ibm.com/support/docview.wss?uid=swg1IC33026

I did not change the mgmt class itself. I bound the full backup to a different mgmt class. I guess the result is the same though the technote doesn't read exactly that way.

Anyone know if this is addressed in a newer version or patch?

 

[moon-buddy]

I don't think that this will be fixed in any release.

What I understand is that when you rebind to a new management class, the TSM environment tracking this backup is reset, and is not matched to any existing backup. Thus, full backups should be re-run from the point the management class has been changed.

BUT I MAYBE WRONG, AND I HOPE I AM! It is really a pain not to be able to re-point to another management class without starting all over.

 

[GregE]

So, is there any other option other than to create new node (for this one database, ugh!)? If I remove ALL backup data for this database, can I then start backing it up as I always have, bound to the original mgmt class? (Since I only had it changed for a single run of a backup, then changed it back)

 

[moon-buddy]

You can change the retention settings within the management class and this should not affect the backup 'behaviour' if this is what your original intention was. However, as you know, all nodes at this management class takes in the new settings.

Further, I don't think you need to delete old backups. You only need to do a fulll backup after moving the node to the new management class. This now becomes the new starting point.

 

[GregE]

This is what I did, which caused the issue. Let me see if I can clarify a bit.

I changed one existing database binding to "NEW_MGMTCLASS" then ran a full backup of it. I then changed that DB back to use the "OLD_MGMTCLASS" and ran a full backup, thinking I would just be back to normal. The next full backup gave the error and has been giving that error ever since.

So I didn't change any settings within a mgmtclass. I didn't want a change to apply to all DBs bound to that mgmtclass. Technote says that would cause it too, as would having meta and bitfile data going to different copy destinations - the latter is exactly what I have.

I see what you are saying. If I delete all data for that DB, I have no history and I begin a new starting point. But if I bind to a new mgmtclass, I still am at a new starting point but at least I have my history bound to the old mgmtclass. That sound right? I would like to be able to get this back to the existing mgmtclass with all other DBs on that node.

I think I'll get the SQL dba to take a native SQL backup then do something more with TDP to get this straight.

 

[GregE]

Ok, so what I did was:

1) Create a new temporary node, JUST for this one DB. (uugh)
2) Removed the DB from the rest of the existing node's backup list so it doesn't backup with that group of DBs, for the next 14 day retention period, but the data will exist as it is.
3) Meanwhile I'm backing up the temporary node for the next 14 days and can then deactivate that db from the old node's db list.
4) THEN, I can put the db back into the old node's DB list, and in another 14 days, delete the temporary node's data and the temporary node. Too painful.

Now I'm getting wind of a possible business requirement change for some SQL backup retentions. From this I just had to go thru, that change is going to be beyond tedious.

Has to be a better way to deal with this. If anyone knows of one, PLEASE chime in.

 

[GregE]

I just read the technote again. I think I may be pulling all my hair out sometime in the near future.

 

[GregE]

More info. So I created the new node to backup only one DB (DB1). The other 10 DBs are backed up under the old node.

14 day retention passed, so I re-added DB1 back into the mix of the current node.................and it errors the same.

So, what this means is, I have to create a new node which backs up all 11 dbs. I can't just remove one db from the current node's list and then add it back.

This is very very bad architecture, IBM. Retention requirements sometimes change, and this has made those changes very difficult for TDP SQL backups.

 

[GregE]

I have not yet used the v6.x versions of SQL TDP. Has there been a redesign that would address, and FIX, this type of situation? This can be a very ugly effort to undertake if a change in management class is required.

 

[DanneFr]

Hi

same problem with sql tdp 6.x.