dbsnap still alive in volhist after delvolhist!!

[alexmartraze]

Hi guys!! I have a interesting problem...the oldest volume used for dbsnap (2010-09-24) can't be deleted. See the logs below:

tsm: TSMSERVER>q volhist
Date/Time: 2010-09-24 13:37:24
Volume Type: DBSNAPSHOT
Backup Series: 313
Backup Operation: 0
Volume Seq: 1
Device Class: CLASSLTO4
Volume Name: LTO031L4
Volume Location:
Command:
Date/Time: 2010-11-23 10:59:29
Volume Type: DBSNAPSHOT
Backup Series: 40
Backup Operation: 0
Volume Seq: 1
Device Class: CLASSLTO4
Volume Name: LTO021L4
Volume Location:
Command:
Date/Time: 2010-11-23 11:33:34
Volume Type: BACKUPFULL
Backup Series: 2,101
Backup Operation: 0
Volume Seq: 1
Device Class: CLASSLTO4
Volume Name: LTO043L4
Volume Location:
Command:
Date/Time: 2010-11-23 12:22:36
Volume Type: BACKUPINCR
Backup Series: 2,101
Backup Operation: 1
Volume Seq: 1
Device Class: CLASSFILE_BKP
Volume Name: G:\TSM\CLASSFILE_BKP\90522156.DBB
Volume Location:
Command:

tsm: TSMSERVER>delete volhist type=all todate=today totime=now
Do you wish to proceed? (Yes (Y)/No (N)) y
ANR2467I DELETE VOLHISTORY: 0 sequential volume history entries were
successfully deleted.
tsm: TSMSERVER>q volhist
Date/Time: 2010-09-24 13:37:24
Volume Type: DBSNAPSHOT
Backup Series: 313
Backup Operation: 0
Volume Seq: 1
Device Class: CLASSLTO4
Volume Name: LTO031L4
Volume Location:
Command:
Date/Time: 2010-11-23 10:59:29
Volume Type: DBSNAPSHOT
Backup Series: 40
Backup Operation: 0
Volume Seq: 1
Device Class: CLASSLTO4
Volume Name: LTO021L4
Volume Location:
Command:
Date/Time: 2010-11-23 11:33:34
Volume Type: BACKUPFULL
Backup Series: 2,101
Backup Operation: 0
Volume Seq: 1
Device Class: CLASSLTO4
Volume Name: LTO043L4
Volume Location:
Command:
Date/Time: 2010-11-23 12:22:36
Volume Type: BACKUPINCR
Backup Series: 2,101
Backup Operation: 1
Volume Seq: 1
Device Class: CLASSFILE_BKP
Volume Name: G:\TSM\CLASSFILE_BKP\90522156.DBB
Volume Location:
Command:


Any idea what happens?

 

[sjl]

Hi guys!! I have a interesting problem...the oldest volume used for dbsnap (2010-09-24) can't be deleted. See the logs below:[snippage]

Any idea what happens?

Possibly silly question: what happens if you do a delete volhist type=dbsnap tod=today tot=now? Or if you do it with a todate and totime just after the dbsnap backup in question?

 

[TonyB]

This feature is by design...no can delete the last one.

 

[sjl]

This feature is by design...no can delete the last one.

That's what I was going to say, until I noticed that there are two DB snapshot backups in volume history, not just one. I'm also wondering if the backup series number might be involved somehow (in which case, it would be a call to Tivoli Support to get it sorted.)

 

[TonyB]

Haha I didn't even look - that'll learn me. Yeah, could be a support call I think. Looks like the instance has chucked a wobbly somewhere between 2010-09-24 13:37:24 and now - the series number is larger back then than currently...maybe there's an internal check to ensure that the series number is less than it is now before purging the old snapshot.

 

[alexmartraze]

Hi friends...I will try an unload/load and auditdb on next weekend, after this I will contact IBM suport if not work.

But if anyone have another tip I apreciate.

Thanks a lot

 

[hogmaster]

you could try:

del volhist vol=000000E1 force=yes type=remote todate=today

 

[alexmartraze]

The following command work:

tsm: TSMSERVER>del volhist vol=lto031l4 force=yes type=dbsnapshot todate=today
Do you wish to proceed? (Yes (Y)/No (N)) y
ANR2467I DELETE VOLHISTORY: 3 sequential volume history entries were
successfully deleted.

It delete all my dbsnapshot backups, but it's not a problem, I will do a new dbsnap backup right now.

Thanks hogmaster.

 

[sjl]

While looking for information on an unrelated issue, I came across this nugget in the ADSM quick facts file:

Note: After a DSMSERV LOADDB (as in a database reload), the Backup Series number will revert to 1...which can royally confuse TSM and cause it to refuse to honor a DELete VOLHistory on the last volume of the previous series.

I think we have a root cause. :up: