Keeping Large Objects in shared pool

Hi,
what is my doubt is the following mention objects
1) DBMS_Application_info
2) Trigger
3) Dbms_space_admin
4) DBMS_RCVCAT
5) DBMS_RCVMAN
6) DBMS_Shared_pool
7) dbms_standard
8) dbms_utility
9) dbms_backup_resotre
10) standard
the above mention object i keep in shared pool, IS it ok? or anythink peformance problems plz reply as soon as possible

hi,
Loading large objects is the primary source of fragmentations. Users' response time is affected because of the large number of small objects that need to be aged out from the shared pool to make room. To prevent these situations Keep these large or frequently required objects in the shared pool to make sure that they are never aged out of the shared pool.
thanking u

Similar Messages

Find out Large objects in Shared pool

Hi,
I am working on Oracle 10.2.0 and 11.2.0 databases.
Could you please give the sql to find out the Large objcts in Shared pool.
Thanks a lot

Hi;
I suggest please review:
Shared Pool script
Re: regarding shared pool
Regard
Helios

Shared pool issues

Hi,
In recent we are getting shared pool exhaust issue. I am interested to know which objects occupying more share pool.Do we have any queries which can show the most space occupied objects in shared pool
do we have any monitoring tools(or queries) using which we can findout once shared pool usage has gone to 70%.I guess OEM automatically alert this if we confgiure it for
I heard that "alter system flush share_pool" doesn't work properly.there is bug in that.After executing this also it wont release shared pool.Is it true ??
Thanks for your information.
Thanks
Anand

In recent we are getting shared pool exhaust issue. I am interested to know which objects occupying more share pool.Do we have any queries which can show the most space occupied objects in shared poolThis if V$DB_OBJECT_CACHE helps for this.
I heard that "alter system flush share_pool" doesn't work properly.there is bug in that.After executing this also it wont release shared pool.Is it true ??Not sure about the bug, do you have the bug number handy. Also, what do you mean by - "it wont release shared pool"...it doesn't release the entire memory allocated to shared pool.
Thanks
Chandra

Large Objects in Database?

Is there ever an arguement for keeping large objects (1-25 MB) inside the database, versus storing pointers to the files at locations outside?

Thank you for the reference. I reviewd these section on your suggestion but I guess I'm hoping for some empirical feedback ( I'm new t o Oracle Dbs). Blob vs. Bfile is the dilemma. The way I read it, the difference in storage location, and the BFILE read only restrictions. So deciding which datatype will be based upon machine conditions for the BFILE side; i.e. is the file server OS stable/accessible? how often would the BFILE date need to be rewritten vs. adding metadata to the BLOB? is it faster to rewrite the BFILE than the BLOB with the addtional metadata? I just don't have any experience to draw from and was looking for a general direction. Thanks for your time

Keeps an object in the shared pool

hello all
please tell me, when should we keep an object in the shared pool?how can we find out which should be kept in shared pool? please tell me in detail..........
thank you all in advance

mohammed_dba wrote:
hi dear,
please tell me how can find out which package is frequently pins? please give query for thatI guess you mean which packages are frequently accessed and are candidate for the pinning in the keep pool.
Use the following query:
SELECT substr(owner,1,10)||'.'||substr(name,1,35) "Object Name",
' Type: '||substr(type,1,12)||
' size: '||sharable_mem ||
' execs: '||executions||
' loads: '||loads||
' Kept: '||kept
FROM v$db_object_cache
WHERE type in ('TRIGGER','PROCEDURE','PACKAGE BODY','PACKAGE')
AND executions > 0
ORDER BY executions desc,
loads desc,
sharable_mem desc;Then check which objects have high value for the EXECS column. Also consult with your application developers to identify the frequently used code.
regards

What server side objects to pin in shared pool?

On the first invocation of Java-based image.process(...), processing can take up to 30 seconds. Second run takes less than a second, but a final invocation a few hours later is back to 30 seconds. My DBA suspects that the server side objects are cached in the shared pool by the time of the second invocation, and then flushed out by the time the code is run a few hours later.
We tried "pinning" ORDSYS.OrdImage pl/sql package in the shared pool using dbsm_shared_pool.keep , but no success. What are the the Java server-side objects referred to the Intermedia Java Client that really does the work when the client-side image.process(..) is executed?
Thanks,
Brandon

hi Mr.kesavan!
i tried .but i am getting some error.
when i give lookup (jndi) that time it is giving some error.
for example :
ic.lookup("Bean2");exactly this line i am getting some unmarshalling error.
Can u give me some sample code.?
thank u...
Shalinipriya.

Script to find the " List of objects to be pinned in the shared pool"

hi all,
please suggest me any script is there to find the recommended objects to be pinned in to shared pool.
Regards,
Vamsi.

I think the important question here is – do you really need to PIN objects? Are you facing any ORA-4031 errors?
Oracle would tell you to PIN packages such as STANDARD, DBMS_STANDARD, DBMS_UTILITY, DBMS_OUTPUT. It really depends on your application. So I am afraid there is no exact answer for that, but you can work with your application team to learn if there is some large object that is very frequently used that you might want to PIN.
I suggest that you check the larger objects from your SGA using the view v$db_object_cache that folks already pointed out checking the column SHARABLE_MEM.
You can refer to v$sql or v$sqlarea (which is a grouping of v$sql) to find the most executed stored procedures and packages and so on.
However, most of the problems shared pool problems I have faced were related to bad application coding - such as lack of bind variables - or shared pool undersized. Once those problems were fixed, I hardly had to PIN anything into the SGA.
Regards

Large shared pool

