Java Mailing List Archive

http://www.dba.5341.com/

Home » Home (12/2007) » oracle l »

RE: Manual mem management in 10g

oracle l bounce

2006-06-30

Replies:

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@(protected)
[mailto:oracle-l-bounce@(protected)
Sent: Friday, June 30, 2006 11:25 AM
To: topshot.rhit@(protected)
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


©2008 dba.5341.com - Jax Systems, LLC, U.S.A.