Home > Disaster recovery, oracle > Undocumented parameter: _allow_resetlogs_corruption

Undocumented parameter: _allow_resetlogs_corruption


Note: This is an undocumented paramete and shouldn’t be used if you don’t know what you are doing. You can put your database in an unstable state if you don’t know what you’re doing, so be careful. You have been warned…

_allow_resetlogs_corruption is a hidden parameter, and undocumented for mortals like us, that is only supposed to be used by Oracle Staff in case of emergency. If you need to use it by yourself, you should have a cold backup ready to restore, and NEVER use it on a working database that you don’t wanna lose, because it’s very probable that you will have corruption problems afterwards.

To use this parameter, you have to set it into your spfile or pfile the following way:

_allow_resetlogs_corruption=TRUE

By default, it is set to false, of course.

When to use this parameter?

You may be in need to use the undocumented parameter _allow_resetlogs_corruption if you have a database that has crashed and cannot be recovered because one of your redologs is corrupted. Yes, you could make an incomplete recover, but… what if you MUST have the data that is inside your corrupted redo logs? What if you can’t afford to lose that data, or at least, you must try to recover it when humanly possible?

Well, in that case then you can try to use this parameter, because you have nothing to lose. However, make sure that you have a cold backup of your broken database, or you could miss any chance of recovering your data.

And just in case you are wondering, yes, you have other ways to recover the data from a “broken” database, but we will talk about this kind of disaster recovering tools in the future.

To activate the resetlog corruption and try to recover all the data that you can, you must:

1. STARTUP MOUNT;
2. ALTER SYSTEM SET _allow_resetlogs_corruption=TRUE;
3. Cross your fingers.
4. ALTER DATABASE OPEN;

If your database opens, DON’T PUT IN IN PRODUCTION. Extract all the data that you need and recover it by any means, for example, using exp or data pump. You could have problem extracting the data, but if you have managed to open the database, you should be able to make an export.

However, it’s best if you don’t ever need to use this kind of parameters. But, in case you have problems with your database, I hope this post will help someone to recover it in case of disaster.

Be careful and don’t play with your production environment!

Advertisements
  1. February 20, 2015 at 9:24 pm

    oow! thank you so much! it is very useful sharing!

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: