RE: dbwr_io_slaves usage on sigle cpu microsoft windows

        > As Windows does asynch IO by default, there is probably not too

		much
		        benefit in setting IO slaves.
	>	        ^^^^
		


	>	...in fact, to the contrary...

      >     ...please explain

... db block buffer flushing through slaves is pretty clunky considering you have OS Async, ODM and multiple database writers options. With slaves, DBWR builds a batch and tasks a set of writers who in turn loop through and perform synchronous I/Os of the buffers they were tasked with flushing.

Until all the writes are done and the slaves report back, DBWR is completely idle. So, a write batch operation is only as fast as the slowest sub-set. Consider a batch that consists of, say, 128 buffers.

If you have 16 slaves, it might turn out that the slaves are all tasked evenly so each "sub batch" would consist of 8 synchronous writes. If those
take on average 10ms, and all the other slaves experience similar I/O service times, the master DBWR will be waiting for 80ms...along with all those foreground processes waiting in free buffer wait. With async, ODM or multiple writers, each completed I/O request is followed with LRU handling associated with freeing the buffer...so free buffer waiters don't wait as long. With async, ODM and multiple writers, DBWR processes also build their next batch while previous I/O is in flight. More efficient...especially in systems suffering cache buffers chain latch contention.

Slaves cause an inordinate amount of IPC overhead as well.

Old technology from a bygone day.

The Win32 API offers Oracle very good async I/O handling.

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