We had the same issue.  This is what we found.  You should have a different
management class for your database backups.  The versioning needs to be set,
so when ebu, backtrack, or the connect agent marks it inactive, the adsm
expire inventory process will remove them.  We did not have this in place
and backup database data would not go away.

To fix it: We had all DBA's use a new filespace for backups for 45 days.
This made sure that all was well before we deleted anything.  We then
created an new management class, with VerExist = 1, RetainOnly=0.  This way
when the files are marked inactive they are removed from ADSM.  We then
removed the old filespaces.  Freed up lots of tapes, and db space.



Anthony Jones
Platform Technologist - ADSM Administrator
Koch Industries, Inc.
Cultivate trusted business partnerships by continuously improving the
delivery of cost-effective and measurable platform and network management
services.


> -----Original Message-----
> From: Roger Hohmann [SMTP:Roger_Hohmann AT WESTLB DOT DE]
> Sent: Wednesday, March 24, 1999 10:06 AM
> To:   ADSM-L AT VM.MARIST DOT EDU
> Subject:      Re: ADSM and Oracle - File Expiration
>
> Most connect agents I know work following way( I just know ebu and
> exchange, but rman might work the same):
>
> While backing up an object (database), they are creating an unique
> object in adsm and have it marked active. Active objects are reflecting
> the actual state of the clients and are never deleted by automatic adsm
> functions.
>
> While the next backup occurs, changed files are backed up again and the
> older backups are changed to inactive state. Now expiration processing
> affects.
>
> Connect agents have similar processing - but: objects are marked
> inactive by the agent. This will work when you are deleting backup sets
> with ebu. Now the adsm objects are marked inactive, expiration
> processing occurs.
>
> When you are using a value > 0 for verd, your objects are never deleted
> in adsm, but are inaccessible from rman or ebu.
>
> So it is needed to use the published values for expiration parameters,
> because ebu has control about deletion of the backup files in adsm.
>
> Regards Roger
>
> -----Original Message-----
> From:   Scott Fluegge [SMTP:sfluegge AT VENATORGROUP DOT COM]
> Sent:   Wednesday, March 24, 1999 4:25 PM
> To:     ADSM-L AT VM.MARIST DOT EDU
> Subject:        ADSM and Oracle - File Expiration
>
> Any Ideas?
>
> I have several ADSM servers running on AIX.  I am using the ADSM
> Disaster
> Recovery Manager.  My problem is that I am running out of tapes in my
> 3494.
> I ran an SQL query to see how much Oracle data I was holding and I
> found
> that there  were many data files out there a far back as last August.
>  SQL
> Backtrak is set to only hold them for two weeks!  I talked to support
> and
> they told me that I should set my retain extra version and retain only
> version parameters for the Oracle management class to 0.  (I had them
> set
> to 1).
>
> First,  can someone tell me how that will work?  With a setting of 0 it
> seems like it won't hold anything!
>
> Second, can anyone tell me how SQL deletes the files and how ADSM knows
> that they have been deleted?  Since every file SQL sends to ADSM is
> given a
> time stamp, they all are unique....
>
> I did what they told me to, I reset those parameters.  I then ran
> expiration and reclamation.  I did find that expiration deleted several
> thousand files.  I also gained many tapes.  The problem is, when I ran
> the
> query against the ADSM database, I found almost all of those old Oracle
> files were still there.  I have no idea what was expired!!  This was
> about
> two weeks ago.  I am again running out of tapes.  I think I still have
> a
> problem, We are at a point where our copy pool sizes should be stable.
> Data should expire at the rate we get more info.  BUT, I am still
> growing
> at about 50 gig a night.  I have upgraded my server to 3.1.2.15
>
> Any suggestions????