On Dec 3, 3:23 pm, Mladen Gogala <gogala.mla...
It could be the case that the Oracle Database documentation authors
were not told about the changes in sufficient detail to provide the
typical reader of the Oracle documentation library with much useful
information. The enhancements are not entirely undocumented:
"log file switch (private strand flush incomplete): User sessions
trying to generate redo, wait on this event when LGWR waits for DBWR
to complete flushing redo from IMU buffers into the log buffer; when
DBWR is complete LGWR can then finish writing the current log, and
then switch log files."
OK, the above confuses me (and possibly a couple of other readers) a
little, redo is in the in-memory undo (IMU) buffers?
I found a presentation from 2007 that was created by Stephan Haisley
(of Oracle Corp.). Although I have not examined the presentation
closely, it appears that the document provides much of the information
that probably should have appeared in the Oracle documentation
Craig Shallahamer's "Oracle Performance Firefighting" book attempted
to describe the redo and undo optimizations in recent Oracle Database
releases. Pages 280-289 of his book describe in-memory undo and I
believe that pages 298-306 are intended to describe the redo
enhancements. I reviewed this book roughly 17 months ago (http://
firefighting-fourth-printing/ )- my review indicates that I found a
couple of errors in these pages of the book, without really attempting
to drill into what is correct or incorrect about his description of in-
memory undo. Craig mentioned in the book that he used an Intel CPU
with 512MB of memory and Oracle Database 11.1 for his testing - the
documentation for Oracle Database 11.1 states that a minimum of 1GB of
memory is required for 11.1, so I am not sure if that partially
invalidates some of the tests.
There is a significant difference in the writing style and depth of
detail when comparing Craig's book and Jonathan's "Oracle Core" book.
For example, page 280 of the "Oracle Performance Firefighting" book
states: "Unfortunately, even if an undo segment buffer is changed, its
change must also be recorded in the redo log buffer. But since IMU
nodes are not undo segments, their changes do not generate redo! So,
IMU will reduce the amount of redo an instance generates."
Pages 15-16 of the "Oracle Core" book does seem to show a decrease in
the amount of redo generated. However, on page 17 the "Oracle Core"
book then makes the following statement, "This show us that the
private memory areas for a session allow roughly 64KB for 'forward'
changes, and the same again for 'undo' changes. For a 64-bit system
this would be closer to 128KB each." And on page 19, "An obvious case
where Oracle has to abandon the new mechanism is when either the
private redo thread or the in-memory undo pool becomes full... When an
area is full, Oracle creates a single redo record, copies it to the
public redo thread, and then continues using the public redo thread in
the old way."
There were excited statements in the "Oracle Performance Firefighting"
book, and as best as I can tell, no mention that the new optimizations
could be abandoned. Yet, Tanel Poder (the technical reviewer of
"Oracle Core") was aware of that limitation back in 2006 and mentioned
it in an Oracle-L thread:
I suspect that the "Oracle Core" book will establish a new standard
for the detail level of information that is expected from a technical
book. Although I must admit that I was startled to see a description
of a block dump early in the book - on page 7. For some reason, I
thought that this book was intended for people with only the Oracle
Fundamentals understood, but I am happy to see that it is a much more
rigorous piece of work (I am only about 30 pages into the book –
please do not spoil the plot of the book :-) ).
(On a side note, Oracle Press books are not published by Oracle
Corporation, or even endorsed by Oracle Corporation. I do not think
that the exclusion of the new feature descriptions was intended to
enhance book sales.)
IT Manager/Oracle DBA
K&M Machine-Fabricating, Inc.