Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Mailing Lists -> Oracle-L -> RE: Manual mem management in 10g

RE: Manual mem management in 10g

From: Allen, Brandon <Brandon.Allen_at_OneNeck.com>
Date: Fri, 30 Jun 2006 10:44:48 -0700
Message-ID: <04DDF147ED3A0D42B48A48A18D574C45059E19E3@NT15.oneneck.corp> 





Looking back at the history (see below), I can see the "KGH: NO ACCESS"
does grow and shrink regularly, so it doesn't seem to be a constantly
worsening problem, but the name is certainly discomforting.  I've opened
an SR on this and a few other sga_target related questions.  I'll come
back and post the results if I get anything good.



Did you eventually run into errors as KGH: NO ACCESS grew, or did you
just turn off sga_target as a preemptive move?




SQL> select a.begin_interval_time, b.bytes from wrm$_snapshot a,
dba_hist_sgastat b where a.snap_id = b.snap_id and a.begin_interval_time


> sysdate -2 and b.pool = 'shared pool' and b.name = 'KGH: NO ACCESS'

order by 1;



BEGIN_INTERVAL_TIME



BYTES







191 rows selected.



-----Original Message-----


From: Schultz, Charles [mailto:sac_at_uillinois.edu] 
Sent: Friday, June 30, 2006 10:28 AM


To: Allen, Brandon; topshot.rhit_at_gmail.com; oracle-l_at_freelists.org
Subject: RE: Manual mem management in 10g



Before we set sga_target = 0, we were seeing "KGH: NO ACCESS" grow to
over 50% of the shared_pool. Support would only say that this was used
to temporarily transfer data from the buffer cache to the shared_pool,
but they never did disclose why so much, or how, or when, or....



Would you really want most of your memory tied up in something called
"NO ACCESS"? *grin* 



-----Original Message-----


From: oracle-l-bounce_at_freelists.org


[mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Allen, Brandon
Sent: Friday, June 30, 2006 11:25 AM


To: topshot.rhit_at_gmail.com; oracle-l_at_freelists.org
Subject: RE: Manual mem management in 10g



I'm growing concerned about the same thing after seeing some of the
comments on this list.  I just implemented my first 10g system (10.2.0.2
on AIX 5.3) about a month ago and I decided to go out on a limb and use
the new gather_stats_job and sga_target.  So far, our performance has
been excellent and we haven't had any problems with memory errors, but
after all the problems I've seen on this list I'm increasingly worried
that I may be sitting on a time bomb and maybe I should change back to
manual memory management before it explodes.  I've just recently started
keeping a closer eye on v$sgastat, hoping that I can catch any problems
before they get out of hand.  A couple odd things I've noticed - a lot
of free memory in the shared pool, even though ADDM keeps telling me I
need to increase my SGA, and a lot of memory allocated to "KGH: NO
ACCESS":


SQL> select * from v$sgastat where bytes > 10000000 order by 3;


POOL         NAME                            BYTES
------------ -------------------------- ----------
shared pool  private strands              11624448
shared pool  KQR M PO                     13381408
             log_buffer                   14700544
shared pool  obj stat memo                16219416
shared pool  ASH buffers                  16252928
java pool    free memory                  16777216
shared pool  Cursor Stats                 17322216
shared pool  kglsim heap                  17627904
shared pool  PCursor                      23200608
shared pool  CCursor                      29468216
shared pool  kglsim object batch          31205664
shared pool  library cache                31840456
shared pool  KGLS heap                    50571752
large pool   free memory                  62080224
shared pool  sql area                    176615248
shared pool  KGH: NO ACCESS              480967264
shared pool  free memory                 655483792
             buffer_cache               1241513984






Anyone else seeing the same pattern?  Have an explanation?



Thanks,


Brandon



Privileged/Confidential Information may be contained in this message or
attachments hereto. Please advise immediately if you or your employer do
not consent to Internet email for messages of this kind. Opinions,
conclusions and other information in this message that do not relate to
the official business of this company shall be understood as neither
given nor endorsed by it.


--
http://www.freelists.org/webpage/oracle-l


--
http://www.freelists.org/webpage/oracle-l


Received on Fri Jun 30 2006 - 12:44:48 CDT












Original text of this message













  HOME |
  ASK QUESTION |
  ADD INFO |
  SEARCH |
  E-MAIL US