S hared P ool
Library Cache
ALL ABOUT SHARED
POOL
Tapas Kumar
Oracle DBA
TATA CONSULTANCY SERVICES
INTRODUCTION
What is shared pool? This first query
that comes, let us have a brief
introduction regarding shared pool
here first.
Most of the people knows that shared
pool is the part of System Global
Area (SGA) it’s true but little else,
What exactly the shared pool?
Shared pool are contain lots of key
memory areas of Oracle and in
Instance tuning the major area that
we have to tune is shared pool if
shared pool defined improperly the
overall database performance will
suffer.
INTERNAL STRUCTURE –
Majority shared pool related to the
two part of SGA one is fixed are
which is relatively constant to a
oracle instance for a particular
version and the second part is
Variable area which gradually shrink
and grow for user and application
requirement.
Now we should do a close look of
various component of Shared Pool –
Basically Shared Pool could be
divided in three major parts –
1. Library Cache
2. Dictionary Cache
3. Control Structure
Library Cache –
Memory Part where all the SQL and
PL/SQL statement executed, all
execution plan reside here for SQL
statement stored here.
We can further subdivide this Library
Chache into –
1. Shared and Private SQL
Area
2. PL/SQL Procedure Part
Shared and Private SQL Area –
Control Structure
Dictionary Cache
S QL Area
PL?SQL Procedure Control Struct Object definition
Latch
LOCK
A shared SQL area contains the parse
tree and execution plan for a single
SQL statement, or for similar SQL
statements. Oracle saves memory by
using one shared SQL area for
multiple similar DML statements,
particularly when many users
execute the same application.
A shared SQL area is always in the
shared pool.
Oracle allocates memory from the
shared pool when a SQL statement is
parsed; the size of this memory
depends on the complexity of the
statement. If a SQL statement
requires a new shared SQL area and
the entire shared pool has already
been allocated, Oracle can deallocate
items from the pool using a modified
least Recently used algorithm until
there is enough free space for the
new statement's shared SQL area. A
private SQL area contains data such
as bind information and runtime
buffers. Each session that issues a
SQL statement has a private SQL
area. Each user that submits an
identical SQL statement has his or
her own private SQL area that uses a
single shared SQL area; many private
SQL areas can be associated with the
same shared SQL area.
A private SQL area contains data
such as bind information and runtime
buffers. Each session that issues a
SQL statement has a private SQL
area. Each user that submits an
identical SQL statement has his or
her own private SQL area that uses a
single shared SQL area; many private
SQL areas can be associated with the
same shared SQL area.
A private SQL area has a persistent area and a
runtime area:
• The persistent area contains
bind information that persists
across executions, code for
datatype conversion (in case
the defined datatype is not
the same as the datatype of
the selected column), and
other state information (like
recursive or remote cursor
numbers or the state of a
 parallel query). The size of the
persistent area depends on
the number of binds and
columns specified in the
statement. For example, the
persistent area is larger if
many columns are specified in
a query.
• The runtime area contains
information used while the
SQL statement is being
executed. The size of the
runtime area depends on the
type and complexity of the
SQL statement being
executed and on the sizes of
the rows that are processed
by the statement. In general,
the runtime area is somewhat
smaller for INSERT, UPDATE
and DELETE statements than
it is for SELECT statements,
particularly when the SELECT
statement requires a sort.
Oracle creates the runtime area as
the first step of an execute request.
For INSERT, UPDATE, and DELETE
statements, Oracle frees the runtime
area after the statement has been
executed. For queries, Oracle frees
the runtime area only after all rows
are fetched or the query is cancelled.
The location of a private SQL area
depends on the type of connection
established for a session. If a session
is connected via a dedicated server,
private SQL areas are located in the
user's PGA. However, if a session is
connected via the multi-threaded
server, the persistent areas and, for
SELECT statements, the runtime
areas, are kept in the SGA
(x$ksmms) table provide the
runtime information regarding SQL
area in Library Cache which is
suppose to be allocated to a
particular Oracle Instance –
E.g. –
select * from X$KSMSS
where KSMSSNAM = 'sql_area'
and KSMSSLEN <> 0 ;
---------------- ---------- ---------- ----------
-------------------------- ----------
ADDR INDX INST_ID KSMSSLEN
KSMSSNAM KSMDSIDX
000000011049B268 29 1 13480352
sql area 1
PL/SQL Procedure Part –
Oracle processes PL/SQL program
units (procedures, functions,
packages, anonymous blocks, and
database triggers) much the same
way it processes individual SQL
statements. Oracle allocates a
shared area to hold the parsed,
compiled form of a program unit.
Oracle allocates a private area to
hold values specific to the session
that executes the program unit,
including local, global, and package
variables (also known as package
instantiation) and buffers for
executing SQL. If more than one user
executes the same program unit,
then a single, shared area is used by
all users, while each user maintains a
separate copy of his or her private
SQL area, holding values specific to
his or her session.
Individual SQL statements contained
within a PL/SQL program unit are
processed as described in the
previous sections. Despite their
origins within a PL/SQL program unit,
these SQL statements use a shared
area to hold their parsed
representations and a private area
for each session that executes the
statement.
(x$ksmms) table provide the
runtime information regarding
PL/SQL area in Library Cache which is
suppose to be allocated to a
particular Oracle Instance –
E.g. –
select * from X$KSMSS
where KSMSSNAM like 'PL/SQL%'
and KSMSSLEN <> 0 ;
ADDR INDX INST_ID KSMSSLEN
KSMSSNAM KSMDSIDX
---------------- ---------- ---------- ----------
-------------------------- ----------
000000011049B268 28 1 1501552
PL/SQL DIANA 1
000000011049B268 37 1 1357968
PL/SQL MPCODE 1
PL/SQL MPCODE stands for machine
dependent pseudocode.
PL/SQL DIANA stands for the PL/SQL
code size in the shared pool at
runtime.
Library Cache Manager –

The main purpose of the library
cache is to provide a mechanism to
locate and store any library cache
object quickly. A hashing mechanism
is used to locate a handle, which
contains the identity (name) of the
object. The library cache handle then
points us to one or more the library
cache objects and their contents.
The library cache caches different
types of library objects (e.g.
packages, procedures, functions,
shared cursors, anonymous
PL/SQL blocks, table definitions, view
definitions, form definitions).
Library cache memory is allocated
out of the top most heap or the
generic SGA heap. When the library
cache, KGL, needs more memory, it
will call the heap manager (KGH) to
allocate it. The library cache consists
of a hash table, which consists of an
array of hash buckets. Each hash
bucket is a doubly linked list of
library cache object handles. Each
library cache object
handle points to a library cache
object and has a reference list. The
library cache object is further broken
down into other components such as
a dependency table, a child table,
and an authorisation table (to name
a few).
Library Cache Manager (Hash
Table and Hash Bucket) –
The hash table is an array of hash
buckets. The initial number of the
hash buckets is 251; however, the
number of buckets will increase when
the number of objects in the table
exceeds the next number. The next
numbers are the next higher prime
value. They are 251, 509, 1021,
2039, 4093, 8191, 16381, 32749,
65521, 131071, and 4292967293
where the "n+1"th size is
approximately twice the "n"th size.
The resulting expansion of the hash
table will involve allocating a new
hash table at the next prime size,
rehashing the library cache objects
from the old table to the new table,
and freeing the space allocated from
the old hash table. Throughout this
procedure, access to the hash table
is blocked (by freezing access to the
child
latches) as one user allocates new
buckets to double the size of the
hash table and then uses the least
significant bits of the hash value to
determine which new bucket a
handle belongs to. Contrary to
common belief, this is a rare and
inexpensive operation that may
cause a short (approximately 3-5
second) hiccup in the system. The
hash table never shrinks.
The library cache manager will apply
a modulo hash function to a given
object’s namespace, object name,
owner, and database link to
determine the hash bucket where the
object should be found. It then walks
down the corresponding linked list to
see if the object is there. If the object
does not exist, the library cache
manager will create an empty object
with the given name, insert it in the
hash table, and request the client
load it by calling the client's
environment-dependent load
function. Basically, the client would
read from disk, call the heap
manager to allocate memory, and
load the object.
Library Cache Handle –
 000000011049AE88 60 1 1092352
dictionary cache 2

Control Structure -

This contain the information

regarding Internal Latch and Locks
(Data Structure), it also contain
buffer header, the process session
A library cache handles points to a and transaction arrays.
library cache object. It contains the The size of these arrays depends on
name of the library object, the the setting of Initialisation parameter
namespace, a timestamp, a of Init.ora file and can’t be changed
reference list, a list of locks locking without shutting down the database.
the object and a list of pins pinning
the object. Each object is uniquely
identified by the name within its
namespace. The library cache
manager will generate a name for
every object, even anonymous
PL/SQL blocks. The handle uses
namespaces to partition library
cache objects by types. These are
examples of different types of Shared Pool Chunks –
namespaces: one namespace holds
all namespaces depended on PL/SQL Have close looks of Shared Pool, For
objects, one for package bodies and that we should have a close look at
table bodies, one for shared cursors; x$ksmsp each row in this table
one for triggers; one for indexes; and shows a chunk of shared pool –
one for clusters. The namespace
KSMCHCOM KSMCHPTR KSMCHSIZ
describes the type of an item KSMCHCLS
kept in the library cache. The name ---------------- ---------------- ---------- --------
sql area 0700000005D85750 1360
consists of the object owner name, freeabl
the object name, the database link 0700000005D846F8 4184 freeabl
KGL handles 0700000005D84520 472
name, and the database link owner recr
name. A comprehensive list can be library cache 0700000005D84478 168
viewed from v$librarycache. freeabl
0700000005D84150 808 recr
A handle can be freed if there are no KQR PO 0700000005D83D20 1072
current references to it and it has not recr
KGL handles 0700000005D83B48 472
been expressly marked to be kept. recr
We use this to determine when a library cache 0700000005D83AA0 168
freeabl
handle should be unpinned in 0700000005D83778 808 recr
memory. 0700000005D83450 808 freeabl
KGL handles 0700000005D83300 336

Dictionary Cache – recr

Table definition against which an When each shared pool chunk is

application user suppose to do a
query, it include table’s associated
Index and Columns and privilege
information regarding table as we as
columns.
select * from X$KSMSS
where KSMSSNAM like 'PL/SQL%'
and KSMSSLEN <> 0 ;
allocated the code is passed to a
function that does the work of
allocation and this address is visible
to KSMCHCOM column, which
describe the purpose of allocation.
This chunk is supposed to be larger
then the size of the object as it also
contains the header information.

ADDR INDX INST_ID KSMSSLEN The column KSMCHCLS represent

KSMSSNAM KSMDSIDX
---------------- ---------- ---------- ---------- the class, there are basically four
-------------------------- ---------- type of classes –
Freeable – can be freed only contain reserved size, here REQUEST_MISS
the objects needed for the session shows the number of times the
call. request miss for a large chunk.
Free – free and not contained by
valid object.
Recr – contain by temporary objects. SHARED_POOL SIZE
Parm – contained by the permanent CALCULATION –
object.
The shared pool size is highly
So the overall summary - application dependent. To determine
the shared pool size for a production
select KSMCHCOM name, system it is generally necessary to
count(KSMCHCOM),
sum(decode(KSMCHCLS,'recr',KSMCHSIZ)) develop the application run it on a
RECREATABLE, test environment (should be enough
sum(decode(KSMCHCLS,'freeabl',KSMCHSIZ))
FREEABLE like production system) get some test
from result and on the basis of that
x$ksmsp
group by KSMCHCOM ;
calculate the shared pool size. There
are some few step which we should
NAME COUNT(KSMCHCOM) RECREATABLE
FREEABLE
consider while calculating the shared
---------------- --------------- ----------- ---------- pool –
PARAMETER ENTRY 4 192
PARAMETER TABLE 1 2064
PL/SQL DIANA 237 12816 479672
PL/SQL MPCODE 23 11792 50336
STORED OBJECTS – The amount of
PLS cca hp desc 1 376 shared pool that needs to be
PLS non-lib hp 1 2136
PRESENTATION TA 1 2064 allocated for objects that are stored
SERVICE NAME EN
SERVICE NAMES T
2
1
152
2064
in the database like packages and
character set m 5 31936 views is
character set o 4 318648
easy to measure. You can just
LRU List – measure their size directly with the
following statement:
When a process starts it allocate
select sum(sharable_mem) from
some memory and when it’ fails to
V$DB_OBJECT_CACHE;
allocated required memory,
Then it try to remove chunk
containing recreatable object from SQL
shared pool to get the desired size of The amount of memory needed to
chunk, and removing these object store sql statements in the shared
from memory is based on LRU(Least pool is more difficult to measure
Recent Used) means those objects because of the needs of dynamic sql.
that are frequently pinned kept in the If an application has no dynamic sql
memory and those are unpinned we then the amount of memory can
generally remove those objects from simply be measured after the
the memory. Object those required application has run for a while by just
again known as transient and other selecting it out of the shared pool as
known as recurrent. follows:

ORA-04331 ‘unable to allocate x select sum(sharable_mem) from v$sqlarea;

bytes of shared pool’ when all
the free memory fully exhausted If the application has a moderate or
(Later we will discuss the shared large amount of dynamic sql like
pool fragmentation). most applications do, then a certain
amount of memory will be needed for
There is one list maintained which the shared sql plus more for the
known as Reserved List, it generally dynamic sql. Sufficient memory
5% of the total size of Shared Pool should be allocated so that the
and reserved size is defined by dynamic sql does not age the shared
SHARED_POOL_RESERVED_SIZE sql out of the shared pool.
parameter in Init.ora parameter file. Approximated memory could be
With the help of calculated by the following:
v$shared_pool_reserved we can see
select sum(sharable_mem) from v$sqlarea where
executions > 5;
The remaining memory in v$sqlarea
is for dynamic sql.
PER-USER PER-CURSOR MEMORY
–
You will need to allow around 250
bytes of memory in the shared pool
per concurrent user for each open
cursor that the user
has whether the cursor is shared or
not. During the peak usage time of
the production system, you can
measure this as follows:
select sum(250 * users_opening) from
v$sqlarea;
In a test system you can measure it
by selecting the number of open
cursors for a test user and
multiplying by the total number of
users:
select 250 * value bytes_per_user
from v$sesstat s, v$statname n
where s.statistic# = n.statistic#
and n.name = 'opened cursors current'
and s.sid = 23; -- replace 23 with session id of
user being measured
The per-user per-cursor memory is
one of the classes of memory that
shows up as 'library cache' in
v$sgastat.
MTS –
If you are using multi-threaded
server, then you will need to allow
enough memory for all the shared
server users to put their session
memory in the shared pool. This can
be measured for one user with the
following query:
select value sess_mem
from v$sesstat s, v$statname n
where s.statistic# = n.statistic#
and n.name = 'session uga memory'
and s.sid = 23; -- replace 23 with session id of
user being measured
A more conservative value to use is
the maximum session memory that
was ever allocated by the user:
select value sess_max_mem
from v$sesstat s, v$statname n
where s.statistic# = n.statistic#
and n.name = 'session uga memory max'
and s.sid = 23; -- replace 23 with session id of
user being measured
To select this value for all the
currently logged on users the
following query can be used:
select sum(value) all_sess_mem
from v$sesstat s, v$statname n
where s.statistic# = n.statistic#
and n.name = 'session uga memory max';
OVERHEAD –
You will need to add a minimum of
30% overhead to the values
calculated above to allow for
unexpected and unmeasured usage
of the shared pool.
Estimating Procedure (From
Metalink) –
set serveroutput on;
declare
object_mem number;
shared_sql number;
cursor_mem number;
mts_mem number;
used_pool_size number;
free_mem number;
pool_size varchar2(100);
begin
-- Stored objects (packages, views)
select sum(sharable_mem) into object_mem
from v$db_object_cache;
-- Shared SQL -- need to have additional
memory if dynamic SQL used
select sum(sharable_mem) into shared_sql from
v$sqlarea;
-- User Cursor Usage -- run this during peak
usage
select sum(250*users_opening) into
cursor_mem from v$sqlarea;
-- For a test system -- get usage for one user,
multiply by # users
-- select (250 * value) bytes_per_user
-- from v$sesstat s, v$statname n
-- where s.statistic# = n.statistic#
-- and n.name = 'opened cursors current'
-- and s.sid = 25; -- where 25 is the sid of the
process
-- MTS memory needed to hold session
information for shared server users
-- This query computes a total for all currently
logged on users (run
-- during peak period). Alternatively calculate
for a single user and
-- multiply by # users.
select sum(value) into mts_mem from
v$sesstat s, v$statname n
where s.statistic#=n.statistic#
and n.name='session uga memory max';
-- Free (unused) memory in the SGA: gives an
indication of how much memory
-- is being wasted out of the total allocated.
select bytes into free_mem from v$sgastat
where name = 'free memory';
-- For non-MTS add up object, shared sql,
cursors and 30% overhead.
used_pool_size :=
round(1.3*(object_mem+shared_sql+cursor_me
m));
-- For MTS add mts contribution also.
-- used_pool_size :=
round(1.3*(object_mem+shared_sql+cursor_me
m+mts_mem));
select value into pool_size from v$parameter
where name='shared_pool_size';
-- Display results
dbms_output.put_line ('Obj mem: '||to_char
(object_mem) || ' bytes');
dbms_output.put_line ('Shared sql: '||to_char
(shared_sql) || ' bytes');
dbms_output.put_line ('Cursors: '||to_char
(cursor_mem) || ' bytes');
dbms_output.put_line ('MTS session: '||to_char
(mts_mem) || ' bytes');
dbms_output.put_line ('Free memory: '||to_char
(free_mem) || ' bytes ' || '(' ||
to_char(round(free_mem/1024/1024,2)) || 'M)');
dbms_output.put_line ('Shared pool utilization
(total): '|| to_char(used_pool_size) || ' bytes ' ||
'(' ||
to_char(round(used_pool_size/1024/1024,2)) ||
'M)');
Technical Reports Compendium, Volume I, 1996
Shared Pool Internals
dbms_output.put_line ('Shared pool allocation
(actual): '|| pool_size ||' bytes ' || '(' ||
to_char(round(pool_size/1024/1024,2)) || 'M)');
dbms_output.put_line ('Percentage Utilized: '||
to_char (round(used_pool_size/pool_size*100))
|| '%');
end;
MONITORING & TUNING –
Let begin with major part which is
knows as shared pool tuning and
Oracle recommend that the default
size of Shared Pool in Init.ora
parameter should be ¼ of the Total
SGA in a general scenario.
The other shared pool parameter
controls how to the variable space
area in the shared pool is parsed out.
According to the suggestion give by
Oracle if our total SGA size is 100 MB
then we should set our Shared Pool
size 25 MB and latter increase
gradually as needed by the system.
Now a question comes in our mind
what are the key area should be
monitored by the DBA to get the
knowledge that the shared pool size
is small.
From V$SGASTAT and V$SQLAREA we
will get this information.
Shared Pool usage we can see at a
given point of time from the following
script –
select
sum(a.KSMSSLEN)/(1024*1024) Pool_used,
max(c.KSPPSTVL)/(1024*1024) pool_size,
(max(c.KSPPSTVL)/(1024*1024))-
sum(a.KSMSSLEN)/(1024*1024)) pool_avail,
(sum(a.KSMSSLEN)/max(c.KSPPSTVL))*100
pool_pct
from x$ksmss a, x$ksppi b, x$ksppcv c
where a.KSMSSNAM in (
'reserved stopper',
'table definiti',
'dictionary cache',
'library cache',
'sql area',
'PL/SQL DIANA',
'SEQ S.O.')and
b.indx = c.indx and
b.KSPPINM='shared_pool_size'
The out of the above script -
POOL_USED POOL_SIZE POOL_AVAIL POOL_PCT
---------------- ---------------- -------
8.98988342 32 23.0101166 28.0933857
If shared percentage (POOL_PCT) in
nineties then we need to increase the
size of shared pool, but some time
the reason may be other of hogh
percentage of shared pool. The
above scripts should run periodically
to get a summary of Shared Usage at
peak and normal time.
Now we should focus on high
percentage usage of shared pool why
it high (more then 90%).
We should see whether the shared
pool fill with reusable sql or with bad
sql, before increase the size of
shared pool we should examine all
the key areas, it might be possible to
flush the shared pool would resolved
the high percentage issue of shared
pool.
So how we can see that what is in
the shared pool?
Whether is being properly used or
not. For that we can generate some
common useful report.
First report will shown here the
individual mapping of user with
shared pool –
Create a temporary table to hold the
information related to sql area for all
users,that produces a summary
report for each user.
create table temp_sql_report as (select
b.username,
a.SQL_TEXT,
a.execution,
a.load,
a.user_executing
a.SHARABLE_MEM,
a.PERSISTENT_MEM,
a.RUNTIME_MEM
from v$sqlarea a,dba_users b
where a.PARSING_USER_ID = b.USER_ID
SQL SUMMARY REPORT –
REM <-- SQLAREA SUMMARY REPORT
REM Mapping between user and sql area
usage.
Col username for a20 heading USER
Col sharable_mem for a25 heading SHARABLE
Col persistent_mem for a20 heading PERSIS
Col run_time for a20 heading RUNTIME
start title80 ‘SQL AREA SUMMARY REPORT’
Spool sql_area_summary_report
Select The out put of the report look like
Username,
Sum(SHARABLE_MEM), this –
Sum(PERSISTENT_MEM),
Sum(RUNTIME_MEM) USERS
From temp_sql_report ------------------------------
Group by username; SQL_TEXT
Spool off -----------------------------------------------------------------
/ -----------------------------------------------------------------
--
USERNAME SUM(SHARABLE_MEM) EXECUTIONS LOADS USERS_EXECUTING
SUM(PERSISTENT_MEM) SUM(RUNTIME_MEM) SHARABLE_MEM PERSISTENT_MEM
------------------------------ ----------------- ---------- ---------- --------------- ------------ --------------
------------------- ---------------- 0 2 0 16439 1376
SYS 3004291
237048 1097504 SYS
TEST 281085 DECLARE
18040 83328 P_EQP_NO
mv_tplans.eqm_eqp_no_fk%type :=
upper('GLDU0371682');
P_MESSAGE_NO
This output of this summary report mv_edimessages.message_no%type := NULL;
shows here the sql area used by each P_EQP_SIZE
user. Now try to analyse the mv_tplans.eqs_eqp_size_fk%type := 20;
P_EQP_TYPE
summary report, if a particular hold a mv_tplans.eqt_eqp_type_code_fk%type :=
large amount of memory then that upper('GP
'); P_REF_NO
means the sql’s used by that user are mv_edimessages.ref1_no%type :=
bad every time it generate different upper('HAI2000229/1');
P_REF_TYPE
execution plan for similar kind of mv_edimessages.ref1_type%type := B;
queries, the coding produce a large P_FACILITY
number of nonreusable sql area. mv_edimessages.fac_facility_fk%type :=
upper('SCTSOUGB');
P_EVENT_DATETM
Now we can generate an another mv_edimessages.event_datetm%type :=
SYSDATE; P_EVENT_TYPE
where we will shown the actual sql mv_eventtableitems.event_type%type := 4;
statement executed by a user and P_FCL_LCL mv_tplans.fcl_lcl%type := NULL;
P_BOOKING
how many time a sql statement _ITEM mv_tplans.booking_item%type := 1;
execute by a user , what amount of P_PLAN_ID mv_tplans.tplan_id%type ;
memory that sql statement took to P_VERSION_NO mv_tplans.version_no%type;
P_LEG_ID mv_tplanlegs.tleg_id%type;
execute the statement. p_ack_reqd_ind number := 0;
P_ACK_ERROR_CODE VARCHAR2(8);
column sql_text format a60 heading Text P_BOOKING_REF_NO mv
word_wrapped _tplans.booking_ref_no%type;
column sharable_mem heading Shared| P_RETURN_CODE NUMBER; P_RETURN_MESG
Bytes
column persistent_mem heading One warning about the script, the
Persistent|Bytes
column loads heading Loads
report it generates can run to several
column users format a15 heading "User" hundred pages for a user with a large
column executions number of SQL areas. What things
heading "Executions"
column users_executing heading should we watch for in a user's SQL
"Used By" areas? First, watch for the non-use of
start title132 "Users SQL Area Memory Use"
spool Sql_info bind variables, bind variable usage is
set long 2000 pages 59 lines 132 shown by the inclusion of variables
break on users
compute sum of sharable_mem on users
such as ":4" in the SQL text. As the
compute sum of persistent_mem on users stement using the bind variable: 4 so
compute sum of runtime_mem on users is reusable. Non-bind usage means
select
username users, hard coded values such as upper
sql_text, ('GLDU0371682') are used. Notice
Executions,
loads, that for most of the rest of the
users_executing, statements in the report no bind
sharable_mem,
persistent_mem
variables are used even though
from many of the SQL statements are
temp_sql_report nearly identical. This is one of the
where b.username like upper('%&user_name%')
order by 3 desc,1; leading causes of shared pool misuse
spool off and results in useful SQL being drown
pause Press enter to continue
in tons of non-reusable garbage SQL.

The problem with non-reusable SQL

is that it must still be looked at by
any new SQL inserted into the pool
(actually it's hash value is scanned).
While a hash value scan may seem a
small cost item, if your shared pool
contains tens of thousands of SQL
areas this can be a performance
bottleneck.
As the SQL statement issued by the
user is directly related to the shared
pool and using a good mechanism of
coding improve the system
performance and also avoid
redundant parsing of PL/SQL and SQL
statement for Library Cache
(memory + CPU). As Library Cache is
a part of Shared pool so Indirectly we
can say we tuned the Shared Pool.
Let have a Close look of various
parsing type of SQL –
Literal SQL – A literal SQL
statement is considered as one which
use literals in the predicates rather
then bind variable, where the value
of the literal is likely to differ
between various execution of the
statement.
E.g 1 –
SELECT * FROM temp_x WHERE col_1='x';
is used by the application instead of
SELECT * FROM temp_x WHERE ename=:x;
Eg 2:
SELECT sysdate FROM dual;
does not use bind variables but
would not be considered as a literal
SQL statement for this article as it
can be shared.
Eg 3:
SELECT vers ion FROM app_vers ion WHERE
vers ion>2.0;
If this same statement was used for
checking the 'version' throughout
the application then the literal value
'2.0' is always the same so this
statement can be considered
sharable.
Hard Parse -
If a new SQL statement is issued
which does not exist in the shared
pool then this has to be parsed fully.
Eg: Oracle has to allocate memory
for the statement from the shared
pool, check the statement
syntactically and semantically etc...
This is referred to as a hard parse, is
very expensive in both terms of CPU
used, and in the number of latch gets
performed.
Soft Parse -
If session issues a SQL statement,
which is already in the shared pool
AND it, can use an existing version of
that statement then this is known as
a 'soft parse'. As far as the
application is concerned it has asked
to parse the statement.
Identical Statements?
If two SQL statements mean the
same thing but are not identical
character for character then from an
Oracle viewpoint they are different
statements. Consider the following
issued by SCOTT in a single session:
SELECT ENAME from TEMP_X;
SELECT ename from temp_x;
Although both of these statements
are really the same they are not
identical as an upper case 'T' is not
the same as a lower case 't'.
Sharable SQL
If two sessions issue identical SQL
statements it does NOT mean that
the statement is sharable. Consider
the following:
User USER_X has a table called
TEMP_X and issues:
SELECT column_x from TEMP_X;
User USER_Y has his own table called
TEMP_X and also issues:
SELECT column_y from TEMP_X;
Although the text of the statements
are identical the TEMP_X tables are
different objects. Hence these are
different versions of the same basic
statement. There are many things
that determine if two identical SQL
strings are truly the same statement
(and hence can be shared) including:
All object names must resolve to the
same actual objects
The optimiser goal of the sessions
issuing the statement should be the
same
The types and lengths of any bind
variables should be "similar". (We
don’t discuss the details of this here
but different types or lengths of bind
variables can cause statements to be
classed as different versions)
The NLS (National Language Support)
environment which applies to the
statement must be the same
Versions of a statement
As described in 'Sharable SQL' if two
statements are textually identical but
cannot be shared then these are
called 'versions' of the same
statement. If Oracle matches to a
statement with many versions it has
to check each version in turn to see if
To give a balanced picture this short
section describes the benefits of both
literal SQL and sharable SQL.
Literal SQL
The Cost Based Optimiser (CBO)
works best when it has full statistics
and when statements use literals in
their predicates. Consider the
following:
SELECT distinct cust_ref FROM orders WHERE
total_cost < 10000.0;
Versus
SELECT distinct cust_ref FROM orders WHERE
total_cost < :bindA;

it is truly identical to the statement

For the first statement the CBO could
currently being parsed. Hence high
use histogram statistics that have
version counts are best avoided by:
been gathered to decide if it would
be fastest to do a full table scan of
Standardising the maximum bind
ORDERS or to use an index scan on
lengths specified by the client
TOTAL_COST (assuming there is one).
Avoid using identical SQL from lots of
In the second statement CBO has no
different schemas, which use private
idea what percentage of rows fall
objects. Eg: SELECT xx FROM
below ":bindA" as it has no value for
MYTABLE; where each user has their
this bind variable to determine an
own MYTABLE
execution plan . Eg: ":bindA" could be
Setting
0.0 or 99999999999999999.9
_SQLEXEC_PROGRESSION_COST to
'0' in Oracle 8.1
There could be orders of magnitude
difference in the response time
Library Cache and Shared Pool
between the two execution paths so
latches
using the literal statement is
preferable if you want CBO to work
The shared pool latch is used to
out the best execution plan for you.
protect critical operations when
This is typical of Decision Support
allocating and freeing memory in the
Systems where there may not be any
shared pool.
'standard' statements, which are
The library cache latches (and the
issued repeatedly so the chance of
library cache pin latch in Oracle 7.1)
sharing a statement is small. Also the
protect operations within the library
amount of CPU spent on parsing is
cache itself.
typically only a small percentage of
All of these latches are potential
that used to execute each statement
points of contention. The number of
so it is probably more important to
latch gets occurring is influenced
give the optimiser as much
directly by the amount activity in the
information as possible than to
shared pool, especially parse
minimise parse times.
operations. Anything that can
minimise the number of latch gets
Sharable SQL
and indeed the amount of activity in
the shared pool is helpful to both
If an application makes use of literal
performance and scalability.
(unshared) SQL then this can
severely limit scalability and
Literal SQL versus Shared SQL
throughput. The cost of parsing a
new SQL statement is expensive both
in terms of CPU requirements and the
number of times the library cache
and shared pool latches may need to
be acquired and released.
Eg: Even parsing a simple SQL
statement may need to acquire a
library cache latch 20 or 30 times.
The best approach to take is that all
SQL should be sharable unless it is
adhoc or infrequently used SQL
where it is important to give CBO as
much information as possible in order
for it to produce a good execution
plan.
Reducing the load on the Shared Pool
Parse Once / Execute Many
By far the best approach to use in
OLTP type applications is to parse a
statement only once and hold the
cursor open, executing it as required.
This results in only the initial parse
for each statement (either soft or
hard). Obviously there will be some
statements which are rarely
executed and so maintaining an open
cursor for them is a wasteful
overhead.
Note that a session only has
<Parameter: OPEN_CURSORS>
cursors available and holding cursors
open is likely to increase the total
number of concurrently open cursors.
In precompilers the HOLD_CURSOR
parameter controls whether cursors
are held open or not while in OCI
developers have direct control over
cursors.
Eliminating Literal SQL
If you have an existing application it
is unlikely that you could eliminate
all literal SQL but you should be
prepared to eliminate some if it is
causing problems. By looking at the
V$SQLAREA view it is possible to see
which literal statements are good
candidates for converting to use bind
variables. The following query that
shows SQL in the SGA where there
are a large number of similar
statements:
SELECT substr (sq l _ text ,1 ,40) "SQL" ,
count(*) ,
sum(executions) "TotExecs"
FROM v$sqlarea
WHERE execut ions < 5
GROUP BY substr(sql_text,1,40)
HAVING count(*) > 30
ORDER BY 2 ;
Note: If there is latch contention for
the library cache latches the above
Statement may cause yet further
contention problems.
The values 40,5 and 30 are example
values so this query is looking for
different statements whose first 40
characters are the same which have
only been executed a few times each
and there are at least 30 different
occurrences in the shared pool. This
query uses the idea it is common for
literal statements to begin "SELECT
col1, col2, col3 FROM table
WHERE..." with the leading portion of
each statement being the same.
Note: There is often some degree of
resistance to converting literal SQL to
use bind variables. Be assured that it
has been proven time and time again
that performing this conversion for
the most frequently occurring
statements can eliminate problems
with the shared pool and improve
scalability greatly.
Performance Effects
Oracle performance can be severely
compromised by large volumes of
literal SQL. Some of the symptoms
that may be noticed are:
• System is CPU bound and exhibits
an insatiable appetite for CPU.
• System appears to periodically
“hang” after some period of
normal operation.
• Latch contention on shared pool
and library cache latches.
• Increasing the shared pool size
delays the problem but it re-
occurs more severely.
Identifying the Problem
An Oracle instance suffering from too
much literal SQL will likely exhibit
some of the symptoms above. There
are several investigations the DBA
can use to help confirm that this is
indeed happening in the instance.
Library Cache Hit Ratio
The library cache hit ratio should be
very high (98%) when SQL is being
shared and will remain low regardless
of shared pool sizing adjustments
when SQL is chronically non-
sharable. Use the following query to
determine the hit ratios by
namespace in the library cache.
SELECT namespace
,(100*gethitratio ) hit_ratio
FROM v$librarycache;
The “SQL AREA” namespace will be
the one affected by literal SQL.
SQL Parse-to- Execute Ratio
The following query displays the
percentage of SQL executed that did
not incur an expensive hard parse.
Literal SQL will always be fully
parsed, so a low percentage may
indicate a literal SQL or other SQL
sharing problem.
SELECT 100 * (1 -
A.hard_parses/B.executions)
noparse_ratio
FROM
(select value hard_parses
from v$sysstat
where name = 'parse count
(hard)' ) A
,(select value executions
from v$sysstat
where name = 'execute count' )
B;
Again, when this ratio is high Oracle
is sparing CPU cycles by avoiding
expensive parsing and when low
there may be a literal SQL problem.
Latch Free Waiters
A telltale sign that the instance is
suffering library cache and shared
pool problems is active latch
contention with sessions waiting on
the “latch free” wait event. The
following query will select all current
sessions waiting for either the shared
pool or library cache latches.
SELECT sid, event, name latch
FROM v$session_wait w
,v$latch l happening is to look for ORA-4031
WHERE w.event = 'latch free'
AND l.latch# = w.p2
AND l.name IN (‘shared
pool’,’library cache’);
When this query selects more than 5-
10% of total sessions there is likely
very serious performance
degradation taking place and literal
SQL may be the culprit.
Finding Literal SQL
We can attempt to locate literal SQL
in the V$SQL fixed view by grouping
and counting statements that are
identical up to a certain point based
on the observation that most literal
SQL becomes textually distinct
toward the end of the statement (e.g.
in the WHERE clause). The following
query returns SQL statements having
more than 10 statements that
textually match on leading substring.
SELECT S.sql_text
FROM v$sql S
,(select substr(sql_text,1,&&size)
sqltext
,count(*)
from v$sql
group by
substr(sql_text,1,&&size)
hav ing count(* ) > 10
) D
WHERE substr(S.sql_text,1,&&size) =
D.sqltext;
The SQL*Plus substitution variable
&&size can be adjusted to vary the
text length used to match
statements, as can the value 10 used
to filter by level of duplication. Note
that this query is expensive and
should not be executed frequently on
production systems.
MEMORY FRAGMENTATION –
The primary problem that occurs is
that free memory in the shared pool
becomes fragmented into small
pieces over time.
Any attempt to allocate a large piece
of memory in the shared pool will
cause large amount of objects in the
library cache to be flushed out and
may result in an ORA-4031 out of
shared memory error.
DIAGNOSIS
i) ORA-4031 ERROR
One way to diagnose that this is
errors being returned from
applications. When an attempt is
made to allocate a large contiguous
piece of shared memory, and not
enough contiguous memory can be
created in the shared pool, the
database will signal this error.
Before this error is signalled, all
objects in the shared pool that are
not currently pinned or in use will be
flushed from the shared pool, and
their memory will be freed and
merged. This error only occurs when
there is still not a large enough
contiguous piece of free memory
after this happens. There may be
very large amounts of total free
memory in the shared pool, but just
not enough contiguous memory.
Note: The compiled code for a
package was split into more than
one-piece, each piece being only
about 12K in size. So, the 64K
restriction was lifted; however,
packages larger 100K still may have
problems compiling. Furthermore,
with releases 7.2/2.3 of
Oracle7/PLSQL, loading a library unit
(package, function, and procedure)
into the shared pool does NOT
require one contiguous piece of
memory in the shared pool. This
means that chances of getting ORA-
4031 is dramatically reduced.
ii) INIT.ORA PARAMETER
An init.ora parameter can be set so
that whenever an ORA-4031 error is
signalled a dump will occur into a
trace file. By looking for these trace
files, the DBA can determine that
these errors are occurring. This is
useful when applications do not
always report errors signalled by
oracle, or if users do not report the
errors to the DBAs. The parameter is
the following:
Event = "4031 trace name
errorstack"
This will cause a dump of the oracle
state objects to occur when this error
is signalled. By looking in the dump
for
'Load=X' and then looking up a few
lines for 'name=' you can often tell
whether an object was being loaded
into the shared pool when this error
occurred. If an object was being
loaded then it is likely that this load
is the cause of the problem and the
Object should be 'kept' in the shared
pool. The object being loaded is the
object printed after the 'name='.
iii) X$KSMLRU
There is a fixed table called
X$KSMLRU that tracks allocations in
the shared pool that cause other
objects in the shared pool to be aged
out. This fixed table can be used to
identify what is causing the large
allocation. The columns of this
fixed table are the following:
KSMLRCOM - allocation comment
that describes the type of allocation.
If this comment is something like
'MPCODE' or 'PLSQL%' then there is a
large PL/SQL object being loaded into
the shared pool. This PL/SQL object
will need to be 'kept' in the shared
pool.
If this comment is 'kgltbtab' then the
allocation is for a dependency table
in the library cache. This is only a
problem when several hundred users
are logged on using distinct user ids.
The solution in this case is to use
fully qualified names for all table
references. This problem will not
occur in 7.1.3 or later.
If you are running MTS and the
comment is something like 'Fixed
UGA' then the problem is that the
init.ora parameter
'open_cursors' is set too high.
KSMLRSIZ - amount of contiguous
memory being allocated. Values over
around 5K start to be a problem,
values over 10K are a serious
problem, and values over 20K are
very serious problems. Anything less
then 5K should not be a problem.
KSMLRNUM - number of objects that
were flushed from the shared pool in
order allocate the memory.
KSMLRHON - The name of the object
being loaded into the shared pool if
the object is a PL/SQL object or a
cursor.
KSMLROHV - hash value of object
being loaded
KSMLRSES - SADDR of the session
that loaded the object.
The advantage of X$KSMLRU is that
it allows you to identify problems
with fragmentation that are effecting
performance,
but that are not bad enough to be
causing ORA-4031 errors to be
signalled. If a lot of objects are being
periodically flushed from the shared
pool then this will cause response
time problems and will likely cause
library cache latch contention
Problems when the objects are
reloaded into the shared pool.
One unusual thing about the
X$KSMLRU fixed table is that the
contents of the fixed table are erased
whenever someone selects from the
fixed table. This is done since the
fixed table stores only the largest
allocations that have occurred. The
values are reset after being selected
so that subsequent large allocations
can be noted even if they were not
quite as large as others that occurred
previously. Because of this resetting,
the output of selecting from this
table should be carefully noted
Since it cannot be reselected if it is
forgotten. Also you should take care
that there are not multiple people on
one database that select from this
table because only one of them will
select the real data.
Technical Reports Compendium,
Volume I, 1996 Shared Pool Internals
To monitor this fixed table just runs
the following:
select * from X$KSMLRU where KSMLRSIZ > 5000;
ACTION
i) KEEPING OBJECTS
The primary source of problems is
large PL/SQL objects. The means of
correcting these errors is to 'keep”
large PL/SQL objects in the shared
pool at startup time. This will load
the objects into the shared pool and
will make sure that the objects are
never aged out of the shared pool. If
the objects are never aged out then
there will not be a problem with
trying to load them and not having
enough memory.
Objects are 'kept' in the shared pool
using the dbms_shared_pool package
that is defined in the dbmspool.sql
file. For example:
exec dbms_shared_pool.keep('SYS.STANDARD');
All large packages that are shipped
should be 'kept' if the customer uses
PL/SQL. This includes 'STANDARD',
'DBMS_STANDARD', and 'DIUTIL'.
All large customer packages should
also be marked 'kept'.
One restriction on the 'keep'
procedure is that it only works on
packages. If the customer has large
procedures or large anonymous
blocks, then these will need to be put
into packages and marked kept.
You can determine what large stored
objects are in the shared pool by
selecting from the
V$DB_OBJECT_CACHE fixed view. This
will also tell you which objects have
been marked kept. This can be done
with the following query:
select * from V$DB_OBJECT_CACHE
where sharable_mem > 10000;
Note that this query will not catch
PL/SQL objects that are only rarely
used and therefore the PL/SQL object
is not currently
loaded in the shared pool.
To determine what large PL/SQL
objects are currently loaded in the
shared pool, are not marked ‘kept’,
and therefore may cause a problem,
execute the following:
select name, sharable_mem
from V$DB_OBJECT_CACHE
where sharable_mem > 10000
and (type = 'PACKAGE' or type = 'PACKAGE
BODY' or type = 'FUNCTION'
or type = 'PROCEDURE')
and kept = 'NO';
ii) USE BIND VARIABLES
Another thing that can be done to
reduce the amount of fragmentation
is to reduce or eliminate the number
of SQL statements in the shared pool
that are duplicates of each other
except for a constant that is
embedded in the statement. The
statements should be replaced with
one statement that uses a bind
variable instead of a constant.
For example:
select * from emp where empno=1;
select * from emp where empno=2;
select * from emp where empno=3;
Should all be replaced with:
select * from emp where empno=:1;
You can identify statements that
potentially fall into this class with a
query like the following:
select substr(sql_text, 1, 30) sql, count(*)
copies
from v$sqlarea
group by substr(sql_text, 1, 30)
having count(*) > 3;
iii) MAX BIND SIZE
It is possible for a sql statement to
not be shared because the max bind
variable lengths of the bind variables
in the statement
do not match. This is automatically
taken care of for precompiler
programs and forms programs, but
could be a problem for programs that
directly use OCI. The bind call in OCI
takes two arguments, one is the max open anon;
loop
length of the value, and the other is fetch anon into addr, hash;
a pointer to the actual length. If the exit when anon%notfound;
dbms_shared_pool.keep(addr || ',' ||
current length is always passed in as to_char(hash), 'C');
the max length instead of the max end loop;
end;
possible length for the variable, then
this could cause the sql statement
not to be shared.
To identify statements that might Initialization Parameters
potentially have this problem
execute the following statement: The following Oracle initialization
select sql_text, version_count from v$sqlarea parameters have an important
where version_count > 5; impact on library cache and shared
iv) ELIMINATING LARGE ANONYMOUS pool performance.
PL/SQL
Large anonymous PL/SQL blocks  _KGL_BUCKET_COUNT
should be turned into small  _KGL_LATCH_COUNT
anonymous PL/SQL blocks that call
packaged functions. The  cursor_sharing
packages should be 'kept' in memory.  shared_pool_size
This includes anonymous PL/SQL
 shared_pool_reserved_size
