When I query as ROOT there are 'active' and  'inactive' versions on the server.
This leads me to believe that my management class is set up improperly for the
server ( i.e. all ORACLE filespaces should be managed by there own management
class).  It does not, however, explain why ORACLE ownership is gone.  Unless I
am missing something?

Sean McNamara
PJM Interconnection L.L.C.
(610)666-4206



> -----Original Message-----
> From: France, Don (Pace) [SMTP:don.france-eds AT EDS DOT COM]
> Sent: Monday, December 27, 1999 14:53
> To:   ADSM-L AT VM.MARIST DOT EDU
> Subject:      Re: SQL-Backtrack filespace deletion.
>
> So... the question now becomes "when you query as ROOT,
> are the objects marked 'inactive' ?!?  If so, then it's
> the Sybase-Backtrack problem cited --- what's the cure?"
>
> It doesn't make sense that ROOT query works and ORACLE
> does not --- unless there's more to the story.
>
> Don France
>
>
> Technical Architect, P.A.C.E.
> San Jose, CA
> mailto:dfrance AT pacbell DOT net
> PACE - http://www.pacepros.com
> Bus-Ph:   (408) 257-3037
>
>
>
>
> > -----Original Message-----
> > From: Shawn Raymond [mailto:sraymond AT SNRGY DOT COM]
> > Sent: Thursday, December 23, 1999 5:23 AM
> > To: ADSM-L AT VM.MARIST DOT EDU
> > Subject: Re: SQL-Backtrack filespace deletion.
> >
> >
> > Sean,
> >
> > I have seen this with SQL-Backtrack for sybase.  In our case ADSM was
> > expiring the entry in the ADSM database before SQL Backtrack,
> > so when SQL
> > backtrack tried to expire, it wasn't there.
> >
> > --
> > Shawn Raymond
> > Sr. Technical Consultant
> > Synergy, INC.
> > 518-782-3457
> >
> >
> >
> >
> >
> > Sean McNamara <mcnams AT PJM DOT COM>
> > Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
> > 12/22/99 03:33 PM
> > Please respond to "ADSM: Dist Stor Manager"
> >
> >
> >         To:     ADSM-L AT VM.MARIST DOT EDU
> >         cc:
> >         Subject:        SQL-Backtrack filespace deletion.
> >
> >
> > Hello All,
> >
> >         Over the past few days we have been seeing the following error
> > message
> > during our nightly Oracle database backup using SQL-Backtrack:
> >
> >
> > 02:31 backup of archived logs completed
> > 02:32 backup of archived logs completed
> > [dtoexpire 15866] Object to be deleted is not found:
> > /BACKTRACK:oracatalog
> > /OPER1 /archivelogs1-0.01-12-1999.02:20:47-34326!, error msg= ANS1302E
> > (RC2)
> > No objects on server match query
> > [dtoexpire 15866] Object to be deleted is not found:
> > /BACKTRACK:oracatalog
> > /OPER1 /archivelogs1-1.01-12-1999.02:20:47-34326!, error msg= ANS1302E
> > (RC2)
> > No objects on server match query
> > [dtoexpire 15866] Object to be deleted is not found:
> > /BACKTRACK:oracatalog
> > /OPER1 /archivelogs1-2.01-12-1999.02:20:47-34326!, error msg= ANS1302E
> > (RC2)
> > No objects on server match query
> > [dtoexpire 15866] Object to be deleted is not found:
> > /BACKTRACK:oracatalog
> > /OPER1 /archivelogs1-0.01-12-1999.02:24:01-32154!, error msg= ANS1302E
> > (RC2)
> > No objects on server match query
> > [dtoexpire 15866] Object to be deleted is not found:
> > /BACKTRACK:oracatalog
> > /OPER1 /archivelogs1-1.01-12-1999.02:24:01-32154!, error msg= ANS1302E
> > (RC2)
> > No objects on server match query
> >
> >         SQL-Backtrack is attempting to expire a backup that
> > it no longer
> > needs
> > and is asking ADSM to mark it as inactive.  ADSM is telling
> > SQL-Backtrack
> > that
> > it can not find the file  My take on it is that is an
> > ownership problem.
> > If I
> > attempt to query the backups above as 'ORACLE', I cannot find
> > any of them.
> >  If I
> > query any of the backups above as 'ROOT', I find them without any
> > problems. This
> > tells me that somewhere along the line the Backtrack backups
> > are losing
> > their
> > ownership and therefore can not be deleted during nightly
> > processing. Does
> > any
> > of this make sense or am I gravely mistaken? Has anyone ever
> > dealt with
> > this
> > situation?
> >
> > Environment - ADSM V3.1.2.40 running on AIX 4.2.1.
> > SQL-Backtrack V3.1.40
> >
> > Any help is greatly appreciated,
> >
> > Sean McNamara
> > PJM Interconnection L.L.C.
> > (610)666-4206
> >