Apress.Expert.Oracle.Database.Architecture.9i.and.10g.Programming.Techniques.and.Solutions.Sep.2005

148
CHAPTER 4 ■ MEMORY STRUCTURES
Shared Pool
The Shared pool is one of the most critical pieces of memory in the SGA, especially with regard
to performance and scalability. A Shared pool that is too small can kill performance to the
point where the system appears to hang. A Shared pool that is too large can have the same
effect. A Shared pool that is used incorrectly will be a disaster as well.
So, what exactly is the Shared pool? The Shared pool is where Oracle caches many bits of
“program” data. When we parse a query, the parsed representation is cached there. Before we
go through the job of parsing an entire query, Oracle searches the Shared pool to see if the
work has already been done. PL/SQL code that you run is cached in the Shared pool, so the
next time you run it, Oracle doesn’t have to read it in from disk again. PL/SQL code is not only
cached here, it is shared here as well. If you have 1,000 sessions all executing the same code,
only one copy of the code is loaded and shared among all sessions. Oracle stores the system
parameters in the Shared pool. The data dictionary cache (cached information about database
objects) is stored here. In short, everything but the kitchen sink is stored in the Shared pool.
The Shared pool is characterized by lots of small (4KB or less in general) chunks of memory.
Bear in mind that 4KB is not a hard limit—there will be allocations that exceed that
size—but in general the goal is to use small chunks of memory to prevent the fragmentation
that would occur if memory chunks were allocated in radically different sizes, from very
small to very large. The memory in the Shared pool is managed on a LRU basis. It is similar to
the buffer cache in that respect—if you don’t use it, you’ll lose it. A supplied package called
DBMS_SHARED_POOL may be used to change this behavior—to forcibly pin objects in the Shared
pool. You can use this procedure to load up your frequently used procedures and packages at
database startup time, and make it so they are not subject to aging out. Normally, though, if
over time a piece of memory in the Shared pool is not reused, it will become subject to aging
out. Even PL/SQL code, which can be rather large, is managed in a paging mechanism so that
when you execute code in a very large package, only the code that is needed is loaded into the
Shared pool in small chunks. If you don’t use it for an extended period of time, it will be aged
out if the Shared pool fills up and space is needed for other objects.
The easiest way to break Oracle’s Shared pool is to not use bind variables. As you saw in
Chapter 1, not using bind variables can bring a system to its knees for two reasons:
• The system spends an exorbitant amount of CPU time parsing queries.
• The system uses large amounts of resources managing the objects in the Shared pool as
a result of never reusing queries.
If every query submitted to Oracle is a unique query with the values hard-coded, the concept
of the Shared pool is substantially defeated. The Shared pool was designed so that query
plans would be used over and over again. If every query is a brand-new, never-before-seen
query, then caching only adds overhead. The Shared pool becomes something that inhibits
performance. A common but misguided technique that many use to try to solve this issue is
adding more space to the Shared pool, which typically only makes things worse than before.
As the Shared pool inevitably fills up once again, it gets to be even more of an overhead than
the smaller Shared pool, for the simple reason that managing a big, full Shared pool takes
more work than managing a smaller, full Shared pool.
The only true solution to this problem is to use shared SQL—to reuse queries. Earlier, in
Chapter 1, we briefly looked at the parameter CURSOR_SHARING, which can work as a short-term