RE: Corruption in SYSTEM Tablespace

2001-10-29 Thread Koivu, Lisa
Title: RE: Corruption in SYSTEM Tablespace





Hi Jeremiah, 


Wish it was always that easy.  Last corruption I experienced, we could not chase down the reason for the corruption.  Oracle wanted so many trace files, dumps, etc. lots of info before they would even look at it.  End result, I fixed the problem but I had so much to do (read: tons of code to write) we had to just hope it wouldn't happen again.  We got lucky and for the duration of my employment, it didn't happen a second time.

Have you been able to determine the exact reason for corruption before?


Lisa Koivu
Oracle Database Monkey
Fairfield Resorts, Inc.
954-935-4117




-Original Message-
From:   Jeremiah Wilton [SMTP:[EMAIL PROTECTED]]
Sent:   Monday, October 29, 2001 1:15 PM
To: Multiple recipients of list ORACLE-L
Subject:    RE: Corruption in SYSTEM Tablespace


On Mon, 29 Oct 2001, Gogala, Mladen wrote:


> Restore the last hot backup and do the database recovery.


Well that seems a little extreme.


Why not find out which objects contain corruptions first, and if the
corrupted areas actually contain data?  Why go through a
restore/recover without having all the information?


Use dba_extents to find out which objects the corrupted blocks belong
to.  If they are indexes, just rebuild them!  If they are
heap-organized segments (tables/clusters), then find out if there are
actually rows in the affected area, by selecting a range of rowids
using dbms_rowid.


Only if you find that the corruptions have damaged actual data do you
have to recover.  Even in that case, as long as you are using
archivelog mode, you can resotre and recover just the datafile(s)
containing the corruptions, and perform complete recovery of that
file(s) with the database in mount mode.


Finally, make sure you find out how the corruption happened.  The O/S
shouldn't just corrupt your database.  The SAs should identify the
root cause and rectify it.


--
Jeremiah Wilton
http://www.speakeasy.net/~jwilton


> > -Original Message-
> > From: Rajesh Dayal [mailto:[EMAIL PROTECTED]]
> >
> > Fortunately this is there only in my TEST database. But I am
> > wondering, how to resolve if this happens in Production Database.
> >     I can't export Full database with zero errors. Although I can
> > export most of the schemas individually. Dbverify shows some 3 blocks
> > to be corrupted, that's too only in SYSTEM TS.
> > Any ideas would be appreciated.


-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: Jeremiah Wilton
  INET: [EMAIL PROTECTED]


Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California    -- Public Internet access / Mailing Lists

To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).





RE: Corruption in SYSTEM Tablespace

2001-10-29 Thread Jeremiah Wilton

On Mon, 29 Oct 2001, Gogala, Mladen wrote:

> Restore the last hot backup and do the database recovery.

Well that seems a little extreme.

Why not find out which objects contain corruptions first, and if the
corrupted areas actually contain data?  Why go through a
restore/recover without having all the information?

Use dba_extents to find out which objects the corrupted blocks belong
to.  If they are indexes, just rebuild them!  If they are
heap-organized segments (tables/clusters), then find out if there are
actually rows in the affected area, by selecting a range of rowids
using dbms_rowid.

Only if you find that the corruptions have damaged actual data do you
have to recover.  Even in that case, as long as you are using
archivelog mode, you can resotre and recover just the datafile(s)
containing the corruptions, and perform complete recovery of that
file(s) with the database in mount mode.

Finally, make sure you find out how the corruption happened.  The O/S
shouldn't just corrupt your database.  The SAs should identify the
root cause and rectify it.

--
Jeremiah Wilton
http://www.speakeasy.net/~jwilton

> > -Original Message-
> > From: Rajesh Dayal [mailto:[EMAIL PROTECTED]]
> >
> > Fortunately this is there only in my TEST database. But I am
> > wondering, how to resolve if this happens in Production Database.
> > I can't export Full database with zero errors. Although I can
> > export most of the schemas individually. Dbverify shows some 3 blocks
> > to be corrupted, that's too only in SYSTEM TS.
> > Any ideas would be appreciated.

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: Jeremiah Wilton
  INET: [EMAIL PROTECTED]

Fat City Network Services-- (858) 538-5051  FAX: (858) 538-5051
San Diego, California-- Public Internet access / Mailing Lists

To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).



RE: Corruption in SYSTEM Tablespace

2001-10-29 Thread Gogala, Mladen

Restore the last hot backup and do the database recovery.

> -Original Message-
> From: Rajesh Dayal [mailto:[EMAIL PROTECTED]]
> Sent: Monday, October 29, 2001 12:55 AM
> To: Multiple recipients of list ORACLE-L
> Subject: Corruption in SYSTEM Tablespace
> 
> 
> Hi All,
> Fortunately this is there only in my TEST database. But I am 
> wondering, how to resolve if this happens in Production Database. 
>   I can't export Full database with zero errors. Although I can 
> export most of the schemas individually. Dbverify shows some 3 blocks
> to be corrupted, that's too only in SYSTEM TS.
> Any ideas would be appreciated.
> 
> TIA,
> Rajesh
> -- 
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> -- 
> Author: Rajesh Dayal
>   INET: [EMAIL PROTECTED]
> 
> Fat City Network Services-- (858) 538-5051  FAX: (858) 538-5051
> San Diego, California-- Public Internet access / Mailing Lists
> 
> To REMOVE yourself from this mailing list, send an E-Mail message
> to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
> the message BODY, include a line containing: UNSUB ORACLE-L
> (or the name of mailing list you want to be removed from).  You may
> also send the HELP command for other information (like subscribing).
> 
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: Gogala, Mladen
  INET: [EMAIL PROTECTED]

Fat City Network Services-- (858) 538-5051  FAX: (858) 538-5051
San Diego, California-- Public Internet access / Mailing Lists

To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).



Corruption in SYSTEM Tablespace

2001-10-28 Thread Rajesh Dayal

Hi All,
Fortunately this is there only in my TEST database. But I am 
wondering, how to resolve if this happens in Production Database. 
I can't export Full database with zero errors. Although I can 
export most of the schemas individually. Dbverify shows some 3 blocks
to be corrupted, that's too only in SYSTEM TS.
Any ideas would be appreciated.

TIA,
Rajesh
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: Rajesh Dayal
  INET: [EMAIL PROTECTED]

Fat City Network Services-- (858) 538-5051  FAX: (858) 538-5051
San Diego, California-- Public Internet access / Mailing Lists

To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).