I think you might be asking how to get a list of volumes that will be
deleted by the command. Is that right? You might try
select volume_name from volhistory where backup_operaton is not null and
location='THE STRING YOU USE TO DENOTE OFFSITE' and
date_time<(current_timestamp-(1 month)-(7 days))
to get your list of dbbackup volumes to return and then run your delete.
You will have your vault return the volumes using the list generated by the
select statement. I don't know if this will work for you, but it seems to
give me the correct list of dbbackup volumes on my box. By the way, the -(1
month) part is due to the fact that I'm running 3.1.2.50 and have to account
for the SQL current_timestamp bug. If you're running a different version,
you probably won't have that problem.
Alex Paschal
Storage Administrator
Freightliner, LLC
(503) 745-6850 phone/vmail
-----Original Message-----
From: Rupp Thomas (Illwerke) [mailto:[EMAIL PROTECTED]]
Sent: Monday, November 06, 2000 9:06 AM
To: [EMAIL PROTECTED]
Subject: AW: ORMSTATE in UPDATE VOLHISTORY
Hi Richard,
thanks very much for your reply.
As we don't have DRM I have to use the location field to mark my
Database backups as offsite.
Is my understanding correct that
DELETE VOLHISTORY TYPE=DBBACKUP TODATE=TODAY-7
will delete all db backup volumes older then 7 days - ignoring the
content of the LOCATION field?
Therefore I will have to sort out all deleted db backup tapes manually
and return them to our robot?
There seems to be no way to handle db backup tapes the way copy
storage pool tapes are handled - right?
Thanks a lot for clearing up this mystery!
Thomas Rupp
