Re: Corrept Undo Tablespace and oracle internal problem

peter wrote:

> I know when my undo tablespace is corrupted then we can change undo
> tablespace to new undo tablespace but what are the problems we can
> face. Like what will happen with pending transactions.

See the concepts manual:

"To manage the multiversion consistency model, Oracle must create a read-consistent set of data when a table is queried (read) and simultaneously updated (written). When an update occurs, the original data values changed by the update are recorded in the database undo records. As long as this update remains part of an uncommitted transaction, any user that later queries the modified data views the original data values. Oracle uses current information in the system global area and information in the undo records to construct a read-consistent view of a table's data for a query.

Only when a transaction is committed are the changes of the transaction made permanent. Statements that start after the user's transaction is committed only see the changes made by the committed transaction."

So, what do you think will happen when Oracle cannot "construct a read-consistent view of a table's data for a query?"

Perhaps this:

01578, 00000, "ORACLE data block corrupted (file # %s, block # %s)" // *Cause: The data block indicated was corrupted, mostly due to software
// errors.

// *Action: Try to restore the segment containing the block indicated. This
// may involve dropping the segment and recreating it. If
there
// is a trace file, report the errors in it to your ORACLE
// representative.

Or maybe an ORA-600. Or maybe it will just go offline and ORA-1555 everything. I don't really know. I have a vague memory of rbs specific corruption messages but that might just be my imagination.

> And could anyone please tell me which book or site can help me to > explore database internally.

Concepts manual first. Then check out
http://www.dbaoracle.net/readme-cdos.htm#subj9

jg

--
@home.com is bogus.
10300, 00000, "disable undo compatibility check at database open"
// *Cause:
// *Action: If this event is enabled it will be possible to upgrade to
a new


//          software version with an incompatible log format when there

may be


//          undo that needs to be applied. This is intended for

upgrades


//          from releases before 6.0.34.3 when there are tablespaces

that are


//          offline cleanly with no save undo. Those releases did not

check the


//          deferred rollback segments, it was assumed that there was

some


//          undo in the segments and every offline tablespace had one.

This


//          event must only be set if you are ABSOLUTELY SURE the last

//          shutdown was a shutdown normal with no errors (do it again

to be


//          sure), and that there is no save undo for any of the

offline


//          tablespaces (dump the save undo segment header).