. Shared Pool概述

在之前的blog对的内存也做了一个概述，参考：

Oracle内存架构详解

在网上搜到一篇介绍shared pool非常详细的pdf资料。 原文链接以找不到，但还是要感谢作者Kamus的辛勤劳动。

结合Kamus的pdf和csdn网友的blog，重新整理了一下，链接如下：

IINTRODUCT IION

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.

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

2.1 Shared and Private SQL Area

A shared SQL area containsthe parse treeandexecution planfor 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 containsdata 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:

(1)The persistent area containsbind 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), andother 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.

(2)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 multithreaded 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.

/* Formatted on 2011/6/21 10:18:48 (QP5 v5.163.1008.3004) */

SELECT*

FROMX$KSMSS

WHEREKSMSSNAM='sql_area'ANDKSMSSLEN<>0;

2.2 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 Cachewhich is suppose to be allocated to a particular Oracle Instance。

E.g.

/* Formatted on 2011/6/21 10:39:11 (QP5 v5.163.1008.3004) */

SELECT*

FROMX$KSMSS

WHEREKSMSSNAMLIKE'PL/SQL%'ANDKSMSSLEN<>0;

PL/SQL MPCODEstands for machine dependent pseudocode.

PL/SQL DIANAstands for the PL/SQL code size in the shared pool at runtime.

2.3Library 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 theheap manager (KGH) to allocate it. The library cacheconsists 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).

KGH Heap Manager说明：

Shared pool和PGA都是由一个Oracle的内存管理器来管理，我们称之为KGH heap manager。Heap Manager不是一个进程，而是一串代码。Heap Manager主要目的就是满足server进程请求memory的时候分配内存或者释放内存。Heap Manager在管理PGA的时候，Heap Manager需要和来打交道来分配或者回收内存。但是呢，在shared pool中，内存是预先分配的，Heap Manager管理所有的空闲内存。

当某个进程需要分配shared pool的内存的时候，Heap Manager就满足该请求，Heap Manager也和其他ORACLE模块一起工作来回收shared pool的空闲内存。

2.4Library Cache Manager (Hash Table and Hash Bucket)

Library cache Manager可以看做是Heap Manager的客户端，因为library cache manager是根据Heap Manager来分配内存从而存放library cache objects。Library cache Manager控制所有的library cache object，包括package/procedure, cursor, trigger等等。

Library cache是由一个hash table组成，这个hash table又由hash bucket组成的数组构成，每个hash bucket又是由一些相互指向的library cache handle所组成，library cache object handle就指向具体的library cache object以及一些引用列表。

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 wherethe "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 willapply

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.

2.5 Library Cache Handle

A library cache handles points to a library cache object.It contains the name of the library object, the namespace, a timestamp,

a reference list, a list of locks locking the object and a list of pins

pinning the object. Each object is uniquely identified by the name within its namespace.

对Library cache中所有对象的访问是通过利用library cache handle来实现的，也就是说我们想要访问library cache object，我们必须先找到library cache handle。Library cache handle指向library cache object,它包含了library object的名字，命名空间，时间戳，引用列表，lock对象以及pin对象的列表信息等等。

Library cache handle也被library cache用来记录哪个用户在这个这个handle上有lock，或者是哪个用户正在等待获得这个lock。那么这里我们也知道了library cache lock是发生在handle上的。

当一个进程请求library cache object, library cache manager就会应用一个hash，从而得到一个hash值，根据相应的hash值到相应的hash bucket中去寻找。

这里的hash算法原理与buffer cache中快速定位block的原理是一样的。如果library cache object在内存中，那么这个library cache handle就会被找到。有时候，当shared pool不够大，library cache handle会保留在内存中，然而library cache heap由于内存不足被age out，这个时候我们请求的object heap就会被重载。最坏的情况下，library cache handle在内存中没有找到，这个时候就必须分配一个新的library cache handle，同时object heap也会被加载到内存中。

查看namespace:

SYS@anqing2(rac2)>select namespace from v$librarycache;

NAMESPACE

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

SQL AREA

TABLE/PROCEDURE

BODY

TRIGGER

INDEX

CLUSTER

OBJECT

PIPE

SOURCE

RESOURCE

JAVA DATA

在AWR里有关Library Cache Activity的统计信息：

Library Cache Object是由一些独立的heap所组成，Library cache handle指向Library cache Object，其实handle是指向第一个heap,这个heap我们就称之为heap 0。Heap 0记录了指向其他heap的指针信息。

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 namespaces:one

namespace holds all namespaces depended on PL/SQL objects, one for

package bodies and table bodies, one for shared cursors; one for

triggers; one for indexes; and one for clusters.The namespace describes the type of an item kept in the library cache.

The name consists of the object owner name, the object name, the database link name, and the database link owner name.A comprehensive list can be viewed from v$librarycache.

A

handle can be freed if there are no current references to it and it has

not been expressly marked to be kept. We use this to determine when a

handle should be unpinned in memory.

2.6Library cache lock/pin

Library cache lock/pin是用来控制对library cache object的并发访问的。Lock管理并发，pin管理一致性，lock是针对于library cache handle,而pin是针对于heap。

当我们想要访问某个library cache object，我们首先要获得这个指向这个object的handle的lock，获得这个lock之后我们就需要pin住指向这个object的heap。

当我们对包，存储过程，函数，视图进行编译的时候，Oracle就会在这些对象的handle上面首先获得一个library cache lock，然后再在这些对象的heap上获得pin，这样就能保证在编译的时候其它进程不会来更改这些对象的定义，或者将对象删除。

当一个session对SQL语句进行硬解析的时候，这个session就必须获得library cache lock，这样其他session就不能够访问或者更改这个SQL所引用的对象。如果这个等待事件花了很长时间，通常表明共享池太小(由于共享池太小，需要搜索free的chunk，或者将某些可以被移出的object page out，这样要花很长时间)，当然了，也有可能另外的session正在对object进行修改(比如split分区),而当前session需要引用那个table，那么这种情况下我们必须等另外的session进行完毕。

Library Cache lock有3中模式：

(1)Share(S):当读取一个library cache object的时候获得

(2)Exclusive(X):当创建/修改一个library cache object的时候获得

(3)Null(N)：用来确保对象依赖性

比如一个进程想要编译某个视图，那么就会获得一个共享锁，如果我们要create/drop/alter某个对象，那么就会获得exclusive lock。Null锁非常特殊，我们在任何可以执行的对象(cursor，function)上面都拥有NULL锁，我们可以随时打破这个NULL锁，当这个NULL锁被打破了,就表示这个对象被更改了，需要从新编译。

NULL锁主要的目的就是标记某个对象是否有效。比如一个SQL语句在解析的时候获得了NULL锁，如果这个SQL的对象一直在共享池中，那么这个NULL锁就会一直存在下去，当这个SQL语句所引用的表被修改之后，这个NULL锁就被打破了，因为修改这个SQL语句的时候会获得Exclusive锁，由于NULL锁被打破了，下次执行这个SQL的时候就需要从新编译。

Library Cache pin有2种模式：

(1)Share(S):读取object heap

(2)Exclusive(X)： 修改object heap

当某个session想要读取object heap，就需要获得一个共享模式的pin，当某个session想要修改object heap，就需要获得排他的pin。当然了在获得pin之前必须获得lock。

在Oracle10gR2中，library cache pin被library cache mutex所取代。

2.7Library cache Latch

Library cache latch用来控制对library cache object的并发访问。前面已经提到，我们要访问library cache object之前必须获得library cache lock，lock不是一个原子操作(原子操作就是在操作程中不会被打破的操作，很明显这里的lock可以被打破), Oracle为了保护这个lock，引入了library cache latch机制，也就是说在获得library cache lock之前，需要先获得library cache latch，当获得library cache lock之后就释放library cache latch。

如果某个library cache object没有在内存中，那么这个lock就不能被获取，这个时候需要获得一个library cache load lock latch，然后再获取一个library cache load lock,当load lock获得之后就释放library cache load lock latch。

