Re: Database can't open / corruption at system01 datafile
- From: Kenny Payton <k3nnyp@xxxxxxxxx>
- To: Mostafa Eletriby <m_etrib@xxxxxxxxx>
- Date: Wed, 22 Oct 2014 07:47:25 -0400
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@xxxxxxxxx> 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@xxxxxxxxx> 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@xxxxxxxxx wrote:
>
>> Make sure you aren't using an old init.ora or spfile.
>>
>> Jay
>> Sent via BlackBerry by AT&T
>> From: "Mostafa Eletriby" <dmarc-noreply@xxxxxxxxxxxxx> (Redacted sender
>> "m_etrib@xxxxxxxxx" for DMARC)
>> Sender: oracle-l-bounce@xxxxxxxxxxxxx
>> Date: Wed, 22 Oct 2014 04:00:24 -0700
>> To: niall.litchfield@xxxxxxxxx<niall.litchfield@xxxxxxxxx>
>> ReplyTo: dmarc-noreply@xxxxxxxxxxxxx
>> Cc: oracle-l<oracle-l@xxxxxxxxxxxxx>
>> Subject: Re: Database can't open / corruption at system01 datafile
>>
>> Database version: Oracle Database 11g Release 11.2.0.1.0 - 64bit Production
>> Platform: Linux 5 2.6.18-164.el5 x86_64
>>
>>
>> On Wednesday, October 22, 2014 12:53 PM, Mostafa Eletriby
>> <dmarc-noreply@xxxxxxxxxxxxx> wrote:
>>
>>
>> There is no metalink support.
>> ----------------------------------------------
>> SQL> alter database open;
>> alter database open
>> *
>> ERROR at line 1:
>> ORA-01589: must use RESETLOGS or NORESETLOGS option for database open
>>
>>
>> SQL> alter database open resetlogs;
>> alter database open resetlogs
>> *
>> ERROR at line 1:
>> ORA-01196: file 1 is inconsistent due to a failed media recovery session
>> ORA-01110: data file 1: '/oraData/<SID>/system01.dbf'
>>
>>
>> On Wednesday, October 22, 2014 12:45 PM, Niall Litchfield
>> <niall.litchfield@xxxxxxxxx> wrote:
>>
>>
>> That's what you pay support fees for. Definitely log a P1 SR with Oracle if
>> you haven't already.
>>
>> To offer any help we'd need version, platform and exact error messages. Even
>> then you might not want to take recovery advice from strangers on the
>> internet.
>>
>> On Wed, Oct 22, 2014 at 11:36 AM, Mostafa Eletriby
>> <dmarc-noreply@xxxxxxxxxxxxx> wrote:
>> Dear All,
>> Please I have a problem at database startup as it can only be mounted while
>> there isn't any backup taken before , corruption at system01 datafile.
>> Please advice
>>
>>
>> Best Regards,
>> Mostafa Eletriby
>> Oracle DBA
>>
>>
>>
>> --
>> Niall Litchfield
>> Oracle DBA
>> http://www.orawin.info
>>
>>
>>
>>
>
>
>
Other related posts:
