Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: recovery issue...

Re: recovery issue...

From: hpuxrac <johnbhurley_at_sbcglobal.net>
Date: 2 Nov 2006 08:16:43 -0800
Message-ID: <1162484203.462474.301890@m73g2000cwd.googlegroups.com>

Volker Hetzer wrote:
> Volker Hetzer schrieb:
> > Hi!
> > (10.2.0.1, Linux RH ES 4)
> > We've got a tablespace with some logging and some nologging tables.
> > Now we've got some corruption and I took the tablespace offline for
> > recovery.
> > Turned out, the corruption was in the nologging part, recovery failed
> > and whenever I try to do put the tablespace online I get a message
> > that it needs recovery.
> > I'm perfectly happy with losing the nologging tables but how do I
> > achieve that?
> > I've got incremental backups until monday and archivelogs until today.
> > I've opened a SR but so far oracle hasn't responded.
> Ok, I got to talk to support.
> They say the backups are indeed corrupt and it has nothing to do with
> nologging operations.
> What I see from the rman messages is that the monday backup was just fine,
> the tuesday backup failed because of a corrupt block in the users tablespace
> and the archivelogs on tuesday are corrupt.
> Great.
>
> How can such a thing happen?

First you shouldn't mix nologging and logging things in the same tablespace. That's beginning to play with fire from my point of view.

You can try a couple of things but you should probably keep working with oracle support.

You should be able to use rman to fix the block corruption in the users tablespace ( except maybe if you can't read your archived logs? ... what do you mean they are corrupt ).

You can try recovering the "good backup" from monday to a separate database and get the data that you want from that tablespace.

Then you can ditch the bad tablespace in your current database and create a new one then move in the data that you recovered.

Block corruption is just something that I encounter in my environment. It's a huge danger sign of possible instability in your disk subsystem somewhere.

Good luck. Received on Thu Nov 02 2006 - 10:16:43 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US