Here's what I just got from OWS:
----------------------------------------
"After further research, this is a known issue that has development feed
back as follows:
BUG:1348362 'SQL EXECUTION' INFORMATION IN V$SESSION_LONGOPS IS INACCURATE
WHEN SORTING
Status: 92,Closed, Not a Bug
This is not a bug.. it is expected behaviour. As PQ relies on several slave
processes to complete their partial work and report the statistics, and a
co-ordinator to aggregate them and update the statistics, it is inherent in
PQ execution model that updates to statistics is not smooth and in some
particular cases it is possible that execution is 100% complete before
updates are made. So I think it should be treated as limition of our PQ
architecture rather than as a bug. Any attempt to guaruntee the smoothness
of progress of 'SQL Execution' operation will call for change in design and
architecture of PQ execution model. So I would treat this as not a bug, but
a limitation which can not be fixed."
----------------------------------------
NOW THAT WAS ENTERTAINING!!! :-)
Oracle Customer: Looks like a bug, walks like a bug, talks like a bug...
Oracle Support: No, it's really just another innocuous insect.
Steve Orr
-----Original Message-----
Sent: Thursday, March 07, 2002 2:13 PM
To: '[EMAIL PROTECTED]'
Well here's what's curious...
Notice the changing SID-serial# with the same sql address and hash.
Notice how elapsed seconds gyrates. Elapsed seconds goes from zero to
447,507,719 yet there were only a few seconds between the queries. How can a
session with 447,507,719 seconds of elapsed time suddenly appear??? Why are
there sessions going back to November when the computer hasn't even been up
that long? None of the sessions in V$SESSION_LONGOPS are in V$SESSION. The
sql
address and hash is not extant in V$SQL, V$SQLAREA, etc. Is this view
supposed to behave this way?
-----Original Message-----
No it is not broken, unless someone explicitly updates underlying
information it is not visible .... I monitor this when I am creating or
rebuilding indexes to importing ... at that time Oracle will populate
relevant fields, and that is really useful.
Raj
______________________________________________________
Rajendra Jamadagni MIS, ESPN Inc.
-----Original Message-----
Sent: Thursday, March 07, 2002 1:19 PM
To: Multiple recipients of list ORACLE-L
Is my V$SESSION_LONGOPS view broken?
Check out the curious results below. Notice the changing SID-serial# and how
elapsed seconds gyrates. None of the below sessions are in V$SESSION. The
sql address and hash is not extant in V$SQL, V$SQLAREA, etc. (Note, we are
using PQO with timed statistics.)
------------------------------------------------------------
col SID-ser# format a10
col secs format 999,999,999 heading "Elapsed|Seconds"
col addhash format a15 heading "SQL Address|Hash"
select substr(lo.sid||'-'||lo.serial#,1,10) "SID-Ser#",
lo.last_update_time "Last Update",
lo.elapsed_seconds secs,
lo.sql_address||'-'||lo.sql_hash_value addhash
from v$session_longops lo
where lo.username not like 'SYS%'
/
Elapsed SQL Address
SID-Ser# Last Update Seconds Hash
---------- ------------------- ------------ ---------------
30-6021 11/28/2001 23:20:21 77 095B5B94-0
30-6021 11/28/2001 23:21:35 74 095B5B94-0
30-6021 11/28/2001 23:22:21 46 095B5B94-0
30-6021 11/28/2001 23:23:24 62 095B5B94-0
30-6021 11/28/2001 23:24:26 62 095B5B94-0
24-3435 11/28/2001 23:59:30 9 59D39B8C-363345
30-7110 11/29/2001 00:40:21 9 59D39B8C-363345
73-2593 03/07/2002 11:39:54 447,507,594 56B9FA30-792775
SQL>/
Elapsed SQL Address
SID-Ser# Last Update Seconds Hash
---------- ------------------- ------------ ---------------
30-6021 11/28/2001 23:20:21 77 095B5B94-0
30-6021 11/28/2001 23:21:35 74 095B5B94-0
30-6021 11/28/2001 23:22:21 46 095B5B94-0
30-6021 11/28/2001 23:23:24 62 095B5B94-0
30-6021 11/28/2001 23:24:26 62 095B5B94-0
24-3435 11/28/2001 23:59:30 9 59D39B8C-363345
30-7110 11/29/2001 00:40:21 9 59D39B8C-363345
51-61397 03/07/2002 11:40:52 0 56B9FA30-792775
SQL>/
Elapsed SQL Address
SID-Ser# Last Update Seconds Hash
---------- ------------------- ------------ ---------------
30-6021 11/28/2001 23:20:21 77 095B5B94-0
30-6021 11/28/2001 23:21:35 74 095B5B94-0
30-6021 11/28/2001 23:22:21 46 095B5B94-0
30-6021 11/28/2001 23:23:24 62 095B5B94-0
30-6021 11/28/2001 23:24:26 62 095B5B94-0
24-3435 11/28/2001 23:59:30 9 59D39B8C-363345
30-7110 11/29/2001 00:40:21 9 59D39B8C-363345
63-34890 03/07/2002 11:41:59 447,507,719 56B9FA30-792775
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: Orr, Steve
INET: [EMAIL PROTECTED]
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: [EMAIL PROTECTED] (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).
