Re: How to use event 10390?
- From: Janine Sisk <janine@xxxxxxxxxx>
- To: tanel.poder.003@xxxxxxx
- Date: Wed, 15 Sep 2004 16:15:22 -0400
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
--
//www.freelists.org/webpage/oracle-l
Other related posts:
