RE: what is the sql doing?

From: Molina, Gerardo <Gerardo.Molina_at_schwab.com>
Date: Wed, 26 Jun 2002 09:43:24 -0800
Message-ID: <F001.00488EBA.20020626094324@fatcity.com>

Try RULE hint. Sometimes, queries against data dictionary perform much better with RULE hint.

HTH,
Gerardo

-----Original Message-----
Sent: Wednesday, June 26, 2002 8:48 AM
To: Multiple recipients of list ORACLE-L

hi, dbas:

        This is the quesiton i met, see if someone can explain it to me, Sun Solaris 7 with 12CPU/12G mem.
Oracle 8.1.7.2 64bit.
About 350 concurrent connected users.
Simple SQL:
SQL> set linesize 200
SQL> alter session set events '10046 trace name context forever,level 12';

Session altered.

Elapsed: 00:00:00.04
SQL> select username,event,sum(total_waits),sum(total_timeouts
),sum(time_waited),avg(average_wait),max(max_wait)

2 from v$session a,v$session_event b
3 where a.sid=b.sid
4 group by username,event;

It takes this long time:
145 rows selected.

Elapsed: 00:03:30.02

During the time the sql is executing, the process is consuming 100% of a single cpu.(from top)
And during the time the sql is executing, the wait event is like:(i execute the sql via perfstat user)

SQL> select sid,event,p1,p2 from v$session_wait where sid in(select sid from v$session where username='PERFSTAT');

SID EVENT

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

P1 P2
---------- ----------
100 SQL*Net message from client
1650815232 1

What is going on on earth?
And through the trace file tkprof from the 9i :

select username,event,sum(total_waits),sum(total_timeouts
),sum(time_waited),avg(average_wait),max(max_wait)

from v$session a,v$session_event b
where a.sid=b.sid
group by username,event

call count cpu elapsed disk query current rows ------- ------ -------- ---------- ---------- ---------- ----------

---

Parse 1 0.02 0.05 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 11 207.72 209.87 0 0 0 145
------- ------ -------- ---------- ---------- ---------- ----------

---

total 13 207.74 209.92 0 0 0 145

Misses in library cache during parse: 1 Optimizer goal: FIRST_ROWS
Parsing user id: 62

Rows Row Source Operation

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

145 SORT GROUP BY
2903 NESTED LOOPS
2904 NESTED LOOPS
365 FIXED TABLE FULL X$KSUSE
3267 FIXED TABLE FULL X$KSLES
2903 FIXED TABLE FIXED INDEX #2 X$KSLED Elapsed times include waiting on following events: Event waited on Times Max. Wait Total Waited

---------------------------------------- Waited ---------- ------------ 

SQL*Net message to client 11 0.00 0.00
SQL*Net message from client 11 332.38 332.43

Can someone explain it for me?

Good luck

            chaos
            chaospku_at_163.net

zhu chao
DBA of Eachnet.com
86-021-32174588-667

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: chaos
  INET: chaospku_at_163.net

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: Molina, Gerardo
  INET: Gerardo.Molina_at_schwab.com

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).

Received on Wed Jun 26 2002 - 12:43:24 CDT