 A special instance recovery [message #419661] |
Mon, 24 August 2009 22:47  |
hello03
Messages: 2
Registered: August 2009
|
Junior Member |
|
|
I have a question about incremental checkpoint.
I recently read a book called <<Orace Database 10g Ocp Certification All-in-One Exam Guide>> that published by oracle press.When talked about the database buffer cache,the book said:
"When a server process looks for a free buffer, starting at the least recently used end of the LRU list, whenever it finds a dirty buffer in the course of its search it will transfer its address to the checkpoint queue."
"This means that a very busy buffer, one that is being continuously updated, will never be written to disk, because it will always be at the most recently used end of the LRU list".
"But what if DBWR has written some blocks to disk before the crash? It might be that JOHN (or another user) was continually requerying his data, but that DAMIR had made his uncommitted change and not looked at the data again. DBWn will therefore decide to write DAMIR's changes to disk in preference to JOHN's; DBWn will always tend to write inactive blocks rather than active blocks. So now, the datafiles are storing DAMIR's uncommitted transaction but missing JOHN's committed transaction.
This is as bad a corruption as you can have. But think it through. If the instance crashes now a power cut, perhaps, or a shutdown abort the roll forward will still be able to sortout the mess."
JOHN updated a block before DAMIR made(I mean the block JOHN updated has a low RBA than DAMIR made.),how does the instance recovery work?What does the incremental checkpoint insure that no corruptions?
[Updated on: Mon, 24 August 2009 22:50] Report message to a moderator |
|
|
|
|
|
| Re: A special instance recovery [message #419680 is a reply to message #419662] |
Tue, 25 August 2009 02:30  |
hello03
Messages: 2
Registered: August 2009
|
Junior Member |
|
|
| BlackSwan wrote on Tue, 25 August 2009 12:00 | >I have a question about incremental checkpoint.
Orcle's Doc. set does not recognize "incremental checkpoint"
If you have questions about this phrase, perhaps you should email the author.
At a minimum, simply have faith that committed data will be available when requested in the future.
|
Thanks for your reply!Can you answer the following question?
"But what if DBWR has written some blocks to disk before the crash? It might be that JOHN (or another user) was continually requerying his data, but that DAMIR had made his uncommitted change and not looked at the data again. DBWn will therefore decide to write DAMIR's changes to disk in preference to JOHN's; DBWn will always tend to write inactive blocks rather than active blocks. So now, the datafiles are storing DAMIR's uncommitted transaction but missing JOHN's committed transaction.
This is as bad a corruption as you can have. But think it through. If the instance crashes now a power cut, perhaps, or a shutdown abort the roll forward will still be able to sortout the mess."
JOHN updated a block before DAMIR made(I mean the block JOHN updated has a low RBA than DAMIR made.),how does the instance recovery work?What does the incremental checkpoint insure that no corruptions?
|
|
|
|
| Re: A special instance recovery [message #419770 is a reply to message #419661] |
Tue, 25 August 2009 09:36 |
 |
BlackSwan
Messages: 26766
Registered: January 2009
Location: SoCal
|
Senior Member |
|
|
Anyone can make any statement about anything, but it does not make it true.
>This is as bad a corruption as you can have
post reproducible test case that Oracle behaves as you claim.
You need to help us by following the Posting Guidelines as stated below.
http://www.orafaq.com/forum/t/88153/0/
Go to the URL above click the link "Posting Guidelines"
Go to the section labeled "Practice" & do as directed.
|
|
|
|
] 
Blog
Search
Help
Members
Register
Login
Home
