Welcome to Scribd. Sign in or start your free trial to enjoy unlimited e-books, audiobooks & documents.Find out more
Download
Standard view
Full view
of .
Look up keyword
Like this
1Activity
0 of .
Results for:
No results containing your search query
P. 1
ASMM_SGA_RESIZE

ASMM_SGA_RESIZE

Ratings:
(0)
|Views: 45|Likes:
Published by satish.lodam

More info:

Published by: satish.lodam on Dec 04, 2011
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less

12/04/2011

pdf

text

original

 
My Oracle Support (the new MetaLink)
 
Bookmarks
 
Admin
 
Profile
 
Feedback
 
Sign Out
 
Help
 
Headlines
Knowledge
Service RequestCollectorPatches & UpdatesCommunityCertify
 
Knowledge Browser 
 
Advanced Search
Bug Search
 
Quick Find
Go
 
Advanced
 
Saved Searches
Did this article help solve your problem?Would you recommend this document to others? 
TIP:
Clickhelpfor a detailed explanation of this page.BookmarkGo to EndSubject:
FREQUENT RESIZE OF SGA
 Doc ID:
742599.1
Type:
PROBLEM
 Modified Date :
05-MAR-2009
Status:
PUBLISHEDIn this Document
 Symptoms Changes Cause Solution References
Applies to:
Oracle Server Enterprise Edition - Version: 10.2.0.1 to 11.1.0.7This problem can occur on any platform.Oracle Server - Enterprise Edition - Version: 10.2.0.1 to 11.1.0.710.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 indemand.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 90set pagesize 60column component format a25column Final format 99,999,999,999column 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:28COMPONENT OPER_TYPE Final STARTED------------------------- ------------- ---------------- --------------------shared pool GROW 2,197,815,296 10/06/2008 07:56:28DEFAULT buffer cache GROW 17,649,631,232 10/06/2008 07:54:25shared 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:28The 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:20DEFAULT buffer cache GROW 17,649,631,232 10/06/2008 06:49:14DEFAULT buffer cache SHRINK 17,632,854,016 10/06/2008 06:49:14shared pool GROW 2,113,929,216 10/06/2008 06:49:14shared pool SHRINK 2,097,152,000 10/06/2008 06:49:14DEFAULT buffer cache SHRINK 17,599,299,584 10/06/2008 06:47:44DEFAULT buffer cache SHRINK 17,616,076,800 10/06/2008 06:47:44shared pool GROW 2,147,483,648 10/06/2008 06:47:44shared pool GROW 2,130,706,432 10/06/2008 06:47:44DEFAULT buffer cache GROW 17,649,631,232 10/06/2008 06:47:43DEFAULT buffer cache SHRINK 17,632,854,016 10/06/2008 06:47:43
ShowDoc https://metalink2.oracle.com/metalink/plsql/f?p=130:14:1058796320950...1 of 3 5/26/2009 10:52 PM
 
SELECT COMPONENT,OPER_TYPE,COUNT(1) FROM V$SGA_RESIZE_OPS GROUP BY COMPONENT,OPER_TYPE;
COMPONENT OPER_TYPE COUNT(1)---------------------------------------------------------------- ------------- ----------shared pool GROW 94DEFAULT buffer cache SHRINK 94shared pool SHRINK 306DEFAULT 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 towhen the resize happened.
 The Following will likely to return a row.select * from v$sgastatwhere name = 'KGH: NO ACCESS';POOL NAME BYTES------------ -------------------------- ----------shared pool KGH: NO ACCESS 216572480DBA_HIST_SGASTAT displays detailed historicalinformation on the system global area (SGA).
SELECT A.BEGIN_INTERVAL_TIME,A.END_INTERVAL_TIME, B.BYTESFROM WRM$_SNAPSHOT A, DBA_HIST_SGASTAT BWHERE A.SNAP_ID = B.SNAP_IDAND B.POOL = 'SHARED POOL' AND B.NAME = 'KGH: NO ACCESS' ORDER BY 1;
KGH: NO ACCESS chunks are owned by the buffer cache and indicatea partial transfer between buffer cache and shared pool.This is due to Bug 7189722 andBug 6528336
Alternating frequent shrink and grow of the buffer cache andshared pool may be seen with automatic memory management enabledcausing various waits in sessions.
Solution
 Disable Automatic memory management by setting SGA_TARGET=0.ORThe following workaround can be used dynamically.alter system set "_memory_broker_stat_interval"=999; --- 999sec between resizesThis 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 valueThis should be done on all RAC nodes.OR
ShowDoc https://metalink2.oracle.com/metalink/plsql/f?p=130:14:1058796320950...2 of 3 5/26/2009 10:52 PM

You're Reading a Free Preview

Download
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->