wierd runstats_pkg report
- From: <ryan.gaffuri@xxxxxxx>
- To: oracle-l@xxxxxxxxxxxxx
- Date: Tue, 23 Mar 2004 9:40:32 -0500
anyone ever see this much of a difference in latch contention and have the
query which uses more resources return faster? All I did was flip the join
order. I can re-write the query and post it later.
just curious if this has happened to anyone.
SQL> exec runstats_pkg.rs_stop(500);
Run1 ran in 1432 hsecs
Run2 ran in 1740 hsecs
run 1 ran in 82.3% of the time
Name Run1 Run2 Diff
STAT...buffer is not pinned co 2,233 1,570 -663
LATCH.library cache pin alloca 1,095 233 -862
LATCH.library cache pin 1,784 347 -1,437
STAT...buffer is pinned count 3,303 1,768 -1,535
STAT...index fetch by key 1,571 3 -1,568
LATCH.shared pool 2,598 570 -2,028
LATCH.library cache 3,423 835 -2,588
STAT...consistent gets - exami 3,406 144 -3,262
STAT...recursive calls 3,709 406 -3,303
STAT...consistent gets 5,502 1,787 -3,715
STAT...session logical reads 6,049 2,334 -3,715
LATCH.cache buffers chains 10,692 6,384 -4,308
STAT...session uga memory 7,936 0 -7,936
Run1 latches total versus runs -- difference and pct
Run1 Run2 Diff Pct
23,389 11,135 -12,254 210.05%
PL/SQL procedure successfully completed.
----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
Other related posts:
