Re: ORACLE data block corrupted

Dino-

Well, I see a mess of replies, all of which overlook a critical concern with your situation. Once again, I feel compelled to jump in.

You must understand the danger of what you have done. I see all sorts of "experts" assuring you that setting those "_" underscore parameters fixes everything nicely. What you have done is to possibly leave your database in a logically corrupt state. The Oracle docs say that this makes your database "unsupported", which makes us imagine that Oracle will hang up the phone on you. While that is not the case, you may have a problem that simply cannot be solved without manual reconstruction of the database.

If the database crashed and you thus wired around a rollback segment corruption, you may have blocks that cannot be recovered. Oracle marked the transaction as dead when it started up, but cannot find the undo to roll back the block to bring it to a pre-crash consistency.

What is supposed to happen after a crash is that Oracle starts up the instance, rolls "forward" from the online redo log changes after the last checkpoint. Then, when the end of redo is found, it marks all "in flight" transactions as "dead" and opens the database. After than, the SMON process starts rolling back the dead transactions in the background to undo any incomplete work. This way, you are guaranteed that the database will be in a consistent state with respect to such matters as referential integrity, having lost only uncommitted transactions at the time of the crash.

So, maybe you changed an invoice detail table and did not get the master table row inserted. The instance crashed before you issued a commit. Now, when you bring up the instance the transaction table cannot be rolled back. You have children with no parent. Logically corrupt.

There could be any of a number of other scenarios that are not sustainable from a business point of view. You now have to examine every table and index in your database and ensure that all is well. Oracle cannot do that for you: it is now a business problem created by bad technical advice. The real solution was to do a media recovery from a previous backup after fixing whatever was the underlying cause. Most often a disk controller failure.

Did any of the so-called experts here warn you about this? One such fool even suggested that you are lucky this was a rollback segment problem. Luck indeed!

• ricky

Dino Hsu wrote:

>
> However, the database can be started up if I add 3 lines and mark out
> the rollback segment in the parameter file:
> #rollback_segments = ( rb1, rb2, rb3, rb4, rb5 )
> _allow_resetlogs_corruption=true
> _corrupted_rollback_segments=( rb1, rb2, rb3, rb4, rb5 )
> _offline_rollback_segments=( rb1, rb2, rb3, rb4, rb5 )
>
> Can anyone explain this to me? Thanks in advance.
>
  Received on Fri Apr 06 2001 - 15:42:42 CDT