library cache latch受隐含参数_KGL_LATCH_COUNT的控制，默认值为大于等于系统中CPU个数的最小素数，但是Oracle对其有一个硬性限制，该参数不能大于67。

注意：我们去查询_kgl_latch_count有时候显示为0,这是一个bug。

Oracle利用下面算法来确定library cache object handle是由哪个子latch来保护的：

latch# = mod(bucket#, #latches)

也就是说用哪个子latch去保护某个handle是根据那个handle所在的bucket号，以及总共有多少个子latch来进行hash运算得到的。

有关其他内容，参考：

Oracle Latch说明

Oracle Mutex机制说明

锁死锁阻塞Latch等待详解

三.Dictionary Cache

Table definition against which an application user suppose to do a query,it include table’s associated Index and Columns and privilege information regarding table as we as columns.

/* Formatted on 2011/6/21 15:01:52 (QP5 v5.163.1008.3004) */

SELECT*

FROMX$KSMSS

WHEREKSMSSNAMLIKE'PL/SQL%'ANDKSMSSLEN<>0;

四.Control Structure

This contain the information regarding InternalLatch and Locks (Data Structure),it also contain buffer header, the process session and transaction arrays.

The

size of these arrays depends on the setting of Initialisation parameter

of Init.ora file and can’t be changed without shutting down the

database.

4.1 Shared Pool Chunks

Have close looks of Shared Pool, For that we should have a close look atx$ksmsp each row in this table shows a chunk of shared pool :

SQL>select*fromX$ksmsp

When

each shared pool chunk is 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.

The columnKSMCHCLSrepresent the class, there are basically four type of classes:

Freeabl:can be freed only contain the objects needed for the session call.

Free:free and not contained by valid object.

Recr:contain by temporary objects.

Perm:contained by the permanent object.

/* Formatted on 2011/6/21 16:14:50 (QP5 v5.163.1008.3004) */

SELECTKSMCHCLSCLASS,

COUNT(KSMCHCLS)NUM,

SUM(KSMCHSIZ)SIZ,

TO_CHAR(((SUM(KSMCHSIZ)/COUNT(KSMCHCLS)/1024)),'999,999.00')

||'k'

"AVG SIZE"

FROMX$KSMSP

GROUPBYKSMCHCLS;

注意：

在生产库上查询X$KSMSP时，要看下系统的繁忙或者说是负载高低，因为可能会导致db hang住。

So the overall summary :

/* Formatted on 2011/6/21 16:06:38 (QP5 v5.163.1008.3004) */

SELECTKSMCHCOMname,

COUNT(KSMCHCOM),

SUM(DECODE(KSMCHCLS,'recr',KSMCHSIZ))RECREATABLE,

SUM(DECODE(KSMCHCLS,'freeabl',KSMCHSIZ))FREEABLE

FROMx$ksmsp

GROUPBYKSMCHCOM;

4.2 LRU List

When a process starts it allocate some memory andwhen

it’ fails to allocated required memory, Then it try to remove chunk

containing recreatable object from shared pool to get the desired size

of chunk,and removing these object from memory is based on LRU(Least Recent Used)means

those objects that are frequently pinned kept in the memory and those

are unpinned we generally remove those objects from the memory. Object

those required again known as transient and other known as recurrent.

ORA-04331

‘unable to allocate x bytes of shared pool’ when all the free memory

fully exhausted (Later we will discuss the shared pool fragmentation).

There

is one list maintained which known as Reserved List, it generally 5% of

the total size of Shared Pool and reserved size is defined by

SHARED_POOL_RESERVED_SIZE parameter in Init.ora parameter file.

With the help of v$shared_pool_reservedwe can see reserved size, here REQUEST_MISS shows the number of times the request miss for a large chunk.

4.3 SHARED_POOL size calculation

The

shared pool size is highly application dependent. To determine the

shared pool size for a production system it is generally necessary to

develop the application run it on a test environment (should be enough

like production system) get some test result and on the basis of that

