Oracle内存详解之三 Shared pool 共享池

最新推荐文章于 2024-08-20 12:47:56 发布

mjj291268154

最新推荐文章于 2024-08-20 12:47:56 发布

阅读量1.4k

点赞数

转自: http://blog.csdn.net/zengmuansha/article/details/6757701

一. Shared Pool 概述

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

Oracle 内存架构详解

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

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

http://blog.csdn.net/robinson1988/archive/2010/11/26/6037925.aspx

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 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 has a persistent area and a runtime area:

（1）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.

（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 *

FROM X$KSMSS

WHERE KSMSSNAM = 'sql_area' AND KSMSSLEN <> 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 Cache which 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 *

FROM X$KSMSS

WHERE KSMSSNAM LIKE 'PL/SQL%' AND KSMSSLEN <> 0;

PL/SQL MPCODE stands for machine dependent pseudocode.

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

2.3 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).

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.4 Library 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 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.

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

JAVA SOURCE

JAVA 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.6 Library 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.7 Library 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运算得到的。

三. 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 *

FROM X$KSMSS

WHERE KSMSSNAM LIKE 'PL/SQL%' AND KSMSSLEN <> 0;

四. Control Structure

This contain the information regarding Internal Latch 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 at x$ksmsp each row in this table shows a chunk of shared pool :

SQL>select * from X$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 column KSMCHCLS represent 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) */

SELECT KSMCHCLS CLASS,

COUNT (KSMCHCLS) NUM,

SUM (KSMCHSIZ) SIZ,

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

|| 'k'

"AVG SIZE"

FROM X$KSMSP

GROUP BY KSMCHCLS;

注意：

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

So the overall summary :

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

SELECT KSMCHCOM name,

COUNT (KSMCHCOM),

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

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

FROM x$ksmsp

GROUP BY KSMCHCOM;

4.2 LRU List

When a process starts it allocate some memory and when 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_reserved we 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) */

SELECT SUM (sharable_mem) FROM V$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 has no dynamic sql then the amount of memory can simply be measured after the application has run for a while by just selecting it out of the shared pool as follows:

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

SELECT SUM (sharable_mem) FROM v$sqlarea;

If the application has a moderate or large amount of dynamic sql like 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) */

SELECT SUM (sharable_mem)

FROM v$sqlarea

WHERE executions > 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) */

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:

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

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 = 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) */

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:

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

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:

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

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

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) */

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_mem));

-- For MTS add mts contribution also.

-- used_pool_size := round(1.3*(object_mem+shared_sql+cursor_mem+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 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 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.

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) */

CREATE TABLE TEMP_SQL_REPORT

(SELECT B.USERNAME,

A.SQL_TEXT,

A.EXECUTIONS,

A.LOADS,

A.USERS_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)

查看report：

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

SELECT Username,

SUM (SHARABLE_MEM),

SUM (PERSISTENT_MEM),

SUM (RUNTIME_MEM)

FROM temp_sql_report

GROUP BY username;

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) */

SELECT username users,

sql_text,

Executions,

loads,

users_executing,

sharable_mem,

persistent_mem

FROM temp_sql_report b

WHERE b.username LIKE UPPER ('%&user_name%')

ORDER BY 3 DESC, 1;

5.1 SQL

5.1.1 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 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 statement the 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 statement CBO 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) */

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

FROM v$sqlarea

WHERE executions < 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.

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

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) */

SELECT namespace, (100 * gethitratio) hit_ratio FROM v$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) */

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.

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) */

SELECT sid, event, name latch

FROM v$session_wait w, v$latch l

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.

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) */

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)

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

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

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

（3）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.

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

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

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:

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

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

（2）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:

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

SELECT SUBSTR (sql_text, 1, 30) sql, COUNT (*) copies

FROM v$sqlarea

GROUP BY SUBSTR (sql_text, 1, 30)

HAVING COUNT (*) > 3;

（3）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 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) */

SELECT sql_text, version_count

FROM v$sqlarea

WHERE version_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. Large anonymous blocks can be identifie d with the following query:

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

SELECT sql_text

FROM v$sqlarea

WHERE command_type = 47 -- command type for anonymous block

AND LENGTH (sql_text) > 500;

Note that this query will not catch PL/SQL blocks that are only rarely used and therefore 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

x NUMBER;

BEGIN

x := 5;

END;

one can use:

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

DECLARE /* KEEP_ME */

x NUMBER;

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 */

addr VARCHAR2 (10);

hash NUMBER;

CURSOR anon

SELECT address, hash_value

FROM v$sqlarea

WHERE command_type = 47 -- command type for anonymous block

AND sql_text LIKE '% KEEP_ME %'

AND sql_text NOT LIKE '%DONT_KEEP_ME%';

BEGIN

OPEN anon;

LOOP

FETCH anon

INTO addr, hash;

EXIT WHEN anon%NOTFOUND;

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

END LOOP;

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