DBWR must write blocks to the datafiles and ensure they get written. These blocks are protected by redo in the oneline redo log. Before we can reuse a redo log file, we must ensure that the blocks protected by that redo are safely and totally written to disk. DBWR can do this in one of two ways. Lets say DBWR has 100 blocks to write to disk. It could: for i in 1 .. 100 loop write block X to disk and wait for the OS to tell us the operation is totally complete (the block is not buffered by the OS or anything, it is on disk) end loop As you can imagine, that would be slow. For each block, we would have to wait for the OS to tell us the block is written. If there was any contention on that disk (eg: another process was reading /writeing that disk), we would have to wait event longer. Another way is to write the block to disk and not wait for the OS to tell us the block has been written. rather, the OS will "call back" to us and tell us that block X was written. The logic might look like this: for i in 1 .. 100 loop write block X and return immediately, don't wait end loop now wait for the 100 blocks to "call back" to us, let the OS do its work and wait. In this case, we give the OS all of the work we want done and let it schedule it as fast as it can. While it is off doing its thing, we are submitting yet more blocks to be written. We can get some parallel processing going on here and things go faster. When the OS does not support async IO, we can use mutliple processes to mimick it. DBWR will use the slaves to do the syncronous writes and use many of them simultaneously. When the slaves are done, they call be to DBWR just like the OS would.
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/10972173/viewspace-511897/，如需转载，请注明出处，否则将追究法律责任。