calculate the shared pool size.There are some few step which we should consider while calculating the shared pool:

4.3.1 STORED OBJECTS

The

amount of shared pool that needs to be allocated for objects that are

stored in the database like packages and views is easy to measure.You can just measure their size directly with the following statement:

/* Formatted on 2011/6/21 16:32:28 (QP5 v5.163.1008.3004) */

SELECTSUM(sharable_mem)FROMV$DB_OBJECT_CACHE;

4.3.2 SQL

The

amount of memory needed to store sql statements in the shared pool is

more difficult to measure because of the needs of dynamic sql. If an

application hasno dynamic sqlthen the amount of memory can simply be measured after the application has run for a whileby just selecting it out of the shared pool as follows:

/* Formatted on 2011/6/21 16:34:02 (QP5 v5.163.1008.3004) */

SELECTSUM(sharable_mem)FROMv$sqlarea;

If the application has a moderate or large amount of dynamic sqllike

most applications do, then a certain amount of memory will be needed

for the shared sql plus more for thedynamic sql. Sufficient memory

should be allocated so that the dynamic sql does not age the shared sql

out of the shared pool.

Approximated memory could be calculated by the following:

/* Formatted on 2011/6/21 16:35:06 (QP5 v5.163.1008.3004) */

SELECTSUM(sharable_mem)

FROMv$sqlarea

WHEREexecutions>5;

The remaining memory in v$sqlarea is for dynamic sql.

4.3.3 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:

/* Formatted on 2011/6/21 16:36:55 (QP5 v5.163.1008.3004) */

SELECTSUM(250* users_opening)FROMv$sqlarea;

In a test system you can measure itby selecting the number of open cursors for a test user and multiplying by the total number of users:

/* Formatted on 2011/6/21 16:37:20 (QP5 v5.163.1008.3004) */

SELECT250*VALUEbytes_per_user

FROMv$sesstat s,v$statname n

WHEREs.statistic#=n.statistic#

ANDn.name='opened cursors current'

ANDs.sid=130;

-- replace 130 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.

4.3.4 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:

/* Formatted on 2011/6/21 16:39:31 (QP5 v5.163.1008.3004) */

SELECTVALUEsess_mem

FROMv$sesstat s,v$statname n

WHEREs.statistic#=n.statistic#

ANDn.name='session uga memory'

ANDs.sid=23;

-- replace 23 with session id of user being measured

A more conservative value to use is themaximum session memory thatwas ever allocated by the user:

/* Formatted on 2011/6/21 16:40:22 (QP5 v5.163.1008.3004) */

SELECTVALUEsess_max_mem

FROMv$sesstats,v$statname n

WHEREs.statistic#=n.statistic#

ANDn.name='session uga memory max'

ANDs.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:

/* Formatted on 2011/6/21 16:40:56 (QP5 v5.163.1008.3004) */

SELECTSUM(VALUE)all_sess_mem

FROMv$sesstat s,v$statname n

WHEREs.statistic#=n.statistic#ANDn.name='session uga memory max';

4.3.5 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)

/* Formatted on 2011/6/21 16:46:24 (QP5 v5.163.1008.3004) */

SETSERVEROUTPUTON;

DECLARE

object_memNUMBER;

shared_sqlNUMBER;

cursor_memNUMBER;

mts_memNUMBER;

used_pool_sizeNUMBER;

free_memNUMBER;

pool_sizeVARCHAR2(100);

BEGIN

-- Stored objects (packages, views)

SELECTSUM(sharable_mem)INTOobject_memFROMv$db_object_cache;

-- Shared SQL -- need to have additional memory if dynamic SQL used

SELECTSUM(sharable_mem)INTOshared_sqlFROMv$sqlarea;

-- User Cursor Usage -- run this during peak usage

SELECTSUM(250* users_opening)INTOcursor_memFROMv$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.

SELECTSUM(VALUE)

INTOmts_mem

FROMv$sesstat s,v$statname n

WHEREs.statistic#=n.statistic#ANDn.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.

