Re: KQR L PO
- From: Taral Desai <taral.desai@xxxxxxxxx>
- To: tanel@xxxxxxxxxx
- Date: Mon, 18 Oct 2010 13:26:48 -0500
*Latch Contention with KQR X PO consuming lots of memory and Database Hang
[ID 289717.1]*
KQR X PO or KQR M PO entries are part of dictionary cache.
Any job that could be filling the dictionary cache can cause this problem.
For example, a job that generates histograms on a table that has huge number
of
columns is can cause huge number of KQR chunks
On Mon, Oct 18, 2010 at 1:20 PM, Tanel Poder <tanel@xxxxxxxxxx> wrote:
> KQR L PO stands for *K*ernel *Q*uery layer *R*ow cache *L*arge *P*arent *O
> *bject. These are dictionary cache objects.
>
> So, you either have a row cache object leak (less likely) or just a lot of
> objects to keep in row cache (row cache = dictionary cache).
>
> For example, if you have a lots of tables with lots of columns and all of
> these columns have histograms, then you'll have lots of histogram data
> cached in dictionary cache's *dc_histogram_defs* section.
>
> So, you should run something like this, to see what kind of rowcache
> objects use all this memory:
>
> select * from v$rowcache order by usage;
>
> Once you find the top consumer, you can use AWR's DBA_HIST_ROWCACHE_SUMMARY
> to see how these values have changed over time...
>
> --
> Tanel Poder
> New virtual conference and online seminars!
> http://tech.e2sn.com/virtual-conferences
> http://tech.e2sn.com/oracle-training-seminars
>
>
>
> On Mon, Oct 18, 2010 at 8:49 PM, Grzegorz Goryszewski <
> grzegorzof@xxxxxxxxxx> wrote:
>
>> Google and MOS are quite mysterious about that .
>> KQR L PO is huge allocation in my RAC shared pool , and I dont got idea
>> what could cause that .
>> Regards.
>> Greg
>>
>
--
Thanks & Regards,
Taral Desai
Other related posts:
