RE: Long Parse Time

> -----Original Message-----
> From: Yong Huang [mailto:yong321_at_yahoo.com]
> Sent: 10 May 2009 01:41
> To: tanel_at_poderc.com
> Cc: oracle-l_at_freelists.org
> Subject: RE: Long Parse Time
>
>

...
>
> Pipe buffer is not the same as, e.g., TCP buffer or
> dbms_output buffer (where before the buffer is full, you see
> nothing coming out), in the sense that 99% of the time when
> we use a UNIX pipe, a reader that can drain the buffer
> already awaits. Although we have a few KB pipe buffer (from
> getconf), the reader immediately "extracts" (reads) what's in
> the buffer. The buffer does have the other use, i.e. when

It's never "immediate". The reader has to get onto CPU to perform the read - if your CPUs are busy you'll see some delays here. So instead of seeing timestamps of trace line generation time (scattered over time as they happened) you'd see "bursts" of timestamps which are generated when the readed happened to be on CPU. With idle CPUs its less of a problem but for busy systems this can become unreliable for getting highly accurate timestamps.

Btw, dbms_output doesn't somehow flush parts of output data once buffer is full, the buffer has to be able to hold all dbms_output data generated during the database call. If the buffer limit is exceeded (if unlimited buffer size isn't used) then we get a buffer overflow exception and the call is terminated. It's the client (sqlplus) process which has to call dbms_output.get_lines() once the previous database call is completed. (The get_lines procedure fetches the output data from the session heap for display).

--
Regards,
Tanel Poder
http://blog.tanelpoder.com

--
http://www.freelists.org/webpage/oracle-l