SELECTbytes

INTOfree_mem

FROMv$sgastat

WHEREname='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_mem));

-- For MTS add mts contribution also.

-- used_pool_size := round(1.3*(object_mem+shared_sql+cursor_mem+mts_mem));

SELECTVALUE

INTOpool_size

FROMv$parameter

WHEREname='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 poolutilization (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 thatthe 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.

FromV$SGASTATand V$SQLAREA we will get this information.

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.

/* Formatted on 2011/6/22 0:16:26 (QP5 v5.163.1008.3004) */

CREATETABLETEMP_SQL_REPORT

AS

(SELECTB.USERNAME,

A.SQL_TEXT,

A.EXECUTIONS,

A.LOADS,

A.USERS_EXECUTING,

A.SHARABLE_MEM,

A.PERSISTENT_MEM,

A.RUNTIME_MEM

FROMV$SQLAREAA,DBA_USERS B

WHEREA.PARSING_USER_ID=B.USER_ID)

查看report：

/* Formatted on 2011/6/22 0:19:04 (QP5 v5.163.1008.3004) */

SELECTUsername,

SUM(SHARABLE_MEM),

SUM(PERSISTENT_MEM),

SUM(RUNTIME_MEM)

FROMtemp_sql_report

GROUPBYusername;

This

output of this summary report shows here the sql area used by each

user. Now try to analyse the summary report, if a particular hold a

large amount of memory then that means the sql’s used by that user are

bad every time it generate different execution plan for similar kind of

queries, the coding produce a large number of nonreusable sql area.

Now

we can generate an another where we will shown the actual sql statement

executed by a user and how many time a sql statement execute by a user ,what amount of memory that sql statement took to execute the statement.

/* Formatted on 2011/6/22 0:25:30 (QP5 v5.163.1008.3004) */

SELECTusernameusers,

sql_text,

Executions,

loads,

users_executing,

sharable_mem,

persistent_mem

FROMtemp_sql_report b

WHEREb.usernameLIKEUPPER('%&user_name%')

ORDERBY3DESC,1;

5.1 SQL

5.1.1Literal 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 version FROM app_version WHERE version>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.

5.1.2 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 get s performed.

5.1.3 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.

5.1.4 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'.

5.1.5 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

5.1.6 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 it is truly identical to the statement

currently being parsed. Hence high version counts are best avoided by:

Standardising

the maximum bind lengths specified by the client Avoid using identical

SQL from lots of different schemas, which use private objects.

Eg:

SELECT xx FROM MYTABLE;

where eachuser has their own MYTABLE

Setting _SQLEXEC_PROGRESSION_COST to '0' in Oracle 8.1

5.1.7 Library Cache and Shared Pool latches

The shared pool latch is used to protect critical operations when allocating and freeing memory in the shared pool.

The

library cache latches (and the library cache pin latch in Oracle 7.1)

protect operations within the library cache itself. All of these latches

are potential points of contention. The number of latch gets occurring

is influenced directly by the amount activity in the shared pool,

especially parse operations. Anything that can minimise the number of

latch gets and indeed the amount of activity in the shared pool is

helpful to both performance and scalability.

5.1.8 Literal SQL versus Shared SQL

To give a balanced picture this short section describes the benefits of both literal SQL and sharable SQL.

5.1.8.1 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;

For the first statementthe

CBO could use histogram statistics that have been gathered to decide if

it would be fastest to do a full table scan of ORDERS or to use an

index scan on TOTAL_COST (assuming there is one).

In the second statementCBO

has no idea what percentage of rows fall below ":bindA" as it has no

value for this bind variable to determine an execution plan . Eg:

":bindA" could be 0.0 or 99999999999999999.9

There

could be orders of magnitude difference in the response time between

the two execution paths so using the literal statement is preferable if

you want CBO to work out the best execution plan for you. This is

typical of Decision Support Systems where there may not be any

'standard' statements, which are issued repeatedly so the chance of

sharing a statement is small. Also the amount of CPU spent on parsing is

typically only a small percentage of that used to execute each

statement so it is probably more important to give the optimiser as much

information as possible than to minimise parse times.

5.1.8.2 Sharable SQL

If

an application makes use of literal (unshared) SQL then this can

severely limit scalability and thr oughput. 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

5.1.9 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.

5.1.10 Eliminating Liter al 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:

/* Formatted on 2011/6/22 10:51:28 (QP5 v5.163.1008.3004) */

SELECTSUBSTR(sql_text,1,40)"SQL",COUNT(*),SUM(executions)"TotExecs"

FROMv$sqlarea

WHEREexecutions<5

GROUPBYSUBSTR(sql_text,1,40)

HAVINGCOUNT(*)>30

ORDERBY2;

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.

5.1.11 Performance Effects

Oracle performance can be severely compromised by large volumes of literal SQL. Some of the symptoms that may be noticed are:

(1).System is CPU bound and exhibits an insatiable appetite for CPU.

(2).System appears to periodically “hang” after some period of normal operation.

(3).Latch contention on shared pool and library cache latches.

(4).Increasing the shared pool size delays the problem but it re-occurs more severely.

5.1.12Identifying 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.

5.1.13 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.

/* Formatted on 2011/6/22 10:56:34 (QP5 v5.163.1008.3004) */

SELECTnamespace,(100* gethitratio)hit_ratioFROMv$librarycache;

The “SQL AREA” namespace will be the one affected by literal SQL.

5.1.14 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.

/* Formatted on 2011/6/22 10:58:35 (QP5 v5.163.1008.3004) */

SELECT100*(1-A.hard_parses/B.executions)noparse_ratio

FROM(SELECTVALUEhard_parses

FROMv$sysstat

WHEREname='parse count (hard)')A,

(SELECTVALUEexecutions

FROMv$sysstat

WHEREname='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.

5.1.15 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.

/* Formatted on 2011/6/22 11:01:08 (QP5 v5.163.1008.3004) */

SELECTsid,event,namelatch

FROMv$session_wait w,v$latch l

WHEREw.event='latch free'ANDl.latch#=w.p2ANDl.nameIN('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.

5.1.16 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.

/* Formatted on 2011/6/22 11:04:55 (QP5 v5.163.1008.3004) */

SELECTS.sql_text

FROMv$sql S,

(SELECTSUBSTR(sql_text,1,&&size)sqltext,COUNT(*)

FROMv$sql

GROUPBYSUBSTR(sql_text,1,&&size)

HAVINGCOUNT(*)>10)D

WHERESUBSTR(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.

5.2 Memory Fragment ation

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 anORA-4031 out of shared memory error.

Oracle ORA-04031错误说明

5.2.1 DIAGNOSIS

(1)ORA-4031 ERROR

One way to diagnose that this is happening is to look for ORA-4031 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.

(2)INIT.ORAPARAMETER

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='.

(3)X$KSMLRU

There is a fixed table calledX$KSMLRUthattracks 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 - SADDRof the session that loaded the object.

The advantage ofX$KSMLRUis 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.

To monitor this fixed table just runs the following:

select * from X$KSMLRU where KSMLRSIZ >5000;

5.2.2 ACTION

(1)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 packagethat 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:

/* Formatted on 2011/6/22 13:13:23 (QP5 v5.163.1008.3004) */

SELECT*

FROMV$DB_OBJECT_CACHE

WHEREsharable_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:

/* Formatted on 2011/6/22 13:14:25 (QP5 v5.163.1008.3004) */

SELECTname,sharable_mem

FROMV$DB_OBJECT_CACHE

WHEREsharable_mem>10000

AND(TYPE='PACKAGE'

ORTYPE='PACKAGE BODY'

ORTYPE='FUNCTION'

ORTYPE='PROCEDURE')

ANDkept='NO';

(2)USE BIND VARIABLES

Another thing that can be done to reduce the amount of fragmentation is toreduce or eliminate the number of SQL statements in the shared poolthat

are duplicates of each other except for a constant that is embedded in

the statement. The statements should be replaced with one statement thatuses 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:

/* Formatted on 2011/6/22 13:18:04 (QP5 v5.163.1008.3004) */

SELECTSUBSTR(sql_text,1,30)sql,COUNT(*)copies

FROMv$sqlarea

GROUPBYSUBSTR(sql_text,1,30)

HAVINGCOUNT(*)>3;

(3)MAXBINDSIZE

It is possible for a sql statement to not be sharedbecause 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 length of the value, and the other is a pointer to the actual length.If the current length is always passed in as the max length instead of the max possible length for the variable,then this could cause the sql statement not to be shared.

To identify statements that might potentially have this problem execute the following statement:

/* Formatted on 2011/6/22 13:22:20 (QP5 v5.163.1008.3004) */

SELECTsql_text,version_count

FROMv$sqlarea

WHEREversion_count>5;

(4)ELIMINATING LARGE ANONYMOUS PL/SQL

Large

anonymous PL/SQL blocks should be turned into small anonymous PL/SQL

blocks that call packaged functions. The packages should be 'kept' in

memory.This includes anonymous PL/SQL blocks that are used for trigger definitions. Largeanonymous blocks can be identifie d with the following query:

/* Formatted on 2011/6/22 13:25:22 (QP5 v5.163.1008.3004) */

SELECTsql_text

FROMv$sqlarea

WHEREcommand_type=47-- command type for anonymous block

ANDLENGTH(sql_text)>500;

Note that this query will not catch PL/SQL blocks that are only rarely used andtherefore the PL/SQL block is not currently loaded in the shared pool.

Another

option that can be used when an anonymous block cannot be turned into a

package is to mark the anonymous block with some string so that it can

be identified in v$sqlarea and marked 'kept'.

For example, instead of using

/* Formatted on 2011/6/22 13:33:20 (QP5 v5.163.1008.3004) */

DECLARE

xNUMBER;

BEGIN

x:=5;

END;

one can use:

/* Formatted on 2011/6/22 13:33:34 (QP5 v5.163.1008.3004) */

DECLARE/* KEEP_ME */

xNUMBER;

BEGIN

x:=5;

END;

You

can then use the following procedure to select these statements out of

the shared pool and mark them 'kept' using the dbms_shared_pool.keep

package.

/* Formatted on 2011/6/22 13:34:55 (QP5 v5.163.1008.3004) */

DECLARE

/* DONT_KEEP_ME */

addrVARCHAR2(10);

hashNUMBER;

CURSORanon

IS

SELECTaddress,hash_value

FROMv$sqlarea

WHEREcommand_type=47-- command type for anonymous block

ANDsql_textLIKE'% KEEP_ME %'

ANDsql_textNOTLIKE'%DONT_KEEP_ME%';

BEGIN

OPENanon;

LOOP

FETCHanon

INTOaddr,hash;

EXITWHENanon%NOTFOUND;

DBMS_SHARED_POOL.keep(addr ||','||TO_CHAR(hash),'C');

ENDLOOP;

END;

To create DBMS_SHARED_POOL,run the DBMSPOOL.SQL script.The PRVTPOOL.PLB script is automatically executed after DBMSPOOL.SQL

runs. These scripts are not run by as part of standard database

creation.

5.3 Initialization Parameters

The following Oracle initialization parameters have an important impact on library cache and shared pool performance.

(1)._KGL_BUCKET_COUNT

(2)._KGL_LATCH_COUNT

(3).cursor_sharing

(4).shared_pool_size

(5).shared_pool_reserved_size

(6).shared_pool_reserved_min_alloc

(7).large_pool_size

(8).large_pool_min_alloc

(9).parallel_min_message_pool

(10).backup_io_slaves

(11).temporary_table_locks

(12).dml_locks

(13).sequence_cache_entries

(14).row_cache_cursors

(15).max_enabled_roles

(16).mts_dispatchers

(17).mts_max_dispatchers

(18).mts_servers

(19).mts_max_servers

(20).cursor_space_for_time