ADSM-L

Re: Obacktrack

1998-09-18 09:35:51
Subject: Re: Obacktrack
From: "Burtenshaw, Barry L." <Barry.Burtenshaw AT STDREG DOT COM>
Date: Fri, 18 Sep 1998 09:35:51 -0400
Tom,

We are using BMC/Datatools SQL-BackTrack to backup our Oracle databases
through ADSM. The following info is based on my recent experiences.

SQL-BackTrack stores files into ADSM and marks those files as active.  Then
when SQLBackTrack's expiration hits, it "deletes" those old files by issuing
a delete object API call to change the status of the object from active to
inactive on the ADSM server.  Once the files are inactive they are deleted
from ADSM after the expiration process is run based on the ADSM copygroup
for the active mgmtclass. Therefore, if your obacktrack expiration is 1
month and your adsm expiration is 3 months you keep those files for 4
months.  BMC has a utility that works on AIX that allows you to "manually"
delete objects.  However,  even if you use that utility to "delete" objects
they would still be there for 3 months (in this case).

On our systems the problem was worse because our obacktrack expiration was
set to 365 days and our ADSM was 180.  And, we weren't using a separate
mgmtclass for the obacktrack objects.  I didn't think I could rebind the
existing objects in ADSM to a new mgmtclass. So to resolve this I had our
DBA's create a new backuppool in SQL-BackTrack using a new
mgmtclass/copygroup that I created in ADSM.  This copygroup has VEREXIST=1,
VERDELETE=0, and RETONLY=0.  This was based on information in an IBM Redbook
titled Oracle Backup and Recovery with ADSM.  (Using ADSM to Back Up
Databases.  Chapter 4 SQL-BackTrack.)  These copygroup options will result
in the inactive objects being deleted immediately the next time an
expiration process is run on the ADSM server.  Then I had the DBA's modify
our existing SQL-BackTrack profile to use that backuppool.  As a result our
backed up files were going to a different filespace in ADSM.  This
backuppool has an expiration of 30 days and once SQL-BackTrack expires them
they will also be removed from ADSM. The first backup that ran with this was
successful with errors.  After every tablespace it looked like SQL-BackTrack
was trying to delete old info because the expiration had changed and this
bombed out (I think due to the size of the delete statement).  The second
time the first tablespace was ok, it made it thru the second and then
bombed.  I ended up running each tablespace manually to "fix" this.  After a
week of backing up data to the new filespace, I deleted the old filespace in
ADSM and freed up the majority of our tapes.

Good luck,
Barry

Barry L. Burtenshaw                                     Standard Register
Senior UNIX Systems Administrator       P.O. Box 1167
(937) 443-1737 direct                           Dayton, OH 45401-1167
(937) 586-6410 fax
(888) 742-9200 alpha page                       600 Albany Street
(888) 572-9740 numeric page                     Dayton, OH 45408


> -----Original Message-----
> From: Fluker, Tom R [SMTP:Tom.Fluker AT VIASYSTEMS DOT COM]
> Sent: Thursday, September 17, 1998 09:29
> To:   ADSM-L AT VM.MARIST DOT EDU
> Subject:      Obacktrack
>
> We're using the BMC/Datatools Obacktrack product to backup Oracle
> databases...  My problem is in convincing all of the Obacktrack/ADSM magic
> to actually remove old versions of the backup data.   The virtual files in
> ADSM are created by Obacktrack using the API and it doesn't seem to be
> deleting them....
>
> BMC offered the suggestion of "setting RETAINONLY and/or VERDELETED to
> zero".  I tried setting VERDELETED to zero, expiring inventory, but (alas)
> still have the same gigantic volume of data in the effected filespaces...
>
> Does anyone have any suggestions or experience with this???
>
> Thanks,
> Tom Fluker
<Prev in Thread] Current Thread [Next in Thread>