You were brought to this page based on an internet search
and as a free service to Oracle DBAs.
The text below is an except from the book,
Oracle Performance Firefighting, written by
Craig Shallahamer of
OraPub, Inc.
Figures and tables are not included on this page, only their reference.
To order the book in either print or PDF form, click
here.
©2009, 2010 by Craig Shallahamer. This is copyrighted material.
PleaseOut of respect for those involved in the creation of the book and also for
their familes, we ask you to respect the copyright both in intent and deed. Thank you.
-------------------------------
As an example of how this can occur regardless of the Oracle release, referring back to Figure 8-3, suppose there was an unfortunate combination of the last allocation pointer to marker MK100 and a number of bytes large enough to push the last allocation marker clockwise beyond the last write pointer (MK300) to marker MK400. Oracle will not allow this to occur, since the redo between marker MK300 and MK400 would be overwritten. When this situation arises, the server process will post a log buffer space wait event, trigger the log writer background process to write, and wait until the log writer background process flushes the redo log buffer and moves the last write pointer beyond marker MK400. Once this takes place, the last allocation pointer will point to MK400, and the last write pointer will be set beyond marker MK400, perhaps to marker MK500.
The log buffer space wait event is most common when a system is initially placed into production or a dramatic increase in redo generation occurs. Either way, a wonderfully simplistic Oracle-focused solution that usually fixes the problem is to increase the redo log buffer size by increasing the instance parameter log_buffer. However, besides wasting memory, if the log buffer becomes too large, other wait events, such as log file sync, can arise. So be conservative to avoid introducing other problems.
Once the redo log buffer has been expanded, increased pressure will be placed on the log writer background process and the IO subsystem. So, it is common to observe the performance issue shift further on down the redo flow toward a log file sync or log file parallel write wait event. Don't be discouraged by this, as it is normal and part of the tuning cycle. What you want to see is either the response time decreasing while workload remains the same or response time remaining the same while the workload increases. If your workload is OLTP-focused, then a drop is response time is usually preferred. If your workload is more batch-centric, a workload increase (the throughput) is typically your goal. Chapter 9 will help you understand your response time and throughput options.
©2009, 2010 by Craig Shallahamer. This is copyrighted material.
PleaseOut of respect for those involved in the creation of the book and also for
their familes, we ask you to respect the copyright both in intent and deed. Thank you.
|