Hi Martin,
 
Thanks, okay if I want to find this gain or nogain in statspack report, is there any stats anywhere in namespace or instance statistics?
 
am looking to prove this in statistical way instead of thinking, one way to look from v$librarychahe, but lets say for a given hash value if there are 10 objects are being accessed, how do we distinguish each object reloads?
 
Reg, Venkat
 
 
 

Martin Berg <martin@(protected):
Venkat Rao wrote:
> Hi Martin,
>
> Thank you very much for good reply, okay is it possible to find the reloads on a particular objects from v$librarycache?
>
> or from v$segment_statistics ===? I can't see even parse waits from this view?
>
> any pinpoints in statspack report on this reload would be also great, my statspack report shows only reloads on sqlarea nowere else...
>
>
> Reg,
> Venkat
>
>

Reloads are relevant for the library cache - not for segments (= forget
v$segment_statistics),
but you can't see object information in v$librarycache.

Reloads in statspack are gathered from the reloads column in v$librarycache.

Reloads in the sql_area are reloads of SQL - not
packages/funtions/procedures.
This can happen for more reasons than just lack of space - a brief list
includes:
varying bind-variable lengths, invalidation of objects lower in the
dependency tree,
poor cursor management etc.

Try to do a select sql_text, reloads from v$sql where reloads > 1 and
parsing_schema_id !=0

This should give you a feeling about the objects that gets reloaded.
--
Med venlig hilsen

Martin Berg

email: martin@(protected)
web: www.berg-consult.com
mobil: 30 35 58 68


--
To unsubscribe, email: suse-oracle-unsubscribe@(protected)
For additional commands, email: suse-oracle-help@(protected)
Please see http://www.suse.com/oracle/ before posting



Send instant messages to your online friends http://uk.messenger.yahoo.com