Re: How to use event 10390?

From: Janine Sisk <janine_at_furfly.net>
Date: Wed, 15 Sep 2004 16:15:22 -0400
Message-Id: <F904348A-0753-11D9-B6F5-000393AED29A@furfly.net>

On Sep 15, 2004, at 4:00 PM, Tanel P=F5der wrote:

> But is this really what you want to know? Do you just want to see =
10046
> trace for your slave processes?

What I want is to see an accurate trace of the query running with=20 parallel query turned on, so I can be sure that when I turn it off the=20=

query is running at least as efficiently as it was before.

 =46rom the message I posted yesterday (which may not have gone out, = since=20
no-one responded):

tkprof output with parallel query on:

call     count       cpu    elapsed       disk      query    current
      rows

------- ------ -------- ---------- ---------- ---------- ----------

---

Parse        1      0.01       0.01          0          0          0
         0
Execute      1      0.00       0.06          0          0          3
         0
Fetch        2      0.01       0.12          0         73          0
         1

------- ------ -------- ---------- ---------- ---------- ----------

---

total        4      0.02       0.19          0         73          3
         1

Misses in library cache during parse: 1
Optimizer goal: CHOOSE
Parsing user id: 38

Rows Row Source Operation

-------  ---------------------------------------------------
        1  SORT AGGREGATE
        0   SORT AGGREGATE
        0    NESTED LOOPS
        0     HASH JOIN
        0      TABLE ACCESS BY INDEX ROWID ACS_RELS
      109       INDEX RANGE SCAN (object id 26428)
        0      TABLE ACCESS FULL MEMBERSHIP_RELS
        0     INDEX UNIQUE SCAN (object id 26694)

tkprof output with parallel query off:

call     count       cpu    elapsed       disk      query    current
      rows

------- ------ -------- ---------- ---------- ---------- ----------

---

Parse        1      0.00       0.00          0          0          0
         0
Execute      1      0.00       0.00          0          0          0
         0
Fetch        2      0.16       0.16          0        657          6
         1

------- ------ -------- ---------- ---------- ---------- ----------

---

total        4      0.16       0.16          0        657          6
         1

Misses in library cache during parse: 1
Optimizer goal: CHOOSE
Parsing user id: 38

Rows Row Source Operation

-------  ---------------------------------------------------
        1  SORT AGGREGATE
      108   NESTED LOOPS
      109    HASH JOIN
      108     TABLE ACCESS BY INDEX ROWID ACS_RELS
      109      INDEX RANGE SCAN (object id 26428)
   170140     TABLE ACCESS FULL MEMBERSHIP_RELS
      108    INDEX UNIQUE SCAN (object id 26694)

Although the elapsed time was a bit smaller for the case where parallel=20=

query is off (which is what I was hoping to see), it looks like it did=20=

a bit more work, and I was perplexed by that. So I'd like to see the=20 work being done by the slaves in the first case, so I can verify that=20 it's about the same either way.

thanks!

janine

--
http://www.freelists.org/webpage/oracle-l

Received on Wed Sep 15 2004 - 15:11:02 CDT