| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> Re: why does oracle recovery redo before undo?
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
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.
[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'?
-- Archives are at http://www.freelists.org/archives/oracle-l/ FAQ is at http://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_at_freelists.org put 'unsubscribe' in the subject line. -- Archives are at http://www.freelists.org/archives/oracle-l/ FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html -----------------------------------------------------------------Received on Tue Apr 20 2004 - 05:55:14 CDT
 |
 |