Re: async i/o via nfs?

"Nuno Souto" <wizofoz2k_at_yahoo.com.au> schrieb im Newsbeitrag news:73e20c6c.0308061638.7bcee796_at_posting.google.com...
> "Volker Hetzer" <volker.hetzer_at_ieee.org> wrote in message
news:<bgra0h$j3$1_at_news.fujitsu-siemens.com>...
> Well, look at it this way:
>
> Oracle does not do some "misterious, behind the scenes" Unix call
> to read and write to disks. It uses the same calls you can use
> in a small C program yourself. Look them up in man pages.
> Mostly file units, read(), write(), ioctl() and a few related ones.
> "truss" the Oracle code if you want to get a detailed list of all
> Unix calls it makes. You'll see there are no undocumented or hidden
> calls there.

Ok, I don't know about async i/o but what I had assumed is that oracle does some kind of out-of-band return value collection and errno check so that no stati get lost.

> As such, async I/O is not some strange kind of I/O. It's just an
> option when you open a file and associate it with a file unit.
> If you pour through the relevant man pages in your OS, you should
> be able to find if it supports that flag on I/O to an nfs file
> system. Check the nfs man pages as well. It should all be there.
Did. Thanks! Only, apart from the O_SYNC flag I got not much more. I'll check some more.

> The reason you won't find any firm reply on this is that
> none of the people here would even remotely consider using nfs
> for anything related to database datafiles, control files,
> redo log files or indeed any db files! As simple as that.
Okay, but only if I truly understand advice I can properly see whether it's relevant implementing or fighting with my boss over. Because first, things change and reliability of disks or nfs systems changes too and second, every environment is different and the availability/performance /safety requirements are different for every environment.

> For a variety of reasons, mostly to do with this paranoia that DBAs
> have that data is to be written/read to/from good ole hard disk.
Yeah, right. During my first three months I had two real problems: 1) a defective board which caused oracle to write wrong data to the disk

    without noticing it for several days. "Notification" came when a select     complained about corrupt data. Naturally, the corrupt data was in the     archived redo logs too, so no means of recovery. Errors were sprinkled     across all sorts of tables. Fortunately we were still testing so no harm done.
2) I had a whole raid system crashing (several raid1 pairs) because one

    disk was damaged, when pulled out the hotspare didn't kick in and then     the controller gave up. We were still testing, so no problem just experience.

After that local disks are definitely not the holy grail of storage for me anymore
but just one part in the safety architecture which can fail like everything else. Or
administrated into failing. So I've got to guard against local disk/system/people
failure as well.
So far my strategy is to have some files mirrored on a system that gets administered by
a different group, runs a different OS and has a completely different hardware.

I'm still trying to figure out whether there are better strategies around. Next I'll
do standby databases which should eliminate the control file mirroring to another
system at least for the production database.

> Not packets clashing in a thin wire. As such, the experience in
> using nfs will be very thin... ;D

Ok, understood.

Lots of Greetings and thanks!
Volker Received on Thu Aug 07 2003 - 05:59:16 CDT