Re: question concerning redo logs and recovery

Your post shows *exactly* why you should mirror/duplex online redolog files. It looks like you didn't do that.

Further answers embedded.

Hth,

Sybrand Bakker, Oracle DBA

"Petra Hein/Gerald Bauer" <Petra.Hein-Gerald.Bauer_at_t-online.de> wrote in message news:9e4vs3$65i$01$1_at_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 ?
The only thing you can do is set log_block_checksum to true. Of course this has an adverse effect on performance.

Does it
> help reducing the size of redo log files ?

No definitely not, has nothing to do with it. It will however increase the chance of the checkpoint not complete problem. With redo log size being smaller,
> will a corrupted redo log be detected earlier ?

Again has nothing to do with it.
> Is the archiver-process able to detect a corrupted redo log file ?

I don't think so, archiving is just a plain copy.
> Does a log switch check the redo logs for consistency ?
>

Not sure about this

> Can anyone explain to me, when exactely the redo log buffer is written to
> the current redo log file ?

When 1/3 of log_buffer is dirty, or every 3 seconds, which ever occurs first.
> Is the redo log buffer written to the current redo log file as soon as a
> transaction is finished by issuing a commit ?
>

No, much more earlier. A commit does however force a checkpoint.

> Anyway, I'm now going to reduce size of redo logs

I would advise against that, it will have an adverse effect on performance.

and adjust parameters to
> have checkpoints triggered more frequently ..

Ditto

but maybe someone has other
> ideas which could prevent such scenario described in the first lines above

Buy better hardware. How come 3!! disks show corruption.
> ...
>
> 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 - 01:53:02 CDT