Shulou(Shulou.com)06/01 Report--

These two parameters of _ OFFLINE_ROLLBACK_SEGMENTS and _ CORRUPTED_ROLLBACK_SEGMENTS can force the database to be opened, but after open, it is best to export, rebuild the library, and then import. I didn't know much about these two parameters until I saw the post of maclean. Here is the address of the post.

_ CORRUPTED_ROLLBACK_SEGMENTS hidden parameters

Http://www.askmaclean.com/archives/_corrupted_rollback_segments.html

_ OFFLINE_ROLLBACK_SEGMENTS hidden parameters

Http://www.askmaclean.com/archives/_offline_rollback_segments.html

I'll put a copy of the content below.

_ CORRUPTED_ROLLBACK_SEGMENTS (corrupted undo segment list) hides features unique to parameters:

When the instance starts startup and open database, the undo segments (undo segment / rollback segment) listed in _ CORRUPTED_ROLLBACK_SEGMENTS will not be accessed and read.

All transactions that point to these undo segments listed by _ CORRUPTED_ROLLBACK_SEGMENTS are considered to have committed the commit, similar to when the undo segments has been drop

This will lead to serious logical corruption.

If there are active transactions in the data dictionary, it will be even worse, and the logical corruption of the data dictionary will cause database management problems.

If the bootstrap bootstrap core object has an active transaction, the error ORA-00704: bootstrap process failure error cannot be ignored and the database cannot be forced to be opened (see my Oracle data recovery: an example of solving ORA-00600: [4000] ORA-00704: bootstrap process failure error)

It is sincerely recommended that you use the parameter _ CORRUPTED_ROLLBACK_SEGMENTS to open the database and export the data and rebuild the database. The sequelae of this parameter may be stubborn.

Oracle has a tool called TXChecker within the company to check problem transactions

_ OFFLINE_ROLLBACK_SEGMENTS (offline undo segment list) hides the unique function of the parameter (hidden parameter):

The Undo segments (undo segment / rollback segment) listed in _ OFFLINE_ROLLBACK_SEGMENTS will still be read when the instance startup starts and open database. If there is a problem in accessing these undo segments, it will be reflected in alert.log and other TRACE, but will not affect the actual startup process.

If the query data block finds an active transaction and ITL points to the corresponding undo segments, then:

If you read the transaction table transaction table of undo segments and find that the transaction has been committed, clean up the data block.

If the read discovers that the transaction is still not commit active, a copy of the CR block is generated.

If there is a problem reading the undo segments (possibly due to corrupted corruption or missing missed), an error is generated and written to alert.log, and the query will be terminated abnormally.

If updating related data blocks by DML will cause the service process to enter an endless loop and consume a lot of CPU in order to resume active transactions, the solution is to rebuild the relevant tables through the query work that can be carried out.

Changes in instance behavior caused by both _ offline_rollback_segments and _ corrupted_rollback_segments:

The Undo Segments (undo segment / rollback segment) listed in the above two parameters will not be used online with online

The record of OFFLINE will be reflected in the base table of UNDO$ data dictionary

New transactions will not be assigned to use during the life cycle of the instance instance

The active transaction active transaction on the Undo Segments list listed in the parameter will neither be rolled back nor marked as dead for SMON to roll back (learn about SMON features you don't know (5): Recover Dead transaction)

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.