Oracle Performance Firefighting
by Craig Shallahamer

Get the book here



Craig Shallahamer's Blog

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.
Please—Out 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.

-------------------------------

Oracle itself continues to add new performance features to the core kernel. Sometimes these take the form of new features like a new SQL optimization path. Other times, it means replacing an existing function or algorithm that many kernel developers and most DBAs will be unaware of. One such optimization is the introduction of Oracle's patented in-memory undo (IMU). Essentially, instead of maintaining undo in Oracle segments, the undo is managed, as much as possible, in memory using structures optimized for in-memory operations. But as you will learn, how Oracle does this is fascinating and foreshadows even greater things to come. But with any piece of code, there is always the possibility of a bottleneck, so I'll cover how to detect IMU performance issues and multiple ways to solve the problem (in addition to just turning it off).

Think about this for a second: If you ran a massive software company, would you sleep good at night knowing the next morning thousands of your customers would start using a brand-new algorithm in your core product and your employees have little real-world experience with the potential problems it may cause or what the solutions may be? It's not something most people consider, but over and over Oracle management must face this dilemma. So, before Oracle, or any software company for that matter, allows a new algorithm into their core bread-and-butter multibillion-dollar-brand product, it had better know that it works. And not just work, but work wonderfully. While CEOs may desire their picture on the front page of the Wall Street Journal, that's an IT manager's nightmare.

Oracle has a history of silently slipping core algorithm changes into its database server code. For example, in Oracle 7, the Oracle developers started instrumenting their code, resulting in the wait interface; the modified buffer cache LRU algorithm dramatically and silently changed, using the touch-count algorithm in Oracle8i Release 8.1.5; mutexes began being used in Oracle Database 10g Release 2; and as I'll detail in the next chapter, Oracle begin using multiple redo allocation latches in Oracle 9i Release 2. All these changes were never formally announced, and some still have not been announced or documented. If you haven't heard much about these changes, then Oracle developers did a good job of testing their code before it was released.

©2009, 2010 by Craig Shallahamer. This is copyrighted material.
Please—Out 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.


Know what's important before it's too late!

OraPub's
Performance Training

is like no other...





More Class Pics...
Get student testimonials!