ShowDoc

https://metalink2.oracle.com/metalink/plsql/f?p=130:14:1058796320950...

My Oracle Support (the new MetaLink)

Bookmarks

Admin

Profile

Feedback

Sign Out

Help

Headlines Knowledge Browser Advanced Search Bug Search

Knowledge

Service Request

Collector

Patches & Updates

Community

Certify

Quick Find Did this article help solve your problem? Would you recommend this document to others?

Go

Advanced

Saved Searches

TIP: Click help for a detailed explanation of this page.

Subject: FREQUENT RESIZE OF SGA Doc ID: 742599.1 Modified Date : 05-MAR-2009 In this Document Symptoms Changes Cause Solution References Type: PROBLEM Status: PUBLISHED

Bookmark

Go to End

Applies to:
Oracle Server Enterprise Edition - Version: 10.2.0.1 to 11.1.0.7 This problem can occur on any platform. Oracle Server - Enterprise Edition - Version: 10.2.0.1 to 11.1.0.7 10.2.X TO 11.1.0.6.0

Symptoms
Typically you will see a small spike in cursor: pin S wait on X or library cache lock waits.This can happen more often in OLTP envoriment. shared pool and buffer cache is in demand. Problem will happen randomly and intermittently.

Changes
Automatic memory management is used. Characteristics of the workload has changed. Like for example some Batch Job has been added in an OLTP envoriment.

Cause
Due to frequent resize of the shared pool and buffer cache You can see cursor: pin S wait on X,library cache lock waits.
Query V$SGA_RESIZE_OPS set linesize 90 set pagesize 60 column component format a25 column Final format 99,999,999,999 column STARTED format A25 SELECT COMPONENT ,OPER_TYPE,FINAL_SIZE Final,to_char(start_time,'dd-mon hh24:mi:ss') STARTED FROM V$SGA_RESIZE_OPS; COMPONENT OPER_TYPE Final STARTED ------------------------- ------------- ---------------- -------------------DEFAULT buffer cache SHRINK 17,548,967,936 10/06/2008 07:56:28 COMPONENT OPER_TYPE Final STARTED ------------------------- ------------- ---------------- -------------------shared pool GROW 2,197,815,296 10/06/2008 07:56:28 DEFAULT buffer cache GROW 17,649,631,232 10/06/2008 07:54:25 shared pool SHRINK 2,097,152,000 10/06/2008 07:54:25 Note:----The shared pool shrinked at 7:54:25 and within 2 minutes it grew at 7:56:28 The default buffer cache grew at 7:54:25 and again shrunk at 7:56:28 . You can see resize operations every 30 seconds also. COMPONENT OPER_TYPE Final STARTED ------------------------- ------------- ---------------- -------------------shared pool GROW 2,130,706,432 10/06/2008 06:49:20 DEFAULT buffer cache GROW 17,649,631,232 10/06/2008 06:49:14 DEFAULT buffer cache SHRINK 17,632,854,016 10/06/2008 06:49:14 shared pool GROW 2,113,929,216 10/06/2008 06:49:14 shared pool SHRINK 2,097,152,000 10/06/2008 06:49:14 DEFAULT buffer cache SHRINK 17,599,299,584 10/06/2008 06:47:44 DEFAULT buffer cache SHRINK 17,616,076,800 10/06/2008 06:47:44 shared pool GROW 2,147,483,648 10/06/2008 06:47:44 shared pool GROW 2,130,706,432 10/06/2008 06:47:44 DEFAULT buffer cache GROW 17,649,631,232 10/06/2008 06:47:43 DEFAULT buffer cache SHRINK 17,632,854,016 10/06/2008 06:47:43

1 of 3

5/26/2009 10:52 PM

ShowDoc

https://metalink2.oracle.com/metalink/plsql/f?p=130:14:1058796320950...

SELECT COMPONENT,OPER_TYPE,COUNT(1) FROM V$SGA_RESIZE_OPS GROUP BY COMPONENT,OPER_TYPE; COMPONENT OPER_TYPE COUNT(1) ---------------------------------------------------------------- ------------- ---------shared pool GROW 94 DEFAULT buffer cache SHRINK 94 shared pool SHRINK 306 DEFAULT buffer cache GROW 306

V$SGA_RESIZE_OPS displays information about the last 800 completed SGA resize operations. This does not include in-progress operations. You can see here how many times the shrink and grow happened.

Get an Ash report for a small time frame like 2 minutes That you saw the problem. Check the Top Events,cursor: pin S wait on X or library cache lock waits can be seen. Check the section Activity Over Time and check the Slot Time ( Duration ) The times of cursor: pin S wait on X or library cache lock will be close to when the resize happened.

The Following will likely to return a row. select * from v$sgastat where name = 'KGH: NO ACCESS'; POOL NAME BYTES ------------ -------------------------- ---------shared pool KGH: NO ACCESS 216572480

DBA_HIST_SGASTAT displays detailed historical information on the system global area (SGA). SELECT A.BEGIN_INTERVAL_TIME,A.END_INTERVAL_TIME, B.BYTES FROM WRM$_SNAPSHOT A, DBA_HIST_SGASTAT B WHERE A.SNAP_ID = B.SNAP_ID AND B.POOL = 'SHARED POOL' AND B.NAME = 'KGH: NO ACCESS' ORDER BY 1; KGH: NO ACCESS chunks are owned by the buffer cache and indicate a partial transfer between buffer cache and shared pool.

This is due to Bug 7189722 and Bug 6528336 Alternating frequent shrink and grow of the buffer cache and shared pool may be seen with automatic memory management enabled causing various waits in sessions.

Solution

Disable Automatic memory management by setting SGA_TARGET=0. OR The following workaround can be used dynamically. alter system set "_memory_broker_stat_interval"=999; --- 999sec between resizes This will increase the time between resize to atleast 999 seconds. This will reduce the number of resizes. _memory_broker_stat_interval is in seconds,By Default it is 30 seconds. You can set _memory_broker_stat_interval to a larger value This should be done on all RAC nodes. OR

2 of 3

5/26/2009 10:52 PM

ShowDoc

https://metalink2.oracle.com/metalink/plsql/f?p=130:14:1058796320950...

Apply one off patches for Bug 7189722 and Bug 6528336

References
Note 6528336.8 - Bug 6528336 - Automatic SGA may repeatedly shrink / grow the shared pool Note 396940.1 - Troubleshooting and Diagnosing ORA-4031 Error

Keywords
SHARED~POOL ; LOCK ; LIBRARY~CACHE ; LIBRARY~CACHE~LOCK ; V$SGA_RESIZE_OPS ; V$SGASTAT ; CURSOR~~PIN~S~WAIT~ON~X ; V$SGASTAT ; V$SGA_RESIZE_OPS ;

Help us improve our service. Please email us your comments for this document. .

My Oracle Support (the new MetaLink)

Copyright 2006, Oracle. All rights reserved.

Bookmarks

Admin

Profile

Feedback

Sign Out

Help
Legal Notices and Terms of Use | Privacy Statement

3 of 3

5/26/2009 10:52 PM