I am running a DW application on 11.2.0.1, linux, using AMM. We have 64G memory, of which 45G is (theoretically) allocated to ORACLE.
I have noticed that the PGA size has increased substantially ( I'd expect this, being a DW with an MDX miiddle ), to about 40G, but I also notice that the SGA has remained static at about 20G (it was 25G). I've ailso noticed that the shared pool has ballooned from a few hundred MB to 7Gb in a matter of months. This is definitely increasing I/O which is unwanted.
Why does the shared pool get so big ? We are not a high turnover/large user number operation and parse times are a very small proportion of overall query time. Will a flush shrink the shared pool memory allocation or will it jsut clear the space ?

OK, the allocated PGA will of course increase in response to demand, but I do not believe that the total PGA + SGA will ever break your 45G limit, and never has. I guess OEM is mis-representing something.
wrt the performance issue, I would question whether the size of the shared pool is in fact impacting on performance. The way I look at it is that no end user ever telphoned the help desk to say "the shared pool is too big" or "disc I/O is excessive". They may telephone to say "my queries are too slow". This throws you into the realm of query tuning, which would be a different topic.
wrt to memory usage and AMM, I believe that AMM does tend to assign more memory than needed to the shared_pool. If this really is a problem in your instance (and we don't know this yet) then you can set minimum values for the other SGA structures (usually, db_cache_size) to prevent this.
Hope this helps.
J.

Keep Sequences in Shared Pool for RAC Environment

Hi,
We have 2 node RAC setup for production environment. I want to pin cached sequences in my database. We are using following command for this purpose.
EXEC DBMS_SHARED_POOL.KEEP('HR.MySeq','Q');
Do I need to execute this command for each single node?

Pinning is in the Shared Pool in the SGA. So it is local to an instance.
Therefore, you would need to execute it in each instance (i.e. on each node).
Note : However, with sequences in RAC, you have to be careful with the definition. Have you defined it or do you need to define it as CACHE/NOCACHE ? Have you defined it or do you need to define it as ORDER (to guarantee order generation in RAC) ?
Hemant K Chitale

Shared Pool utilisation

Hello Team:
I ran a metalink script to report the shared pool utilization recently. I took this output when the database was on peak load.
SQL> /
Obj mem: 66435759 bytes (63.36MB)
Shared sql: 324219036 bytes (309.2MB)
Cursors: 341207073 bytes (325.4MB)
Free memory: 67228508 bytes (64.11MB)
Shared pool utilization (total): 468785754 bytes (447.07MB)
Shared pool allocation (actual): 754974720bytes (720MB)
Percentage Utilized: 91%
does this mean I have to add more space to shared pool. If so what is the threshold value?
Regards,
Bala

Bhawani nandan Prasad - Principal DBA -- See a to z diagnostics about Shared pool
1. Memory     2
a. Shared Pool     2
1. Introduction     2
2. Architecture     2
3. Scripts for different DBA tasks:     5
a.Measure object usage inside the shared pool and Tune shared pool     7
b.Check reload problem in library cache     12
c.Find the large queries in the shared pool library cache (using > 4mb each)     13
d.Find objects that can be considered pining into the shared pool     13
e.LRU work and objects were loaded and flushed     13
f.How much are waiting for Library Cache Latch     14
g.Queries identical but aren’t shared.     14
h.Get Biggest chunk of free memory.     14
i.Check the shared pool reserved size status     16
j.When having multiple subheaps:     16
k.Check shared pool at first glance quick diagnostics     17
l.Memory Usage - object list level view     17
m.Loads Number of times object has been loaded     17
n.Check number of times and object has been executed     18
o.Check shared pool in more details     18
p.Library Cache Statistics     18
q.Reserve Pool Settings     19
r.Pinned Objects     19
s.Finding literal SQL     19
t.Finding the Library Cache hit ratio     19
u. Row Cache Misses – Dictionary cache stats     19
v. Checking hash chain lengths     20
w. Checking for high version counts     20
x. Finding statement/s which use lots of shared pool memory     20
y. Allocations causing shared pool memory to be 'aged' out     21
z. Issues in various Oracle Releases     21
4. Terminology     22
5. Oracle 11g Caching and Pooling – SQL Result Cache     27
6. References     37
2. SQL     38
3. Statistics     38
4. Wait events     38
5. Schema     39
6. General     39
a. Scripts     39
1. accept.sql     39
1. Memory
a. Shared Pool
1. Introduction
Shared pool is used to cache different types of data such as textual and executable forms of PL/SQL blocks and SQL statements, dictionary cache data, and other data in SGA. Additional shared memory needed in the SHARED POOL if using ASM storage. Gathering schema/database stats (table/index stats) makes database query performance better and it reduce utilization of shared pool. Hence, practice to schedule job to gather stats regularly which suites your database performance. If you use shared pool effectively you can reduce resource consumption in at least four ways
1.     Parse overhead is avoided if the SQL statement is already in the shared pool. This saves CPU resources on the host and elapsed time for the end user.
2.     Latching resource usage is significantly reduced, which results in greater scalability.
3.     Shared pool memory requirements are reduced, because all applications use the same pool of SQL statements and dictionary resources.
4.     I/O resources are saved, because dictionary elements that are in the shared pool do not require disk access.
This sharable area of memory is managed as a sophisticated cache and heap manager rolled into one. It has 3 fundamental problems to overcome:
1.     The unit of memory allocation is not a constant - memory allocations from the pool can be anything from a few bytes to many kilobytes
2.     Not all memory can be 'freed' when a user finishes with it (as is the case in a traditional heap manager) as the aim of the shared pool is to maximize share of information. The information in the memory may be useful to another session - Oracle cannot know in advance if the items will be of any use to anyone else or not.
3.     There is no disk area to page out to so this is not like a traditional cache where there is a file backing store. Only "rewriteable" information can be discarded from the cache and it has to be re-created when it is next needed.
Oracle 10g architecture of Shared pool:
Library Cache     Shared SQL Area (Hash Value, SQL source, Execution plan)
Data Dictionary Cache
Enqueues     Fixed Area     Other
Latches
Oracle 11g architecture of Shared pool:
Library Cache     Shared SQL Area (Hash Value, SQL source, Execution plan)
Data Dictionary Cache
Result Cache
Enqueues     Fixed Area     Other
Latches
1. Library Cache
Shared Sql Area: contains Parsed SQL and execution Plans for statements already run against the database. This area allows SQL execution plans to be reused by many users.
Private SQL Area: Private SQL areas are non-shared memory areas assigned to unique user sessions.
Pl/sql Area: contains the recently executed Procedures, Functions and Packages.
Control Structures: Common control structure information example Memory for Latches and locks, sequence cache.
2. Dictionary cache known as the row cache.
Dictionary cache stores all the metadata info of tables and views in the database, Names and data types of the columns in the database, Object and system privileges of all the Users. Oracle maintains the stats of all the objects in the shared pool, if any of the memory objects are not used from the last 3 seconds, these memory objects will be aged out and will be removed from the cache. All the Shared Pool Structures are maintained by a LRU (least recently Used) algorithm, by which Oracle removes the objects from the shared Pool, until there is enough free space in the shared Pool to keep new Object.
3. Scripts for different DBA tasks:
Dictionary Views for shared POOL:
NON-RAC
V$DB_CACHE_ADVICE
V$DB_OBJECT_CACHE
V$DLM_LATCH
V$DLM_LOCKS
V$LATCH
V$LATCHHOLDER
V$LATCHNAME
V$LATCH_CHILDREN
V$LATCH_MISSES
V$LATCH_PARENT
V$LIBRARYCACHE
V$LOCK
V$LOCKED_OBJECT
V$LOCKS_WITH_COLLISIONS
V$LOCK_ACTIVITY
V$LOCK_ELEMENT
V$OPEN_CURSOR
V$PROCESS
V$PX_PROCESS
V$PX_PROCESS_SYSSTAT
V$PX_SESSION
V$PX_SESSTAT
V$ROWCACHE
V$ROWCACHE_PARENT
V$ROWCACHE_SUBORDINATE
V$SESSION
V$SESSION_CONNECT_INFO
V$SESSION_CURSOR_CACHE
V$SESSION_EVENT
V$SESSION_LONGOPS
V$SESSION_OBJECT_CACHE
V$SESSION_WAIT
V$SESSTAT
V$SESS_IO
V$SGA
V$SGASTAT
V$SGAINFO
V$SGA_DYAMIC_COMPONENTS
V$SGA_DYNAMIC_FREE_MEMORY
V$SGA_RESIZE_OPS
V$SGA_CURRENT_RESIZE_OPS
v$shared_pool_advice
V_$SHARED_POOL_ADVICE
V$SHARED_POOL_RESERVED
V$SHARED_SERVER
V$SORT_SEGMENT
V$SORT_USAGE
V$SQL
V$SQLAREA
V$SQLTEXT
V$SQLTEXT_WITH_NEWLINES
V$SQL_BIND_DATA
V$SQL_BIND_METADATA
V$SQL_CURSOR
V$SQL_SHARED_CURSOR
V$SQL_SHARED_MEMORY
V$STATNAME
V$SUBCACHE
V$SYSSTAT
V$SYSTEM_CURSOR_CACHE
V$SYSTEM_EVENT
V$SYSTEM_PARAMETER
X$KSMSP
RAC
GV$LATCH
GV$LATCHHOLDER
GV$LATCHNAME
GV$LATCH_CHILDREN
GV$LATCH_MISSES
GV$LATCH_PARENT
GV$LIBRARYCACHE
GV$LOCK
GV$LOCKED_OBJECT
GV$LOCKS_WITH_COLLISIONS
GV$LOCK_ACTIVITY
GV$LOCK_ELEMENT
GV$PROCESS
GV$PX_PROCESS
GV$PX_PROCESS_SYSSTAT
GV$PX_SESSION
GV$PX_SESSTAT
GV$ROWCACHE
GV$ROWCACHE_PARENT
GV$ROWCACHE_SUBORDINATE
GV$SESSION
GV$SESSION_CONNECT_INFO
GV$SESSION_CURSOR_CACHE
GV$SESSION_EVENT
GV$SESSION_LONGOPS
GV$SESSION_OBJECT_CACHE
GV$SESSION_WAIT
GV$SESSTAT
GV$SESS_IO
GV$SGA
GV$SGASTAT
gv$shared_pool_advice
GV$SHARED_POOL_RESERVED
GV$SHARED_SERVER
GV$SORT_SEGMENT
GV$SORT_USAGE
GV$SQL
GV$SQLAREA
GV$SQLTEXT
GV$SQLTEXT_WITH_NEWLINES
GV$SQL_BIND_DATA
GV$SQL_BIND_METADATA
GV$SQL_CURSOR
GV$SQL_SHARED_CURSOR
GV$SQL_SHARED_MEMORY
GV$STATNAME
GV$SUBCACHE
GV$SYSSTAT
GV$SYSTEM_CURSOR_CACHE
GV$SYSTEM_EVENT
GV$SYSTEM_PARAMETER
GV$WAITSTAT
GV$_LOCK
a.Measure object usage inside the shared pool and Tune shared pool
set pagesize 132
column owner format a16
column name format a36
column sharable_mem format 999,999,999
column executions format 999,999,999
prompt
prompt Memory Usage of Shared Pool Order - Biggest First
prompt
column name format 45
select owner, name||' - '||type name, sharable_mem from v$db_object_cache
where sharable_mem > 10000
and type in ('PACKAGE', 'PACKAGE BODY', 'FUNCTION', 'PROCEDURE')
order by sharable_mem desc
prompt
prompt Loads into Shared Pool - Most Loads First
prompt
select owner, name||' - '||type name, loads , sharable_mem from v$db_object_cache
where loads > 3
and type in ('PACKAGE', 'PACKAGE BODY', 'FUNCTION', 'PROCEDURE')
order by loads desc
prompt
prompt Executions of Objects in the Shared Pool - Most Executions First
prompt
select owner, name||' - '||type name, executions from v$db_object_cache
where executions > 100
and type in ('PACKAGE', 'PACKAGE BODY', 'FUNCTION', 'PROCEDURE')
order by executions desc
select 'If the values for the EXEC and LOADS close increase SHARED_POOL_SIZE!' from dual ;
set feedback off
set linesize 80
set pagesize 52
clear columns
clear breaks
col executions HEADING EXEC
col sharable_mem heading SHAMEM
col owner format a8
col name format a30
col type format a12
set numwidth 8
ttitle center 'Data Base Objects Owned by All Users Statistics' skip 2
select name, type, sharable_mem, loads, executions, pins
from sys.v_$db_object_cache ;
b.Check reload problem in library cache
select namespace, pins, reloads from v$librarycache;
show parameters shared_pool
select bytes/1024/1024 from v$sgastat where pool='shared pool' and name='free memory';
c.Find the large queries in the shared pool library cache (using > 4mb each)
SELECT sql_text "Stmt", count(*), sum(sharable_mem) "Mem",
sum(users_opening) "Open", sum(executions) "Exec"
FROM v$sql GROUP BY sql_text HAVING sum(sharable_mem) > 4096000;
d.Find objects that can be considered pining into the shared pool
column name format a40
column owner format a15
select owner, name, executions, locks, pins, loads, kept from v$db_object_cache where loads > 10;
create temp table and insert records of candidates to be pinned.
CREATE TABLE LRU_TMP AS SELECT * FROM X$KSMLRU;
INSERT INTO LRU_TMP SELECT * FROM X$KSMLRU;
Use the LRU_TMP table for analysis.
SELECT USERNAME, KSMLRCOM, KSMLRHON, KSMLRNUM, KSMLRSIZ, SQL_TEXT
FROM V$SQLAREA A, LRU_TMP K, V$SESSION S WHERE KSMLRSIZ > 3000
AND A.ADDRESS=S.SQL_ADDRESS AND A.HASH_VALUE = S.SQL_HASH_VALUE
AND SADDR=KSMLRSES;
You can see the candidates to pin from the query below
COL STORED_OBJECT FORMAT A40;
COL SQ_EXECUTIONS FORMAT 999,999;
SELECT /*+ ORDERED USE_HASH(D) USE_HASH(C) */ O.KGLNAOWN||’.'||O.KGLNAOBJ STORED_OBJECT, SUM(C.KGLHDEXC) SQL_EXECUTIONS
FROM SYS.X$KGLOB O, SYS.X$KGLRD D, SYS.X$KGLCURSOR C
WHERE
O.INST_ID = USERENV(’INSTANCE’) AND
D.INST_ID = USERENV(’INSTANCE’) AND
C.INST_ID = USERENV(’INSTANCE’) AND
O.KGLOBTYP IN (7, 8, 9, 11, 12) AND
D.KGLHDCDR = O.KGLHDADR AND
C.KGLHDPAR = D.KGLRDHDL
GROUP BY O.KGLNAOWN, O.KGLNAOBJ
HAVING SUM(C.KGLHDEXC) > 0
ORDER BY 2 DESC;
How to pin object
EXECUTE SYS.DBMS_SHARED_POOL.SIZES(150);
EXECUTE SYS.DBMS_SHARED_POOL.KEEP('SYS.STANDARD');
EXECUTE SYS.DBMS_SHARED_POOL.UNKEEP('SYS.STANDARD');
e.LRU work and objects were loaded and flushed
LRU work in the shared pool KSMLRNUM stores the number of objects that were flushed to load the large object. KSMLRISZ stores the size of the object that was loaded (contiguous memory allocated)
column ksmlrcom format a20
column username format a5
select username,sid,KSMLRCOM,KSMLRSIZ,KSMLRNUM, KSMLRHON, KSMLROHV, KSMLRSES from x$ksmlru , v$session where KSMLRSES=SADDR and KSMLRNUM >2 ;
f.How much are waiting for Library Cache Latch
select count(*),event from v$session_wait where event not like '%SQL%' and event not like '%ipc%' and event not like '%timer%' GROUP BY EVENT;
select count(*),wait_time from v$session_wait where event='latch free' and p2=106 group by wait_time;
select sid,wait_time,seconds_in_wait from v$session_wait where event='latch free' and p2=106 and WAIT_TIME>1;
g.Queries identical but aren’t shared.
SELECT address, hash_value, version_count , users_opening , users_executing,
substr(sql_text,1,240) "SQL" FROM v$sqlarea WHERE version_count > 10;
h.Get Biggest chunk of free memory.
select sysdate, decode( sign(ksmchsiz - 812), -1, (ksmchsiz - 16) / 4,
decode(sign(ksmchsiz - 4012),-1, trunc((ksmchsiz + 11924) / 64),
decode(sign(ksmchsiz - 65548), -1, trunc(1/log(ksmchsiz - 11, 2)) + 238,254))) bucket,
sum(ksmchsiz) free_space, count(*) free_chunks, trunc(avg(ksmchsiz)) average_size,
max(ksmchsiz) biggest from x$ksmsp
where inst_id = userenv('Instance') and ksmchcls = 'free' group by
decode(sign(ksmchsiz - 812),-1, (ksmchsiz - 16) / 4,
decode(sign(ksmchsiz - 4012),-1, trunc((ksmchsiz + 11924) / 64),
decode(sign(ksmchsiz - 65548),-1, trunc(1/log(ksmchsiz - 11, 2)) + 238,254 ))) ;
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;
CLASS     NUM     SIZ     AVG SIZE
freeabl     19010     34519404     1.77k
recr     23581     24967956     1.03k
R-freea     68     1632     .02k
perm     22     39801268     1,766.75k
R-free     34     7238192     207.90k
free     2389     36075980     14.75k
Watch for trends using these guidelines:
a) if ‘free’ memory is low (less than 5mb or so) you may need to increase the shared_pool_size and shared_pool_reserved_size. You should expect ‘free’ memory to increase and decrease over time. Seeing trends where ‘free’ memory decreases consistently is not necessarily a problem, but seeing consistent spikes up and down could be a problem.
b) if ‘freeable’ or ‘perm’ memory continually grows then it is possible you are seeing a memory bug.
c) if ‘freeabl’ and ‘recr’ memory classes are always huge, this indicates that you have a lot of cursor info stored that is not releasing.
d) if ‘free’ memory is huge but you are still getting 4031 errors, the problem is likely reloads and invalids in the library cache causing fragmentation.
-Note says that this query can hang database on HP platforms
See the shared pool parameters
column name format a30
select name,value from v$parameter where name like '%shared_pool%' ;
select x.ksppinm, y.ksppstvl from x$ksppi x , x$ksppcv y where x.indx = y.indx and lower(x.ksppinm) like '%spin%';
SELECT count(*) FROM v$latch_children WHERE NAME = 'library cache';
Shrinking and growing operations from V$SGA_RESIZE_OPS dynamic view:
select to_char(end_time, ‘dd-Mon-yyyy hh24:mi’) end, oper_type, initial_size, target_size, final_size from V$SGA_RESIZE_OPS where component=’shared pool’ order by end;
#shared_pool_summary.sql -get an overview of chunks in the shared pool
select
ksmchcom contents,
count(*) chunks,
sum(decode(ksmchcls, 'recr', ksmchsiz)) recreatable,
sum(decode(ksmchcls, 'freeabl', ksmchsiz)) freeable,
sum(ksmchsiz) total
from
sys.x_$ksmsp
where
inst_id = userenv('Instance') and
ksmchcls not like 'R%'
group by
ksmchcom
#reserved_pool_summary.sql - get an overview of chunks in the reserved pool
select
ksmchcom contents,
count(*) chunks,
sum(decode(ksmchcls, 'R-recr', ksmchsiz)) recreatable,
sum(decode(ksmchcls, 'R-freea', ksmchsiz)) freeable,
sum(ksmchsiz) total
from
sys.x_$ksmspr
where
inst_id = userenv('Instance')
group by
ksmchcom
#save_sqlplus_settings.sql -reset sqlplus settings
set termout off
store set sqlplus_settings replace
clear breaks
clear columns
clear computes
set feedback off
set verify off
set termout on
set define "&"
#restore_sqlplus_settings.sql -reset sqlplus settings
set termout off
@sqlplus_settings
clear breaks
clear columns
clear computes
set termout on
i.Check the shared pool reserved size status
SELECT free_space, avg_free_size, used_space, avg_used_size, REQUEST_MISSES, request_failures, last_miss_size FROM v$shared_pool_reserved;
An ORA-04031 error referencing large failed requests, indicates the Reserved Area is too fragmented. The reserved pool is small when: REQUEST_FAILURES > 0 (and increasing), The DBA should Increase shared_pool_reserved_size and shared_pool_size together. It is possible that too much memory has been allocated to the reserved list. The DBA should Decrease shared_pool_reserved_size, If: REQUEST_MISS = 0 or not increasing
FREE_MEMORY = > 50% of shared_pool_reserved_size minimum
col free_space for 999,999,999,999 head “TOTAL FREE”
col avg_free_size for 999,999,999,999 head “AVERAGE|CHUNK SIZE
col free_count for 999,999,999,999 head “COUNT”
col request_misses for 999,999,999,999 head “REQUEST|MISSES
col request_failures for 999,999,999,999 head “REQUEST|FAILURES”
col max_free_size for 999,999,999,999 head “LARGEST CHUNK”
select free_space, avg_free_size, free_count, max_free_size, request_misses, request_failures from v$shared_pool_reserved;
TOTAL FREE     AVERAGE
CHUNK SIZE     COUNT     LARGEST CHUNK     REQUEST
MISSES     REQUEST
FAILURES
7,238,192     212,888     34     212,888     0     0
You should also use hidden and unsupported parameter “_shared_pool_reserved_pct” to control reserved pool. This parameter controls the allocated percentage of shared pool for reserved pool. By default it is %5 of the shared pool and if you use ASMM for memory management you can set this value higher like 10 to allocate reserved pool dynamically. When you set the parameter you will see the shared_pool_reserved_size parameter will be adjusted to the new setting. The parameter can not be modified when instance is started. You can use the query below to see the current value
select a.ksppinm “Parameter”, b.ksppstvl “Session Value”, c.ksppstvl “Instance Value” from sys.x$ksppi a, sys.x$ksppcv b, sys.x$ksppsv c where a.indx = b.indx and a.indx = c.indx and a.ksppinm = ‘_shared_pool_reserved_pct’;
Parameter     Session Value     Instance Value
sharedpool_reserved_pct     10     10
j.When having multiple subheaps:
select KSMCHIDX, ksmchcom ChunkComment,
decode(round(ksmchsiz/1000),0,'0-1K', 1,'1-2K', 2,'2-3K', 3,'3-4K',4,'4-5K',5,'5-6k',6,'6-7k',7,'7-8k',8,'8-9k', 9,'9-10k', '> 10K'), count(*), ksmchcls Status, sum(ksmchsiz) Bytes
from x$ksmsp where KSMCHCOM = 'free memory' group by KSMCHIDX,ksmchcom, ksmchcls, decode(round(ksmchsiz/1000),0,'0-1K', 1,'1-2K', 2,'2-3K', 3,'3-4K',4,'4-5K',5,'5-6k',6,'6-7k',7,'7-8k',8,'8-9k', 9,'9-10k','> 10K');
SubPool     SGA_HEAP     CHUNKCOMMENT     size     COUNT(*)     STATUS     BYTES
1     sga heap(1,0)     free memory     > 10K     34     R-free     7238192
1     sga heap(1,0)     free memory     3-4K     2     free     6284
1     sga heap(1,0)     free memory     > 10K     241     free     35707400
1     sga heap(1,0)     free memory     8-9k     1     free     7712
1     sga heap(1,0)     free memory     2-3K     4     free     6752
1     sga heap(1,0)     free memory     0-1K     2090     free     133288
1     sga heap(1,0)     free memory     9-10k     21     free     188676
1     sga heap(1,0)     free memory     1-2K     30     free     25868
If you see lack of large chunks it is possible that you can face with ORA-04031 in near future.
k.Check shared pool at first glance quick diagnostics
select 'You may need to increase the SHARED_POOL_RESERVED_SIZE' Description, 'Request Failures = '||REQUEST_FAILURES Logic
from      v$shared_pool_reserved where      REQUEST_FAILURES > 0
and      0 != (select      to_number(VALUE) from      v$parameter
where      NAME = 'shared_pool_reserved_size')
union
select 'You may be able to decrease the SHARED_POOL_RESERVED_SIZE' Description,'Request Failures = '||REQUEST_FAILURES Logic
from      v$shared_pool_reserved where      REQUEST_FAILURES < 5
and      0 != (select      to_number(VALUE) from      v$parameter
     where      NAME = 'shared_pool_reserved_size')
l.Memory Usage - object list level view
•     Owner - Owner of the object
•     Object - Name/namespace of the object
•     Sharable Memory - Amount of sharable memory in the shared pool consumed by the object
select OWNER, NAME||' - '||TYPE object,SHARABLE_MEM
from      v$db_object_cache where SHARABLE_MEM > 10000
and     type in ('PACKAGE','PACKAGE BODY','FUNCTION','PROCEDURE')
order by owner asc ,SHARABLE_MEM desc
SELECT * FROM (SELECT ROW_NUMBER () over (PARTITION BY NAMESPACE ORDER BY SHARABLE_MEM DESC) ROW_within , NAMESPACE, SHARABLE_MEM, SUBSTR(NAME,1,40) NAME FROM V$DB_OBJECT_CACHE ORDER BY SHARABLE_MEM DESC) WHERE ROW_WITHIN <= 2 ORDER BY NAMESPACE, ROW_WITHIN;
ROW_WITHIN NAMESPACE SHARABLE_MEM NAME
1 CLUSTER 2794 C_OBJ#_INTCOL#
2 CLUSTER 1684 SMON_SCN_TO_TIME
1 RSRCPLAN 5117 SYS_GROUP

Contention for latches related to the shared pool was consuming significant

We are having performance issue on our database. When I look at the AWR, I see that there is a contention for latches. Below is the AWR Report.
ADDM Report for Task 'ADDM:1775307360_12808'
Analysis Period
AWR snapshot range from 12807 to 12808.
Time period starts at 10-MAY-11 01.00.15 PM
Time period ends at 10-MAY-11 02.00.23 PM
Analysis Target
Database 'ADVFDWP' with DB ID 1775307360.
Database version 11.1.0.7.0.
ADDM performed an analysis of all instances.
Activity During the Analysis Period
Total database time was 27827 seconds.
The average number of active sessions was 7.71.
Summary of Findings
Description Active Sessions Recommendations
Percent of Activity
1 Shared Pool Latches 6.43 | 83.42 0
2 Top SQL by DB Time 2.41 | 31.24 3
3 "Concurrency" Wait Class 2.18 | 28.22 0
4 PL/SQL Execution 1.53 | 19.86 1
5 "User I/O" wait Class 1.33 | 17.24 0
6 Hard Parse 1.24 | 16.14 0
7 Undersized Buffer Cache .83 | 10.73 0
8 CPU Usage .7 | 9.02 0
9 Top SQL By I/O .31 | 4.04 1
10 Top Segments by I/O .24 | 3.12 1
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Findings and Recommendations
Finding 1: Shared Pool Latches
Impact is 6.43 active sessions, 83.42% of total activity.
Contention for latches related to the shared pool was consuming significant
database time in some instances.
Instances that were significantly affected by this finding:
Number Name Percent Impact ADDM Task Name
1 ADVFDWP1 99.31 ADDM:1775307360_1_12808
Check the ADDM analysis of affected instances for recommendations.
Finding 2: Top SQL by DB Time
Impact is 2.41 active sessions, 31.24% of total activity.
SQL statements consuming significant database time were found.
Recommendation 1: SQL Tuning
Estimated benefit is 1.07 active sessions, 13.82% of total activity.
Action
Run SQL Tuning Advisor on the SQL statement with SQL_ID "fdk73nhpt93a5".
Related Object
SQL statement with SQL_ID fdk73nhpt93a5.
INSERT INTO SFCDM.F_LOAN_PTFL_MOL_SNPSHT SELECT * FROM
F_LOAN_PTFL_MOL_SNPSHT_STG
Recommendation 2: SQL Tuning
Estimated benefit is 1 active sessions, 12.96% of total activity.
Action
Tune the PL/SQL block with SQL_ID "7nvgzsgy9ydn9". Refer to the "Tuning
PL/SQL Applications" chapter of Oracle's "PL/SQL User's Guide and
Reference".
Related Object
SQL statement with SQL_ID 7nvgzsgy9ydn9.
begin
insert into SFCDM.F_LOAN_PTFL_MOL_SNPSHT select * from
F_LOAN_PTFL_MOL_SNPSHT_STG;
end;
Recommendation 3: SQL Tuning
Estimated benefit is .4 active sessions, 5.2% of total activity.
Action
Investigate the SQL statement with SQL_ID "fcvfq2gzmxu0t" for possible
performance improvements.
Related Object
SQL statement with SQL_ID fcvfq2gzmxu0t.
select
a11.DT_YR_MO DT_YR_MO,
a11.IND_SCRTZD IND_SCRTZD,
a13.CD_LNSTAT CD_LNSTAT_INTGRTD,
sum(a11.CNT_LOAN) WJXBFS1,
sum(a11.AMT_PART_EOP_UPB) WJXBFS2,
sum(a11.AMT_LST_VLD_PART_UPB) WJXBFS3
from
SFCDM.F_LOAN_PTFL_MOL_SNPSHT
a11
join
SFCDM.D_DETD_LNSTAT_CURR
a12
on
(a11.ID_CYCL_CLOS_DETD_LNSTAT_SRGT = a12.ID_DETD_LNSTAT_SRGT)
join
SFCDM.D_LNSTAT_CD
a13
on
(a12.ID_LNSTAT_CD_SRGT = a13.ID_LNSTAT_CD_SRGT)
join
SFCDM.D_LOAN_CHARTC_CURR_MINI
a14
on
(a11.ID_LOAN_CHARTC_SRGT = a14.ID_LOAN_CHARTC_SRGT)
where
(a11.DT_YR_MO in (201103)
and a14.CD_SFCRM_LOAN_BUS_LI not in ('L', 'T', 'W')
and a13.CD_LNSTAT in (14)
and not exists
(select * from SFCDM.F_LOAN_PTFL_MOL_SNPSHT s
where s.id_loan_syst_gend = a11.id_loan_syst_gend
and s.dt_yr_mo

It is worth checking the actual size of the shared pool e.g.
select pool,sum(bytes)/1024/1024/1024 from v$sgastat group by pool;
the parameters you ahve posted suggest you have set a minimum but no maximum, so it could very large.
Next up is looking for unhared SQL i.e.
select column1 from some_table where column2='A_VALUE';
select column1 from some_table where column2='Another_Value';
where the code should be using binds instead of literals for security and performance reasons, a simple way to find this is to look in v$sql for sql having the same plan_hash_value but different sql_Ids and compare the sql_fulltext of each statement.
Also a possibility is sql with many child cursors, this is trickier as the cause may vary and may not be easy to fix. check th econtents of v$sql for sql that have high values in the child_number column anmd investigate the contents of v$sql_shared_cursor for the reason there are multiple child cursors.
Chris

Shared pool request_failures

Hello,
Does any one ever faced the problem of REQUEST_FAILURES in shared pool? If yes, please share your experience(s). We have this issue every now and then, and I am just fed up of this alarm. Sometimes request_failures are over thousand.
This occurs in both 10g (10.2) and 11g DB (11.2.0.3) OS=RHL data guard setup
SYS@db AS SYSDBA> select request_failures from v$shared_pool_reserved; ---Primary DB
REQUEST_FAILURES
           52
SYS@db AS SYSDBA> show parameter shared_pool_reserved_size
NAME                         TYPE                           VALUE
shared_pool_reserved_size          big integer                      348966092
SYS@db AS SYSDBA> select free_space,avg_free_size,used_space,request_failures,requests,max_free_size,request_misses from v$shared_pool_reserved;
FREE_SPACE AVG_FREE_SIZE USED_SPACE REQUEST_FAILURES   REQUESTS MAX_FREE_SIZE REQUEST_MISSES
236005496    241314,413    5668264            57           0       6713160             0Thanks a lot.
Best Regards
Edited by: K-Saf on Sep 4, 2012 12:46 PM
Edited by: K-Saf on Sep 4, 2012 12:46 PM
Edited by: K-Saf on Sep 4, 2012 1:00 PM

Hello Kuljeet Pal,
Thanks a lot. Here is the result of your suggested queries. Please have a look and suggest.
- AS SYSDBA> SELECT shared_pool_size_for_estimate, estd_lc_size, estd_lc_time_saved FROM v$shared_pool_advice;
SHARED_POOL_SIZE_FOR_ESTIMATE ESTD_LC_SIZE ESTD_LC_TIME_SAVED
                2816            455            819115
                3584           1222            819732
                4352           1990            824577
                5120           2758            837826
                5376           3014            848912
                5504           3142            854454
                5632           3270            860003
                5760           3398            865548
                5888           3526            871084
                6016           3653            876620
                6144           3780            882158
                6272           3908            887700
                6400           4036            893245
                6528           4164            898789
                6656           4292            904342
                6784           4420            904351
                6912           4548            904351
                7040           4676            904352
                7168           4804            904353
                7296           4932            904354
                7424           5060            904355
                7552           5188            904356
                7680           5316            904356
                7808           5444            904356
                8192           5828            904356
                8960           5888            904356
                9728           5888            904356
               10496           5888            904356
               11264           5888            904356
               12032           5888            904356
               12800           5888            904356
               13568           5888            904356
32 rows selected.
COMPONENT                 OPER_TYPE       PARAMETER                INITIAL_SIZE TARGET_SIZE FINAL_SIZE STARTED                                                              ENDED
streams pool                 GROW            streams_pool_size           134217728   268435456     268435456 03-sep-2012:14:07:44                                                         03-sep-2012:14:07:44
DEFAULT buffer cache            SHRINK            db_cache_size               3,4226E+10 3,4091E+10 3,4091E+10 03-sep-2012:14:07:44                                                         03-sep-2012:14:07:44
java pool                 STATIC            java_pool_size                     0   134217728     134217728 30-aug-2012:15:31:27                                                         30-aug-2012:15:31:27
streams pool                 STATIC            streams_pool_size                0   134217728     134217728 30-aug-2012:15:31:27                                                         30-aug-2012:15:31:27
DEFAULT buffer cache            INITIALIZING    db_cache_size               3,4226E+10 3,4226E+10 3,4226E+10 30-aug-2012:15:31:27                                                         30-aug-2012:15:31:31
ASM Buffer Cache            STATIC            db_cache_size                     0          0          0 30-aug-2012:15:31:27                                                         30-aug-2012:15:31:27
DEFAULT buffer cache            STATIC            db_cache_size                     0 3,4226E+10 3,4226E+10 30-aug-2012:15:31:27                                                         30-aug-2012:15:31:27
DEFAULT 2K buffer cache        STATIC            db_2k_cache_size                 0          0          0 30-aug-2012:15:31:27                                                         30-aug-2012:15:31:27
DEFAULT 4K buffer cache        STATIC            db_4k_cache_size                 0          0          0 30-aug-2012:15:31:27                                                         30-aug-2012:15:31:27
DEFAULT 8K buffer cache        STATIC            db_8k_cache_size                 0          0          0 30-aug-2012:15:31:27                                                         30-aug-2012:15:31:27
DEFAULT 16K buffer cache       STATIC            db_16k_cache_size                0          0          0 30-aug-2012:15:31:27                                                         30-aug-2012:15:31:27
DEFAULT 32K buffer cache       STATIC            db_32k_cache_size                0          0          0 30-aug-2012:15:31:27                                                         30-aug-2012:15:31:27
KEEP buffer cache            STATIC            db_keep_cache_size                0          0          0 30-aug-2012:15:31:27                                                         30-aug-2012:15:31:27
RECYCLE buffer cache            STATIC            db_recycle_cache_size                0          0          0 30-aug-2012:15:31:27                                                         30-aug-2012:15:31:27
shared pool                 STATIC            shared_pool_size                 0 6979321856 6979321856 30-aug-2012:15:31:27                                                         30-aug-2012:15:31:27
large pool                 STATIC            large_pool_size                     0   134217728     134217728 30-aug-2012:15:31:27                                                         30-aug-2012:15:31:27
16 rows selectedBest Regards

Shared Pool Statistics - awr report -m 10.2.0.1

Hi,
I'm new to reading awr report and performance tuning.
I have the below in my statspack.
Do i need to increase my shared pool?
Any one can advise and explain "% Memory for SQL w/exec" and "% SQL with executions>1"
Shared Pool Statistics
Begin End
Memory Usage %: 95.78 97.71
% SQL with executions>1: 51.51 80.85
% Memory for SQL w/exec> 1: 67.88 82.46
thanks!

user21123 wrote:
The sweet point for the shared pool Memory Usage % is at about ~70%-80% because of aging out. You are at ~90%. It would be advisable to increase the shared pool, but if you're using 10g SGA_TARGET and SGA_MAX_SIZE, then that might require increasing those parameters. It depends how your AWR report looks for the Buffer Cache.
What makes you think this ?
In an OLTP system you hope for 100% shareable SQL, and correct allocation for the other objects, which would lead to 100% usage. In realistic terms, you're likely to get a few percent (which is often the shared_pool_reserved) free because there's a constant turn-over of non-shareable SQL.
If you're always seeing 70% - 80%, then there are several scenraios that might explain the figure. One is that you've simply made shared pool a bit too big. At the opposite extreme you might be constantly flushing 20%-30% of the material from the shared pool because it has become so fragmented that you have to clear a lot of garbage to create a small amount of contiguous space.
The best guideline to follow is to check whether you appear to be losing a significant amount of time on libarary cache and shared pool latches, using up an undesirable amount of CPU on parse time, see lots of reloads (without corresponding invalidations) in v$librarycache.
Without further information, we really can't say how good or bad the situation is. In fact, it's possible that the information that +"50% of your SQL has been shared, 50% has been single use"+ is a possible indicator that the shared_pool_size is too small, and we are filling the excess space with garbage rather than keeping the garbage (and library cache search time) to a minimum.
I would be interested to hear the thinking behind your suggestion, though.
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
http://www.jlcomp.demon.co.uk
"The greatest enemy of knowledge is not ignorance, it is the illusion of knowledge." Stephen Hawking.

Shared Pool Allocation Problem

Hi everyone,
When I execute the following statement from my application, it returns the ORA-04031 29080216 byte can not allocate shared pool ("large pool","unknown object","hash-join subh","kllcqc:kllcqslt") error.
SELECT DISTINCT KULLANICIID, NOVELKULLANICIADI AS "KULLANICIADI" FROM KULLANICIROLLERI
LEFT OUTER JOIN KULLANICILAR ON KULLANICIROLLERI.KULLANICIID = KULLANICILAR.ID
WHERE
KULLANICIROLLERI.AKTIF = '1' AND
KULLANICILAR.AKTIF = '1' AND
KULLANICILAR.NOVELKULLANICIADI IS NOT NULL AND
GECERLIOLDUGUELEMENTTYPENO = 5 AND GECERLIOLDUGUELEMENTID = 1
But when I look the parameters their values are
shared_pool_size : 318767104
large_pool_size : 335544320
How can I solve that problem.. Actually the parameters seem to be ok..
Thanks in advance
OzerK

Hi,
Do you resolved problem with sharet pool allocation ?
I have a same, with ora-4031 error...
Best,
Adam
[email protected]

Sql query executes faster 2. time despite clearing buffer cache/shared pool

Hi All,
I want to test query performance, so i clear cache in following way before each execution:
alter system flush buffer_cache;
alter system flush shared_pool;
But, first execution takes more time than second and consequent executions. For example first execution takes 30 seconds, consequent executions take 3 seconds.
Before each execution I clear the cache.
What can be the reason? I use TOAD for query execution. Does TOAD caches something after first execution?
And last question. Is there a dynamic query that query execution duration is stored?
Any help will be appreciated.
Thanks.

>
So there shouldn't be problem from the parameter, can you post result from V$SGA_DYNAMIC_COMPONENTS and v$SGAINFO ?
V$SGA_DYNAMIC_COMPONENTS
COMPONENT CURRENT_SIZE MIN_SIZE MAX_SIZE USER_SPECIFIED_SIZE OPER_COUNT LAST_OPER_TYP LAST_OPER LAST_OPER GRANULE_SIZE
shared pool 436207616 402653184 0 0 125 GROW IMMEDIATE 02-JUL-09 16777216
large pool 201326592 117440512 0 83886080 12 SHRINK DEFERRED 02-JUL-09 16777216
java pool 16777216 16777216 0 0 0 STATIC 16777216
streams pool 16777216 16777216 0 0 0 STATIC 16777216
DEFAULT buffer cache 1895825408 1711276032 0 16777216 137 GROW DEFERRED 02-JUL-09 16777216
KEEP buffer cache 0 0 0 0 0 STATIC 16777216
RECYCLE buffer cache 0 0 0 0 0 STATIC 16777216
DEFAULT 2K buffer cache 0 0 0 0 0 STATIC 16777216
DEFAULT 4K buffer cache 0 0 0 0 0 STATIC 16777216
DEFAULT 8K buffer cache 0 0 0 0 0 STATIC 16777216
DEFAULT 16K buffer cache 0 0 0 0 0 STATIC 16777216
DEFAULT 32K buffer cache 0 0 0 0 0 STATIC 16777216
ASM Buffer Cache 0 0 0 16777216 0 STATIC 16777216
V$SGA_INFO
NAME BYTES RESIZEABL
Fixed SGA Size 2086392 No
Redo Buffers 14688256 No
Buffer Cache Size 1895825408 Yes
Shared Pool Size 436207616 Yes
Large Pool Size 201326592 Yes
Java Pool Size 16777216 Yes
Streams Pool Size 16777216 Yes
Granule Size 16777216 No
Maximum SGA Size 2634022912 No
Startup overhead in Shared Pool 218103808 No
Free SGA Memory Available 50331648

Keeping Large Objects in shared pool

Similar Messages

Maybe you are looking for