blocks that are used for trigger
definitions. Large anonymous blocks  shared_pool_reserved_min_all
can be identified with the following oc
query:  large_pool_size
select sql_text from v$sqlarea
where command_type=47 -- command type for  large_pool_min_alloc
anonymous block
and length(sql_text) > 500;  parallel_min_message_pool
Note that this query will not catch  backup_io_slaves
PL/SQL blocks that are only rarely  temporary_table_locks
used and therefore the PL/SQL block
is not currently loaded in the shared  dml_locks
pool.  sequence_cache_entries
Another option that can be used
 row_cache_cursors
when an anonymous block cannot be
turned into a package is to mark the  max_enabled_roles
anonymous block with some string so  mts_dispatchers
that it can be identified in
 mts_max_dispatchers
v$sqlarea and marked 'kept'.
For example, instead of using  mts_servers
declare x number;
begin x := 5; end;  mts_max_servers
one can use:
declare /* KEEP_ME */ x number; begin x := 5;  cursor_space_for_time
end;

You can then use the following SUMMARY –

procedure to select these statements
out of the shared pool and mark Here I try to provide some general
them 'kept' using the information regarding shared pool
dbms_shared_pool.keep package. and some internal information
declare
regarding memory structure, I hope
/* DONT_KEEP_ME */ this information will useful for DBA’s,
addr varchar2(10); I also try to provide some information
hash number;
cursor anon is related to application user relation to
select address, hash_value application point of views.
from v$sqlarea
where command_type = 47 -- command type for
anonymous block References
and sql_text like '% KEEP_ME %'
and sql_text not like '%DONT_KEEP_ME%'; 1. "Oracle Internals" Stev Adams
begin 2. Metalink.oracle.com
3. Quest pipeline.