wierd runstats_pkg report

From: <ryan.gaffuri_at_cox.net>
Date: Tue, 23 Mar 2004 9:40:32 -0500
Message-Id: <20040323144034.KIWJ21704.lakemtao05.cox.net@smtp.central.cox.net>

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_at_freelists.org put 'unsubscribe' in the subject line.
--

Archives are at http://www.freelists.org/archives/oracle-l/ FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html

Received on Tue Mar 23 2004 - 08:41:03 CST