Re: ORA-00376: what are my options?

So hardware never fails? (regardless of what RDBMS, or filebased system) Guess the data isn't very important. Clearly your boss is a moron.

One thing you might do is doa clean shutdown. Then copy the files elsewhere (all of them - cold backup). Start Oracle again. Then take the tablespace off line. then recover the tablespace. If you get media recovery complete try bringing the tablespace back on line.

I have seen this error when someone tries to do a backup and the backup software (usually on Windows- which you are on) puts a lock on the file. Then Oracle tries to read from or write to the file, sees the file lock (from the backup software) and labels the file needing recovery. In actual fact the file is fine, but since some other process (the backup) locked the file Oracle has to assume the file is bad. Jim

-- 
Replace part of the email address: kennedy-down_with_spammers_at_attbi.com
with family.  Remove the negative part, keep the minus sign.  You can figure
it out.
"mar" <mar_at_foo.com> wrote in message
news:ba7thj$piugo$1_at_ID-174077.news.dfncis.de...


>

> "Howard J. Rogers" <howardjr2000_at_yahoo.com.au> wrote

>

> > Mmmmm. A newbie that needs to learn the values of backups, perhaps?

>

> My boss is management-challenged. I keep telling him about

> the value of backups, but he lives on another planet.

>

> You know, he is one of those guys who think that RDBMSes

> are just a little bit better filesystems. His premise is "Oracle

> should run forever automatically, without supervision"! I'm

> serious.

>

> A story for Dilbert, I guess.

>

> But let's get back to the problem:

>

>

>

>

> > The problem you've got is that whilst you can merrily re-create indexes,

> > dropping them is a whole lot harder. For a start, you can't drop indexes

> > which are used to enforce Primary or Unique Key constraints. So you have

> to

> > identify those constraints first, drop or disable them, and then you can

> > drop the indexes.

>

>

> I have TOAD. So I just have to find all index-related constraints,

> drop them, and DROP TABLESPACE INDX INCLUDING

> CONTENTS? Sounds easy. I have only around 30 tables.

> Thanks,

>

>

>

>

>

> > Which is easier said than done.

> >

> > So who said anything about dropping indexes??? You did. If you want to

> drop

> > the file, you'll have to drop the tablespace. And you can't drop a

> > tablespace if it's got anything in it. So you'll have to use the 'drop

> > tablespace INDX including contents' command. Which won't work if any of

> the

> > indexes within the tablespace are involved in Primary or Unique Key

> > constraint enforcement.

> >

> > Which brings us back to identifying which indexes are used to enforce

> which

> > constaints. Which used to be easy when the constraint name was

definitely


> > equal to the index name... but that hasn't been true since 8.0. So it's

> > hard.

> >

> > All of which means that it might be a darn'd sight easier to invest in

> some

> > decent backup and recovery procedures than to assume that indexes are

> > disposable.

>

>

>

>

>

>

>

>

>