Re: why does oracle recovery redo before undo?
- From: "Jonathan Lewis" <jonathan@xxxxxxxxxxxxxxxxxx>
- To: <oracle-l@xxxxxxxxxxxxx>
- Date: Tue, 20 Apr 2004 11:58:48 +0100
Notes in-line.
Regards
Jonathan Lewis
http://www.jlcomp.demon.co.uk
The Co-operative Oracle Users' FAQ
http://www.jlcomp.demon.co.uk/faq/ind_faq.html
April 2004 Iceland http://www.index.is/oracleday.php
June 2004 UK - Optimising Oracle Seminar
July 2004 USA West Coast, Optimising Oracle Seminar
August 2004 Charlotte NC, Optimising Oracle Seminar
September 2004 USA East Coast, Optimising Oracle Seminar
September2004 UK - Optimising Oracle Seminar
----- Original Message -----
From: "Ryan" <ryan.gaffuri@xxxxxxx>
To: <oracle-l@xxxxxxxxxxxxx>
Sent: Monday, April 19, 2004 10:28 PM
Subject: why does oracle recovery redo before undo?
I know how it works. I know that it works. I can't find 'why'? I'm taking a
university database class and my professor says the optimal way to recover
is with undo before redo and so does my book.
[jl] As someone else said, it's dependent on the basic infrastructure.
[jl] I'd guess that the professor is assuming there is an undo stream
[jl] and a redo stream that are both external to the data files. But
[jl] in Oracle, of course, the "undo stream" would be incomplete
[jl] until the "redo stream" had been applied to rebuild it.
Anyone know why Oracle does it the other way?
Here is how I think Oracle performs recovery.
1. Oracle scans the redo log from the end back to the last checkpoint.
[jl] No need - Oracle will have a record in each data file of the
[jl] change with highest SCN that was __guaranteed__ to be in
[jl] the data file (there may be newer ones, but not guaranteed).
[jl] so Oracle goes to the most recent redo log file that could
[jl] hold the lowest 'highest guaranteed SCN' and works forward.
2. Oracle takes notes of all open transactions at the time of the
checkpoint. Why it was scanning backwards it noted all 'commits'
[jl] No need - historically it just tried to replay everything in the redo
log.
[jl] In v9, it runs the redo log twice - once to find out the highest SCN
[jl] for each changed data block (identified by "block written records"
(BWR))
[jl] and once to apply only those changes that are needed to roll blocks
[jl] forward from their know highest SCN.
3. If there are any open transactions at the time of the last checkpoint
oracle continues to scan back until it reaches the earliest one.
[jl] N/A
4. Oracle rolls forward and applies all redo from that point to the end of
the log.
5. Oracle Rollsback all open transactions.
Now my book says the optimal way to do this is to check for all open
transactions at the time of the last checkpoint that have committed after
that checkpoint.
[jl] I think there would be a hole here from Oracle's perspective
[jl] because some of the UNDO for an uncommitted transaction
[jl] could be on disc already, whilst other, earlier, bits of UNDO
[jl] for the same uncommitted transaction might never have made
[jl] it to disc.
Anyone know more? In particularly know 'why'?
----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
Other related posts:
