Re: A Theoretical Situation

Alan Gano wrote:

> Hi,
>
> Assuming an instance of this configuration:
> - 5 redo logs of 10K each.
>
> Assume this situation:
> - A single transaction (say an UPDATE) produces more than 50K of redo
> information, filling the redo logs, and then wraps around.
> - There is plenty of rollback space for the transaction.
> - The transaction is not committed.
>
> In this situation, some redo information concerning the transaction is
>
> being overwritten or written off to offline archive logs. I would
> assume
> that at least some of the modified blocks for this
> offlined/overwritten
> information has been getting written out to the datafiles by DBWR.
>
> Now, my question is, if the instance crashes (or shutdown aborts), how
> is
> Oracle going to roll back all the blocks changes in the transaction if
> they
> are no longer in the redo logs?
>
> As I understand Oracle's mechanism for recovery, it cannot roll back
> the
> transaction. Is this correct? If so, what does the server do in this
>
> case? I imagine that if it's in archive mode, it could demand media
> recovery, but what a surprise that would be! And what about
> non-archive
> mode?
>
> Thanks!
>
> Alan.

 You are not right: Oracle will make a recover and will be able to perform rollback. That's because any log switch initiates a checkpoint and when Oracle is going to overwrite any redo log file it ensures that the "previous" checkpoint initiated by the log switch of that redo log is finished (i.e. all the changes it is to overwrite are fully applied to datafiles and rollback segments).
 That's why using small redo logs is not a very good idea though it will work in some way: you have a risk to have "overlapping" checkpoints and therefore checkpoints may become actually synchronous, while normally they are asynchronous.

--
Vitaly Sikolenko                  Senior Sales Consultant
                                  Server & Gateways
ORACLE C.I.S.
Moscow Russia                      E-mail: vsikolen_at_ru.oracle.com

The statements and opinions expressed here are my own and do not
necessarily represent those of Oracle Corporation.