On 5/21/07, Richard Sims <[EMAIL PROTECTED]> wrote:
Michael - I think you mean 05/20/2007 in the above.
yes!
There are two other factors at play as well... First, the volume location information says offsite. That suggests the use of TSM DRM, and in that case, DELete VOLHistory should not be used for pruning dbbackup volumes; and such offsite volumes need to be returned onsite (Vault state) before the pruning will work. The second factor relates to the Backup Series number, which you suspected. You had been performing dbsnapshot type backups for some time, having gotten up to 164 generations of them, where their series number is independent of full+incremental backup series numbering, and now you have the series number back to 1. TSM is confused, and refuses to perform the volhistory deletion, based upon its last- backup preservation rule. I don't know of circumstances where the series number would reset like that: Activity Log research may shed light on it.
I've also noticed that the Backup Series number has jumped from 164 to 1. The only thing that could perhaps cause this and I can think of is db reorganization that I have performed a week ago.
Did a Force work to delete it?
I haven't tried it yet. I'd prefer to figure out what's the root cause of such a weird (IMO) behavior before I attempt to delete that volume forcibly (if there is no other choice). -- Warm regards, Michael Green
