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

Home -> Community -> Usenet -> c.d.o.server -> Re: large PGA_AGGREGATE_TARGET value problems

Re: large PGA_AGGREGATE_TARGET value problems

From: James McCudden <james.mccudden_at_mckesson.com>
Date: 28 Jan 2004 07:12:05 -0800
Message-ID: <5b8af1c7.0401280712.4176b509@posting.google.com>


Thanks. I forget to note that that is, in fact, our workaround. Using the manual memory settings with a big fat S_A_S allows the system to run fine. Oracle has now at least logged this is a bug in 9.2.0.4. Whether any resolution will happen (with 10g on the horizon) remains to be seen. It (the infinitely spinning process) is also not predicatable or repeatable (except in one case so far), which makes it tough to give them a test case.
Also, when the shadow process is spinning, it does not respond to dbms_system.set_ev() commands to show the event trace.

James

"Telemachus" <Zaka_at_twibbles.99.net> wrote in message news:<ZvvRb.376$rb.51715_at_news.indigo.ie>...
> Perhaps it thinks it can fit all of one table in memory and switches access
> plan accordingly ?
>
> does use of SQL*Analyze show a difference when you play around with the
> value ? although I've a feeling you might need to do a workarea size policy
> =manual and watch the numbers yerselves for S_A_S,H_A_S,B_A_S
>
> Alternatively there's always 10053 output to diagnose the optimizer choices
> although the reading is a little abstruse
Received on Wed Jan 28 2004 - 09:12:05 CST

Original text of this message

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