Re: DBWR, Direct I/O and the Devil

I found a post over at Howard Roger's site [0] that had similar errors on a similar configuration. In the end the user (Jeff, I believe) said that the problem was that "the max-aio-size and the veritas aio size mismatched" and that lining up those two settings fixed the problem. He said that the parameter to tune was discovered_direct_iosz.

I then found this description on another site [1]:

discovered_direct_iosz: Any file I/O request larger than the value defined by this parameter will result in an unbuffered I/O without " a synchronous commit of the inode when the file is extended or blocks are allocated." This is similar to direct I/O. The default value is 256K. For random I/O access pattern, unbuffered or direct I/O is preferred. So, to set 100% of the I/O activities to unbuffered I/O, I would expect setting this parameter less than 8K will do the trick.

My limited reading tells me that such parameters are changed in /etc/vx/tunefstab. I don't currently find such a file in my /etc/vx directory. Should I assume then that my current setting is the default 256K? Can any VxFSophiles say how to see the current settings?

[0] http://www.dizwell.com/prod/node/233 [1] http://vegdave.wordpress.com/2007/05/18/vxfs-tuning-notes-from-reading-admin-guide/

On Nov 29, 2007 8:24 AM, Don Seiler <don_at_seiler.us> wrote:
> I made the change to filesystemio_options=setall, and lowered
> db_writer_processes=1 (might be unrelated, just providing fyi).
>
> However I'm now getting this error from RMAN when I try to do my
> archivelog and controlfile backups, which I do every couple of hours.
>
> Starting Control File and SPFILE Autobackup at 29-NOV-07
> RMAN-00571: ===========================================================
> RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
> RMAN-00571: ===========================================================
> RMAN-03009: failure of Control File and SPFILE Autobackup command on ORA_DISK_1
> channel at 11/29/2007 02:00:46
> ORA-19502: write error on file "/rman/c-3171457975-20071129-00",
> blockno 321 (blocksize=16384)
> ORA-27061: waiting for async I/Os failed
> Linux-x86_64 Error: 14: Bad address
> Additional information: -1
> Additional information: 1048576
>
> Here is how my /rman is currently mounted (output from `mount`):
> /dev/vx/dsk/oracle-01/rman-temp on /rman type vxfs
> (rw,delaylog,largefiles,mincache=direct,convosync=direct,ioerror=mwdisable)
>
> Here is one of the datafile partitions, they are all the same:
> /dev/vx/dsk/oracle-01/u22 on /u22 type vxfs
> (rw,delaylog,largefiles,mincache=direct,convosync=direct,noatime,ioerror=mwdisable)
>
> We are not using ODM with our Veritas.
>
> Don.
>
> On Nov 28, 2007 3:22 PM, Don Seiler <don_at_seiler.us> wrote:
>
> > On Nov 28, 2007 3:07 PM, Bobak, Mark <Mark.Bobak_at_il.proquest.com> wrote:
> > > I think you want both direct *and* async I/O configured, if your O/S and filesystem will support it. In that case (with async i/o) you probably will only need 1 DBWR.
> >
> > Alright so I should set filesystemio_options=setall rather than
> > directio? Are there any other parameters to look at?
> >
> > Don't I still need to mount the disk with "mincache=direct,convosync=direct"?
> >
> > > http://www.ixora.com.au/tips/avoid_buffered_io.htm
> > > http://www.ixora.com.au/tips/use_asynchronous_io.htm
> >
> > Yep I've been reading this already.
> >
> > My connotation was that direct I/O the opposite of asynchronous I/O.
> > I'm seeing now that they are more or less independent states of I/O
> > covering different aspects of behavior.
> >
> >
> > --
> > Don Seiler
> > http://seilerwerks.wordpress.com
> > ultimate: http://www.mufc.us
> >
>
>
>
> --
> Don Seiler
> http://seilerwerks.wordpress.com
> ultimate: http://www.mufc.us
>

-- 
Don Seiler
http://seilerwerks.wordpress.com
ultimate: http://www.mufc.us
--
http://www.freelists.org/webpage/oracle-l