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.
-------------------------------
Operating system vendors try to take a single process and break it up into multiple smaller processes so performance is not constrained to a single process. In effect, they are trying to transform the situation from diagram B in Figure 3-1 to diagram A, in the hopes of increasing performance. And I'm sure the CPU vendors themselves are highly involved in reducing serialization.
My point is that everyone gets involved in reducing serialization and maximizing parallelization. It's not only a technical issue, but can also be a business issue.
However, there are times when all the time, money, creative thinking, and technical prowess come to a grinding serialization slowdown. In the Oracle world, this can occur when accessing memory. When a process wants to access Oracle memory structures, Oracle must ensure complete serialization control. It may be able to parallelize if multiple processes want to look at a memory structure, but it still must have full control. Memory serialization control is what latching and mutexes are all about, and why this chapter is so important to Oracle performance firefighting.
©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.
|