Folks,
All of the underscore parameters used to force the db
open or ignore inconsistency in the redo logs or the
RBS's, such as the one below, have two major
drawbacks:
- The db MUST be recreated afterwards (recreating
the RBS and/or RBS tablespace is not sufficient).
- Most likely there will be logical corruption as
all transactions on disk will be treated as committed.
This is why they should be used only as a very last
resort.
The reason for this is that changes to the data
dictionary are by default stored in the RBS for the
transaction, not the SYSTEM RBS. So when you allow
Oracle to skip its normal integrity checks by not
rolling back uncommitted transactions you are
potentially corrupting your data dictionary at the
same time.
The sole purpose of using these parameters is to allow
you to do a full db export so that the db can then be
recreated.
You may not see errors right away, but if the data
dictionary has been corrupted you're sitting on a time
bomb and it's only a matter of time before it
explodes. Furthermore Oracle Support won't support
you if you continue using the db after using these
paramters. How lucky do you feel and do you really
want to play russian roulette with your production db?
What about dropping the objects?
This can be done INSTEAD of using the underscore
parameters in some cases when the RBS is physically
corrupted (i.e. an ORA-1578). In many cases the
easiest way to detect the objects locked by the
transaction in the corrupted RBS, if the db activity
can be restricted, is to do a full db export to
/dev/null as an ORA-1578 will be signaled when the RBS
is accessed.
If the RBS corruption is due to an ORA-600 error this
is most likely a form of logical corruption. In which
case dropping the object locked by the transaction is
usually not a valid option. In most cases the ORA-600
error indicates that the version of the block in the
RBS may not be the correct block (e.g. a missed
write). If that's the case then there's no guarantee
that the objects locked by the undo block are really
the ones locked.
Also if the db has crashed or been bounced and SMON is
encountering RBS corruption when attempting to roll
back an uncommitted transaction, dropping the object
will usually not work as SMON will continue to try to
rollback the transaction.
The safest method for resolving corruption is usually
restoring the affected datafile from backup and
recovering it. Of course this requires a good backup
and the required archived logs ;)
HTH,
- Anita
- Kevin Lange <kgel_at_ppoone.com> wrote:
> Danisment;
> When we had a problem that we needed the
> _corrupted_rollback_segments
> option added to the init.ora file. The Rollback
> Segment itself was
> corrupted. Not the objects using the Rollback
> Segment. If this is the
> case, dropping the objects will not do the trick
> because it will happen
> again when the Rollback Segment is accessed for
> another activity.
>
> -----Original Message-----
> Sent: Friday, July 27, 2001 2:17 PM
> To: Multiple recipients of list ORACLE-L
>
>
> Hello,
>
> It's bad problem. I think _offline_rollback_segments
> or
> _corrupted_rollback_segments should be last method.
>
> I'll recommend a tip for this error: If you can
> identify which objects need
> recovery and then drop them, Oracle doesn't try to
> recover them, so "needs
> recovery" goes away.
>
> Let's identify which object need recovery in
> corrupted rbs:
>
> - add following parameters to init.ora:
>
> event="10013 trace name context forever, level 10"
> event="10015 trace name context forever, level 10"
>
> Note that if there are more than 1 event in
> init.ora, they have to be
> consecutive. otherwise just last one will be active.
>
> Now, re-start db abd try to get same error. Oracle
> will dump recovery
> operation
> in alert.log. And you will be able to see object id.
> drop this object.
> That's
> all.
>
> You can paste recovery dumps in alert.log to
> identify your object, as well.
>
> regards...
>
>
>
>
> 27/7/01 08:37:06, "Cale, Rick T (Richard)"
> <RICHARD.T.CALE_at_saic.com> wrote:
>
> >Hi DBAs,
> >
> >Oracle 8.0.5/Windows NT4
> >
> >I shutdown database normal and restarted ok.
> >I tried to drop a rollback segment and getora-1545
> rollback segment not
> >available.
> >When I select from dba_rollback_segs I get "needs
> recovery".
> >
> >I want to drop rollback tablespace and all rollback
> segment then rebuild
> >because I got datafile corruption error.
> >I am in noarchive mode.
> >
> >Any ideas how to proceed?
> >
> >Thanks
> >Rick
> >
> >
> >--
> >Please see the official ORACLE-L FAQ:
> http://www.orafaq.com
> >--
> >Author: Cale, Rick T (Richard)
> > INET: RICHARD.T.CALE_at_saic.com
> >
> >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: ListGuru_at_fatcity.com (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: Danisment Gazi Unal (Unal Bilisim)
> INET: danisment.unal_at_unal-bilisim.com
>
> 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: ListGuru_at_fatcity.com (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: Kevin Lange
> INET: kgel_at_ppoone.com
>
> 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: ListGuru_at_fatcity.com (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).
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: A. Bardeen
INET: abardeen1_at_yahoo.com
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: ListGuru_at_fatcity.com (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).
Received on Tue Jul 31 2001 - 06:44:14 CDT