Re: compile dba_data_files

Ah, thanks, I see where you were going with it.

I don't however think there is a duplicate row in obj$.

There are 2 unique indexes on obj$ in 9i, so there can't be duplicate rows.

The compile of the view is attempting to violate one of the unique indexes by creating a row that would be a duplicate.

That is why I suggested the level 4 trace to show the bind variables when the update of obj$ is done.

Use those bind variable values to query sys.obj$ to find the already existing row.

-- 
Jared Still
Certifiable Oracle DBA and Part Time Perl Evangelist


On 7/7/05, shirish_at_microexcel.com <shirish_at_microexcel.com> wrote:


> 

> the best guess is that the obj$ has duplicate row for this view

> dba_data_files

>  stats has practically nothing to do with this case .....it was just to 

> say that oracle even supports analyze .....on sys objects (for stats)

>  thus he should do

>  sql>analyze table obj$ validate structure cascade

>  and

>  run this to find the duplicate row

>   select count(*) ,obj# from obj$ group by obj# having count(*) > 1 ;

>  or

>  select count(*) ,owner#, name, namespace,

> remoteowner, linkname, subname from obj$ group by owner#, name, 

> namespace,remoteowner, linkname, subname having count(*) > 1 ;

>  if he opens tar, this will be a perfect case as support guy will do an 

> OWC and can just run a update on obj$ and do shutdown abort BUT this is 

> something which oracle will never support if ct does on its own.......I 

> agree it does require tar :-)

>  --Shirish

>


--
http://www.freelists.org/webpage/oracle-l