Re: are redo records always flushed in order?

Not sure I can completely answer your question but here's a start.

1) Are records written sequentially?  Although I have no concrete proof at
the moment I'm pretty sure the answer is yes.  I don't think that Oracle
will ever do a "seek" backwards in a redo log; that seems pretty problematic
for many reasons.

2) The most important thing to remember is that when a transaction issues a
COMMIT statement, the COMMIT does not return to the client (and is not
successful) until the redo data is written to disk.

First, if all eight I/O operations were being written together then TX1 does
not succesfully COMMIT until the 8th I/O is complete.  However I don't think
that it works this way; a COMMIT will always cause an immediate log buffer
flush so when TX1 COMMITs it will probably cause an I/O for the first 5
blocks and when TX2 COMMITs it will cause an I/O for the last 3.

Second, all of the transactions will ALWAYS be replayed from the redolog
regardless of whether the transaction committed.  After instance startup and
after redo replay, uncommitted transactions will be rolled back in the
background by SMON (or sooner if a session tries to access a block before
SMON gets to it).  So replaying the redo log is not conditional on whether
or not a transaction was "COMMITTED".

For more detailed info check out Julian Dyke's excellent presentation
Transaction Internals here:
http://julian.dyke.users.btopenworld.com/com/Presentations/Presentations.html#TransactionInternals

-Jeremy


On 4/25/07, Jessica Mao <jessica.mao@xxxxxxxxxx> wrote:


i'm afraid my questions were not well presented. more descriptions:

quite often single redo write needs to flush multiple redo records
and/or commit records to redo log. let's say this time LGWR finds in log
buffer 10 redo records and 1 commit record for TX1, followed by 3 redo
records and 1 commit record for TX2, and is going to flush them all in
single redo write.

1.) are the records always flushed in the same order as they were
generated in log buffer? in this case, are TX1's records always flushed
no later than TX2's? doesn't matter how TX1 / TX2 committed (immediate,
wait, batch, nowait)

2.) assume answer to 1.) is yes. say it takes 8 physical I/O at OS level
to serve this redo write, first 5 for TX1's records, then 3 for TX2's.
what happens if instance crashes at I/O #7? all TX1's records are
already written to the redo log. TX2's are not. during recovery, would
db discard TX1's records in redo log and rollback TX1 instead replay? if
rollback, how does db know that TX1 belonged to a failed redo write?
through on-disk RBA? if replay, then redo write is not atomic.

thanks!  -Jessica

Jessica Mao wrote, On 4/25/2007 12:37 PM:
> Dear Gurus,
>
> Could you please help me with my questions below?
>
> if TX1 starts and commits (no matter what mode: immediate, wait,
> batch, nowait). after that TX2 starts and commits (whatever mode). are
> TX1's redo records (including the commit record) always flushed no
> later than TX2's? is there ANY chance that TX2's records (including
> the commit record) would be flushed first? i can't think of any but i
> could be missing something.
>
> a related question: (maybe i'm worrying too much) is redo write always
> atomic? when single redo write size is bigger than max OS I/O write
> size, 1 redo write may take several physical writes to finish. if
> there's instance crash in the middle of the several physical writes,
> is the db able to discard the already written to disk commit records
> and roll back ALL transactions associated with this redo write? if
> yes, how does the db achieve that? using on-disk RBA?
>
> would the zero-copy redo and private redo strands features introduce
> new issue on this matter?
>
> the DB is 10gR2 (since i mentioned the different commit methods), OS
> are mainly hp-ux 11, solaris 10, windows xp.
>
> thanks a lot!
>
> Jessica Mao
>
--
http://www.freelists.org/webpage/oracle-l






--
Jeremy Schneider
Chicago, IL
http://www.ardentperf.com/category/technical

Other related posts: