Re: Database can't open / corruption at system01 datafile

I’ll try not making assumptions but since there is no support and no backups I would assume this is not very important data. If it is important I would strongly advice seeking some experienced assistance in moving forward and additionally acquiring support and logging an SR. Support has tools that are not publicly available that in dire circumstances can be utilized to recover data that is otherwise lost.

Minimally I would stop everything you are doing, shut down the instance and back up every part of this database to ensure you have a way to get back to this point as things go bad moving forward.

After that, you might want to see if there is an alternative backup of log file sequence 4149. Possibly it is not the current log file and was archived already, possibly you have a multiplexed redo log file in an alternate location that is not corrupt.

Keep in mind the hidden parameter you speak of is not a solution but a possible last ditch effort of recovering some of your data. After opening a database with such a parameter you can attempt doing exports of your data although you are likely to encounter errors along the way and some, or all, of your data might be inaccessible. After exporting the data you would recreate a new database, ideally with a sound and tested backup strategy, and import your data.

This is probably the escape hatch you are asking for.

alter system set "_allow_resetlogs_corruption"=true scope=spfile;

After that you can shutdown, mount and re-attempt your open reset logs.

Good luck.

Kenny

On Oct 22, 2014, at 7:30 AM, Mostafa Eletriby <m_etrib_at_yahoo.com> wrote:

> Archivelog is enabled,
> 
> SQL> select log_mode from v$database;
> 
> LOG_MODE
> ------------------------------------
> ARCHIVELOG
> 
> Block corruption is shown as below:
> ------------------------------------------------
> 
> RMAN> recover database;
> 
> Starting recover at 22-OCT-14
> using channel ORA_DISK_1
> 
> starting media recovery
> 
> archived log for thread 1 with sequence 4149 is already on disk as file /oraData/cdsdb/redo03.log
> archived log file name=/oraData/<SID>/redo03.log thread=1 sequence=4149
> RMAN-00571: ===========================================================
> RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
> RMAN-00571: ===========================================================
> RMAN-03002: failure of recover command at 10/22/2014 13:24:45
> ORA-00283: recovery session canceled due to errors
> RMAN-11003: failure during parse/execution of SQL statement: alter database recover logfile '/oraData/<SID>/redo03.log'
> ORA-00283: recovery session canceled due to errors
> ORA-00354: corrupt redo log block header
> ORA-00353: log corruption near block 9214 change 50976239 time 10/20/2014 17:41:50
> ORA-00334: archived log: '/oraData/<SID>/redo03.log'
> 
> RMAN>
> 
> 
> Also please I need to know how to set hidden parameter   _allow_resetlogs_corruption=TRUE   at spfile or pfile in order to startup database after this change.
> 
> Thanks
> 
> 
> 
> On Wednesday, October 22, 2014 1:22 PM, Kenny Payton <k3nnyp_at_gmail.com> wrote:
> 
> 
> And controlfile.  If those check out I’d start with verifying the file ( database and redo logs ) locations and make sure the actual file locations match that in the control file.  Next step would be to issue a “recover database” command.  If the needed redo is in the redo logs to get the datafiles consistent then it’ll roll forward.  Something tells me archiving is not enabled.
> 
> Situations like this tend to have a long back story but at it’s simplest this might get you consistent so that you can open the database.
> 
> You mention corruption in your post but I don’t see anything suggestion corruption, only inconsistency in datafiles.  There is a big difference between the two and handling them are quite different.
> 
> Kenny
> 
> 
> On Oct 22, 2014, at 7:12 AM, hostetter.jay_at_gmail.com wrote:
> 

> 
> 
> 

--
http://www.freelists.org/webpage/oracle-l