Redo Log Buffer – What is Wrong with this Quote?

24 06 2010

June 24, 2010

I am in the process of reading the June 2010 printing (fourth printing) of the “Oracle Performance Firefighting” book.  To say that I have stumbled upon one or two gems in the book is probably an understatement.  The book is filled with interesting statements – this time I found a couple of interesting paragraphs that describe several initialization parameters and their effect on the redo log buffer prior to Oracle 9i R2, and the current behavior.

Redo Log Buffer Prior to Oracle Database 9i R2, page 297:

Having a single redo allocation latch makes enforcing redo serialization very straightforward. But as you can imagine, having a single redo allocation latch also can become a point of contention. To reduce the likelihood of this, server processes hold the allocation latch just long enough to allocate redo log buffer space. There is also the instance parameter _log_small_entry_max_size, which is used to shift allocation latch activity onto one of the redo copy latches, as discussed in the ‘Redo Allocation Latch Contention’ section later in this chapter. To further reduce the contention possibilities, Oracle allows for multiple redo copy latches. The instance parameter _log_simultaneous_copies is used to control the number of redo copy latches.

Redo Log Buffer Oracle Database 9i R2 and Later, page 298:

By default, the number of redo strands is dynamic, but it can be made static by setting the hidden instance parameter _log_parallelism_dynamic to false. When Oracle is dynamically controlling the number of redo strands, the maximum number of strands is controlled by the hidden instance parameter _log_parallelism_max. The DBA can specifically set the number of redo strands via the hidden parameter _log_parallelism. The default number of redo strands is surprisingly low—perhaps two.

What, if anything, is wrong with the above quotes from the book (it is possible that nothing is wrong)?  Keep in mind that these blog articles are intended to generate discussion – be sure to check any and all comments attached to the articles in this series.  The comment section is where the heart of the blog article material in this series will be found.

The point of blog articles like this one is not to insult authors who have spent thousands of hours carefully constructing an accurate and helpful book, but instead to suggest that readers investigate when something stated does not exactly match what one believes to be true.  It could be that the author “took a long walk down a short pier”, or that the author is revealing accurate information which simply cannot be found through other resources (and may in the process be directly contradicting information sources you have used in the past).  If you do not investigate in such cases, you may lose an important opportunity to learn something that could prove to be extremely valuable.


Actions

Information

3 responses

25 06 2010
Chris_c

Well the first thing is that the log_parallelism parameter was a normal parameter in 9.2 hidden in 10.1 and 10.2 and removed in 11g.

25 06 2010
Charles Hooper

Very nice start.

Bug in Oracle Database 9.2: http://www.freelists.org/post/oracle-l/Caution-on-LOG-PARALLELISM,1
Can’t RAC Oracle Database 9.2: http://www-01.ibm.com/support/docview.wss?uid=swg21368263
Where is that darn parameter (checked 11.1.0.7): http://www.orafaq.com/parms/parm1192.htm

27 06 2010
Charles Hooper

Regarding the second paragraph, I should add that prior to seeing Chris’ comment I had only determined that the _LOG_PARALLELISM parameter does not exist in Oracle Database 11.1.0.7, but I suspected that there might be something else that is not quite right with the quote.

Regarding the first paragraph, it also does not help that the _LOG_SMALL_ENTRY_MAX_SIZE parameter does not exist in Oracle Database 11.1.0.7, but I suspected that there might be something else that is not quite right with the quote.

Something to think about is what might happen when this 10.1.0.x or 10.2.0.x database, whose instance is using a spfile, is upgraded in-place. If the book’s advice were followed to the letter and the value of these four hidden initialization parameters were modified, how much unnecessary downtime would be suffered? As a DBA, do you really want to get into the habit of flipping hidden initialization parameters as a silver bullet for performance problems?

Speaking of silver bullets, where is that second edition ultimate oracle reference book that I ordered which was supposed to be released June 1, 2010?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s




Follow

Get every new post delivered to your Inbox.

Join 148 other followers

%d bloggers like this: