Re: Need advice about Result Cache size allocation

From: Michael Moore <michaeljmoore_at_gmail.com>
Date: Wed, 30 Mar 2011 15:14:10 -0700
Message-ID: <AANLkTinemJ-5e1xpkOqz35+uJk6+gCEb9+eDtjKv1X0X_at_mail.gmail.com>



Ellis, makes sense. I'll see If I can get that changed. Niall, thanks for the link, I'll check it out.

Mike

On Wed, Mar 30, 2011 at 2:24 PM, Niall Litchfield < niall.litchfield_at_gmail.com> wrote:

> Hi Michael
>
> Thanks - possibly this article
> http://www.oracle-developer.net/display.php?id=503 might give more help.
> I'm afraid I don't know squat about result cache (other than what it is) to
> help more, hence my earlier curiosity. A brief read of the docs suggests
> that the designers of the feature expect developers to know how much and
> what size is going to be cached. A brief read of the available blogs
> suggests this might be optimistic.
>
> On Wed, Mar 30, 2011 at 9:15 PM, Michael Moore <michaeljmoore_at_gmail.com>wrote:
>
>> Niall,
>> this produces the report.
>>
>>
>> BEGIN
>> SYS.DBMS_Result_Cache.Memory_Report(Detailed=>TRUE);
>> END;
>> /
>>
>> I just ran it again and the results are very different in the last two
>> lines.
>>
>> R e s u l t C a c h e M e m o r y R e p o r t
>> [Parameters]
>> Block Size = 1K bytes
>> Maximum Cache Size = 10M bytes (10K blocks)
>> Maximum Result Size = 512K bytes (512 blocks)
>> [Memory]
>> Total Memory = 9657800 bytes [0.593% of the Shared Pool]
>> ... Fixed Memory = 5352 bytes [0.000% of the Shared Pool]
>> ....... Memory Mgr = 200 bytes
>> ....... Cache Mgr = 208 bytes
>> ....... Bloom Fltr = 2K bytes
>> ....... State Objs = 2896 bytes
>> ... Dynamic Memory = 9652448 bytes [0.593% of the Shared Pool]
>> ....... Overhead = 149728 bytes
>> ........... Hash Table = 64K bytes (4K buckets)
>> ........... Chunk Ptrs = 24K bytes (3K slots)
>> ........... Chunk Maps = 12K bytes
>> ........... Miscellaneous = 47328 bytes
>> ....... Cache Memory = 9280K bytes (9280 blocks)
>> ........... Unused Memory = 29 blocks
>> ........... Used Memory = 9251 blocks
>> ............... Dependencies = 5 blocks (5 count)
>> ............... Results = 9246 blocks
>> ................... PLSQL = 9246 blocks (9246 count)
>> PL/SQL procedure successfully completed.
>>
>> On Wed, Mar 30, 2011 at 1:08 PM, Niall Litchfield <
>> niall.litchfield_at_gmail.com> wrote:
>>
>>> I've not seen that report before but I'd be interested in what the
>>> invalid results mean - looks like you have 1 valid cached result and 7802
>>> invalid cached results.
>>>
>>>
>>> On Wed, Mar 30, 2011 at 8:49 PM, Michael Moore <michaeljmoore_at_gmail.com>wrote:
>>>
>>>> R e s u l t C a c h e M e m o r y R e p o r t
>>>> [Parameters]
>>>> Block Size = 1K bytes
>>>> Maximum Cache Size = 10M bytes (10K blocks)
>>>> Maximum Result Size = 512K bytes (512 blocks)
>>>> [Memory]
>>>> Total Memory = 8147504 bytes [0.501% of the Shared Pool]
>>>> ... Fixed Memory = 5352 bytes [0.000% of the Shared Pool]
>>>> ....... Memory Mgr = 200 bytes
>>>> ....... Cache Mgr = 208 bytes
>>>> ....... Bloom Fltr = 2K bytes
>>>> ....... State Objs = 2896 bytes
>>>> ... Dynamic Memory = 8142152 bytes [0.500% of the Shared Pool]
>>>> ....... Overhead = 146760 bytes
>>>> ........... Hash Table = 64K bytes (4K buckets)
>>>> ........... Chunk Ptrs = 24K bytes (3K slots)
>>>> ........... Chunk Maps = 12K bytes
>>>> ........... Miscellaneous = 44360 bytes
>>>> ....... Cache Memory = 7808K bytes (7808 blocks)
>>>> ........... Unused Memory = 0 blocks
>>>> ........... Used Memory = 7808 blocks
>>>> ............... Dependencies = 5 blocks (5 count)
>>>> ............... Results = 7803 blocks
>>>> ................... PLSQL = 1 blocks (1 count)
>>>> ................... Invalid = 7802 blocks (7802 count)
>>>> PL/SQL procedure successfully completed.
>>>>
>>>> How can I tell if the DBA's have allocated enough space?
>>>>
>>>> Regards,
>>>> Mike
>>>>
>>>
>>>
>>>
>>> --
>>> Niall Litchfield
>>> Oracle DBA
>>> http://www.orawin.info
>>>
>>
>>
>
>
> --
> Niall Litchfield
> Oracle DBA
> http://www.orawin.info
>

--
http://www.freelists.org/webpage/oracle-l
Received on Wed Mar 30 2011 - 17:14:10 CDT

Original text of this message