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

Home -> Community -> Mailing Lists -> Oracle-L -> RE: Rollback Segment needs recovery

RE: Rollback Segment needs recovery

From: A. Bardeen <abardeen1_at_yahoo.com>
Date: Tue, 31 Jul 2001 04:44:14 -0700
Message-ID: <F001.00359C0C.20010731032520@fatcity.com>

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:

  1. The db MUST be recreated afterwards (recreating the RBS and/or RBS tablespace is not sufficient).
  2. 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,


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

Original text of this message

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