I see what you're concerned about. The recent sessions' operations are getting aged out of v$session_longops almost as soon as they are done, and there are a bunch of old sessions' operations sitting around in there from last November.
Looking at some of my systems, I see a couple stragglers from long ago sitting in there, but it doesn't seem to be hurting anything. Yours does look a little broken. The entries in v$session_longops should survive beyond the session disconnecting. Note that you are cutting off your sql hash value with the column command and also combining it with SQL Address, which is why it doesn't match anything. In general though, it looks like your v$session_longops is correctly displaying long operations as they are occurring, which is what most people watch v$session_longops for. Does anyone know what governs how long entries in v$session_longops are preserved? -- Jeremiah Wilton http://www.speakeasy.net/~jwilton On Thu, 7 Mar 2002, Orr, Steve wrote: > 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: Jeremiah Wilton 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).
