Good catch.  It was showing  Waited Known Time, and  the seconds_in_wait  kept 
increasing.  I was fooled by the latter being incremented each time v$session_event 
was queried.  I did run a trace on it to track the waits, but had to kill the session. 
 I've never gotten dbms_system session traces to  work.  They never return anything 
even on newly rebooted machines.  

Ian MacGregor

-----Original Message-----
Sent: Saturday, September 20, 2003 4:05 AM
To: Multiple recipients of list ORACLE-L


Hi!

How do you verify that your session is still waiting on sequential read? From 
v$session_event? Is the status column saying WAITING there? (if it says WAITED%, then 
your CPU is doing something else already, and this record in session wait just shows 
the last wait).

Tanel.
----- Original Message ----- 
To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]>
Sent: Saturday, September 20, 2003 12:54 AM


> SQL> describe chanarch_nlc.archive_wave_i
>  Name                                      Null?    Type
>  ----------------------------------------- -------- 
> ----------------------
----
>  PV_ID                                              NUMBER(38)
>  TIMESTAMP                                          DATE
>  NANOSECS                                           NUMBER(9)
>  STAT                                               NUMBER(8)
>  SEVR                                               NUMBER(8)
>  OSTAT                                              NUMBER(16)
>  VALUE
CHANARCH_NLC.INT_VALUES
>
> SQL> describe chanarch_nlc.arch_wave_i
>  Name                                      Null?    Type
>  ----------------------------------------- -------- 
> ----------------------
----
>  PV_ID                                              NUMBER(38)
>  TIMESTAMP                                          DATE
>  NANOSECS                                           NUMBER(9)
>  STAT                                               NUMBER(8)
>  SEVR                                               NUMBER(8)
>  OSTAT                                              NUMBER(16)
>  VALUE
CHANARCH_NLC.INT_VALUES
>
>
>
>
> SQL> describe chanarch_nlc.int_values
>  chanarch_nlc.int_values VARRAY(16384) OF NUMBER(38)
>
> Select * from chanarch_nlc.arch_wave_i
> Where pv_id = 433 and
> Timestamp between '18-SEP-2003:13:48:00' AND '18-SEP-2003:13:49:00' 
> ORDER BY TIMESTAMP, NANOSECONDS /
>
> Returns 1 row plus the associated varray data in one second
>
> Select * from chanarch_nlc.archive_wave_i
> Where pv_id = 433 and
> Timestamp between '18-SEP-2003:13:48:00' AND '18-SEP-2003:13:49:00' 
> ORDER BY TIMESTAMP, NANOSECONDS
>
> Returns 0 rows in  about a second
>
> Select * from chanarch_nlc.arch_wave_i
> Where pv_id = 433 and
> Timestamp between '18-SEP-2003:13:48:00' AND '18-SEP-2003:13:49:00' 
> Union all Select * from chanarch_nlc.archive_wave_i
> Where pv_id = 433 and
> Timestamp between '18-SEP-2003:13:48:00' AND '18-SEP-2003:13:49:00'
>
> Returns a single row with the varray data in a second
>
> However
>
> Select * from chanarch_nlc.arch_wave_i
> Where pv_id = 433 and
> Timestamp between '18-SEP-2003:13:48:00' AND '18-SEP-2003:13:49:00' 
> Union all Select * from chanarch_nlc.archive_wave_i
> Where pv_id = 433 and
> Timestamp between '18-SEP-2003:13:48:00' AND '18-SEP-2003:13:49:00'
> Order by 2,3
>
> Never returns.  It waits forever on a sequential dbfile read event of 
> one
the files used by the lob  segment which contains the varray data for the value column 
of chanarch_nlc.arch_wave_i.  Nothing appears to be blocking the session.  The query 
plan is as one would expect.
>
> Similar queries  against different  tables with the same structure 
> proceed
without incident.
>
> Ian MacGregor
> Stanford Linear Accelerator Center
> [EMAIL PROTECTED]
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.net
> -- 
> Author: MacGregor, Ian A.
>   INET: [EMAIL PROTECTED]
>
> Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
> San Diego, California        -- Mailing list and web hosting services
> ---------------------------------------------------------------------
> 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).
>


-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Tanel Poder
  INET: [EMAIL PROTECTED]

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
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).
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: MacGregor, Ian A.
  INET: [EMAIL PROTECTED]

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
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).

Reply via email to