引用

*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

• References:
  • KQR L PO
    • From: Grzegorz Goryszewski
  • Re: KQR L PO
    • From: Tanel Poder