RE: Long Parse Time
- From: "Tanel Poder" <tanel@xxxxxxxxxx>
- To: <yong321@xxxxxxxxx>
- Date: Sun, 10 May 2009 19:38:18 +0200
Comments below..
> -----Original Message-----
> From: Yong Huang [mailto:yong321@xxxxxxxxx]
> Sent: 10 May 2009 01:41
> To: tanel@xxxxxxxxxx
> Cc: oracle-l@xxxxxxxxxxxxx
> 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
--
//www.freelists.org/webpage/oracle-l
Other related posts:
