Google Patent Search to the rescue
During the yesterday session at seminar, someone from the class “surprised” Mr. Craig Shallahamer with a question about a detail from the slide (on page 128, picture 2); “…how does Oracle recover “In-Memory Undo” blocks in case system crashes at T3″.
It’s one of those stressful moments for the intructor, when a good instructor if it’s not sure about the correct answer will admit that he/she doesn’t know it (or can’t recollect the info) and that he/she will investigate the subject further, rather than speculate on the subject. Of course, Mr. Shallahamer is a superb instructor with enough mileage that he gracefully admitted that he doesn’t know the answer (imho, I would say that he was at the moment of thinking about the answer focusing too much on the slide – after all, it was late afternoon and we all had our heads full of information). (Btw. if you’re not familiar with Oracle IMU, Mr. Shallahamer released a white paper recently on the subject – recommended!)
Thinking about unanswered question on my way back home, I came to the conclusion that Oracle most likely protects the in memory undo (IMU) with the same mechanism as undo stored in segments, with the redo logging. So, I believe the redo log keeps all the information needed to “redo” Undo-Information in memory, that can then serve for undoing changes after the crash. Simple answer for a “tricky” question. [Note added: My assumption was wrong and if you read an answer from Mr. Shallahamer that I posted in my comment, you’ll see why]. Well, but is my conclusion correct? I couldn’t find any useful Metalink note about IMU. Am I lost?
Here we come to the subject of this blog, why not ask Google Patent search engine that is specialized for the patents search and presentation to find the document related to patent# 6981004 (Oracle IMU). This is such a great tool if you’re interested in all those nifty details – Oracle can choose what information to include in Metalink documents and what to leave out. Guess what, they really don’t have a choice in a document that is a baseline for the patent :-). They must cover all the details to prevent others to copy-cat + “patch” the solution. On the con side, some of the patents (and yes, IMU is one such patent) are documented with so much details that documents are extremely heavy to digest. You have been warned, it’s your choice, after all!
(A side note: I’m still digesting the IMU patent pdf, so I can’t confirm (nor deny) my conclusion/speculation yet, it well might be that Oracle uses some other nifty trick to protect IMU in case of instance crash – perhaps some other patented algorithm…)
dbaportal.eu 
Received explanation from Craig Shallahamer…
I received explanation about the IMU from Craig Shallahamer with updated version of the paragraph from his recently published white paper that reads:
---START
Using IMU instead of traditional undo segments does not present a recovery problem for many reasons. First, IMU structures do not have to be recovered because they are not segments. Second, a database writer will never write a changed buffer to disk unless the associated redo information has already been written to an on-line redo log. (A database writer can trigger the log writer to flush the redo log buffer.) This means Oracle will not permit the situation where a changed on-disk block exists without the associated redo written to an on-line redo log. If an instance or media failure occurs, any changed on-disk block will have their recovery information in the redo stream. So a buffer change is not a recovery issue, it’s the change to an on-disk block that is a recovery issue and Oracle has already dealt with this. Third, if a failure occurs during a read consistent operation, it simply stops without any committed data loss. So IMUs provide all the undo related capabilities without any of the standard segment management overhead. Brilliant!
---END
I think this paragraph explains “recovery” of IMU segments much better than the original one. I believe that Mr. Shallahamer will soon release an updated version of the paper.