How do you mark a file as inactive. This is not visible from SQLBACKtrack.
eg I would like the filespace below to be marked inactive. Output from 'show
versions'
/MFS_REMDEV_ARSystem_P:sbackups.physical : /MFS_REMDEV/
ARSystem-0.28-10-1998.03:01:47-22117 (MC: DEFAULT)
Active, Inserted 10/28/98 02:51:39
Jasdayal S Dhanoa
MCI WorldCom Phone: 0171 675 3423
> -----Original Message-----
> From: Bruce Elrick [SMTP:belrick AT HOME DOT COM]
> Sent: Wednesday, March 24, 1999 3:49 PM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: ADSM and Oracle - File Expiration
>
> Scott...
>
> SQLBackTrack stores backups of physical files or logical exports using
> pseudo-filenames that includes time stamps, so every time you do an SQL
> BackTrack backup ADSM is given a new set of unique objects. Thus there
> are
> never more than one 'version' of a 'file'. That is why versions-exists
> can
> safely be set to 1 and retain-extra can be set to zero (recall retain
> extra
> affects the retention of the 2nd, 3rd, etc. oldest versions of a file, of
> which
> there are none in this case). The versions-deleted is set to 0 so that
> when
> SQL BackTrack tells ADSM to delete an object, which it does after the two
> weeks
> you've set it to, ADSM will mark it for expiration the next time
> expiration is
> run (within 24 hours typically). The retain-only is set to zero for the
> same
> reason; once SQL BackTrack decides to delete the file, it is of no use to
> retain that last-good-version and longer.
>
> Hope that clears it up.
>
>
> Cheers...
> Bruce
>
> Scott Fluegge wrote:
>
> > 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????
>
> --
> Bruce Elrick, Ph.D.
> mailto:belrick AT home DOT com
> http://members.home.net/belrick/
|