Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> help: question concerning redo logs and recovery

help: question concerning redo logs and recovery

From: Petra Hein/Gerald Bauer <Petra.Hein-Gerald.Bauer_at_t-online.de>
Date: Sat, 19 May 2001 07:22:19 +0200
Message-ID: <9e4vs3$65i$01$1@news.t-online.com>

Hi,

I just experienced a crash of Oracle 8.0.5. Our AIX-Server was hanging and there was no way to shut down Oracle properly. The database is running in archive mode.
The consequences: all 3 members of the CURRENT redo log group were corrupted. The corrupted members of the group were distributed across 3 different disks. The size of redo logs are 50MB. Trying to clear the current log file group was not possible, so I started recovery ... There was a corrupted block inside EACH CURRENT redo log file, which could not be read by the recovery-process. The recovery-process reported that the corrupted block inside the current redo logs was from yesterday ...

So I recovered the database until yesterday, but I lost half a day of work

Now my questions:

Is there any chance to detect as early as possible if a redo log is corrupted and which parameters do I have to specify in init.ora ? Does it help reducing the size of redo log files ? With redo log size being smaller, will a corrupted redo log be detected earlier ? Is the archiver-process able to detect a corrupted redo log file ? Does a log switch check the redo logs for consistency ?

Can anyone explain to me, when exactely the redo log buffer is written to the current redo log file ?
Is the redo log buffer written to the current redo log file as soon as a transaction is finished by issuing a commit ?

Anyway, I'm now going to reduce size of redo logs and adjust parameters to have checkpoints triggered more frequently .. but maybe someone has other ideas which could prevent such scenario described in the first lines above ...

I currently can't see a possibility to prevent 100% a crash as described above (except standby database or replicated database nodes) ... hopefully you never will experience this case ...

Many questions, hopefully at least some answers ... thanks in advance,

Gerald Received on Sat May 19 2001 - 00:22:19 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US