RE: Manual mem management in 10g
- From: "Allen, Brandon" <Brandon.Allen@xxxxxxxxxxx>
- To: <topshot.rhit@xxxxxxxxx>, <oracle-l@xxxxxxxxxxxxx>
- Date: Fri, 30 Jun 2006 09:25:05 -0700
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.
--
//www.freelists.org/webpage/oracle-l
Other related posts:
