Re: lgwr/dbw0 did not issue pwrite64 sys call
- From: Sidney Chen <huanshengchen@xxxxxxxxx>
- To: "D'Hooge Freek" <Freek.DHooge@xxxxxxxxx>
- Date: Mon, 28 Nov 2011 08:53:37 +0800
Freek,
see my reply as below
During the time you traced the lgwr process, it has not written any data.
>
yes, it's writing log data, through the *read* call provide by ASMLIB.
10046 trace is enable on the lgwr and i can see below pair patter. I
believe the write is done by the hightlight *read* call.
16:59:19 read(17,
"MSA\0\2\0\10\0P\0\0\0\222\377\377\377\320\243j\6\0\0\0"..., 80) = 80
<0.000024>
16:59:19 kill(16364, SIGWINCH) = 0 <0.000008>
*16:59:19 read(17,
"MSA\0\2\0\10\0P\0\0\0\0\0\0\0\320\243j\6\0\0\0\0\0\0\0"..., 80) = 80
<0.000507>*
16:59:19 times(NULL) = 844620691 <0.000005>
16:59:19 write(2, "WAIT #0: nam=\'log file parallel "..., 105) = 105
<0.000007>
> Best is to trace the process directly after it has been started (certainly
> before the full table scan is started), so you see also the open calls for
> the datafiles (which will show you which flags are used).
>
>
I flushed the buffer_pool and start strace the server process before doing
a full table scan on a big table, the result confirm the server process is
using below ASMLIB call to do the physical read, and yes, you's right that
ASM instance will not do the physical IO for the redo/datafile. it still
done by lgwr and server process themselves.
...
*read(16, "MSA\0\2\0\10\0P\0\0\0\222\377\377\377@\313\373\5\0\0\0"..., 80) = 80*
...
--
Regards
Sidney Chen
--
//www.freelists.org/webpage/oracle-l
Other related posts:
