Below are some of the points about async i/o which was explained by tom:-
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.
Question:-
Hi Tom,
Now i understood about DBWR SLAVE process.
another question.
Accouring to your reply DBWR process is coordinator and SALVES are the processes which are doing real work.
1)Does that mean there is always DBWR SLAVE process in the database for DBWR process?
2)How many DBWR SLAVE process we can have in database?
I know there is DBWRnnn Parameter in init.ora file.
3)MULTIPLE DBWR SALVE process will distribute dirty buffers write to disk. Am i right?
Answer:-
1) No, if your server supports asynch IO then there would be no point having slaves for the DBWR process since slaves are used to simulate asynch IO
2) There is an init ora parameter db_writer_processes which controls the number of DBWR processes.The maximum number of DBWR processes is 10, most systems
have 1 DBWR but on large multi CPU machines it is set higher.
If you change DBWR_PROCESSES you should also configure DB_BLOCK_LRU_LATCHES. This controls the number of LRU (least recently used) list latches. It is recommended
each DBWR process have it's own list.
There is a seperate parameter for SLAVES called DBWn_IO_SLAVES.
3) Yes the DBWR or it's SLAVE writes dirty blocks from the buffer cache to disk.
Multiple DBWR are more efficient then SLAVES because the buffer cache is effectively partitioned such that each database writer process maintains a disjoint set of buffers. The allows the buffer cache processing to be parallelized across the available database writer processes.
DBWR IO slaves do not parallelize buffer processing because a single DBWR is used to allocate work to the I/O slaves. IO slaves I suspect will have a higher overhead
then multiple DBWRs since there is IPC communication between the Master DBWR and it's slaves which results in context switches.
Multi DBWR I believe divide the buffer cache into equal sized groups of buffers (working sets).
The working sets are assigned to the DBWRs in a round robin fashion which ensures each receives a share of the different pools such as keep, recycle default etc.
The number of working sets is defined by the number of LRU latches.
I have noticed that a recovery after a shutdown abort is faster with a single DBWR then with multiple DBWRs and I haven't worked out why yet. There is no appreciable
difference when starting the database with multi DBWR after normal or immediate shutdown.
Since I don't work for Oracle I could be completely wrong but hopefully Tom will comment on what I have said.
-------------
Synch I/O = Blocking I/O where a process waits (does not return) till the O/S completes the I/O
Asynch I/O = Non-Blocking I/O where a process does not wait for the O/S to complete the I/O, but rather continues with its processing and the O/s sends back a signal to the process to indicate the I/O completion.
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.
Question:-
Hi Tom,
Now i understood about DBWR SLAVE process.
another question.
Accouring to your reply DBWR process is coordinator and SALVES are the processes which are doing real work.
1)Does that mean there is always DBWR SLAVE process in the database for DBWR process?
2)How many DBWR SLAVE process we can have in database?
I know there is DBWRnnn Parameter in init.ora file.
3)MULTIPLE DBWR SALVE process will distribute dirty buffers write to disk. Am i right?
Answer:-
1) No, if your server supports asynch IO then there would be no point having slaves for the DBWR process since slaves are used to simulate asynch IO
2) There is an init ora parameter db_writer_processes which controls the number of DBWR processes.The maximum number of DBWR processes is 10, most systems
have 1 DBWR but on large multi CPU machines it is set higher.
If you change DBWR_PROCESSES you should also configure DB_BLOCK_LRU_LATCHES. This controls the number of LRU (least recently used) list latches. It is recommended
each DBWR process have it's own list.
There is a seperate parameter for SLAVES called DBWn_IO_SLAVES.
3) Yes the DBWR or it's SLAVE writes dirty blocks from the buffer cache to disk.
Multiple DBWR are more efficient then SLAVES because the buffer cache is effectively partitioned such that each database writer process maintains a disjoint set of buffers. The allows the buffer cache processing to be parallelized across the available database writer processes.
DBWR IO slaves do not parallelize buffer processing because a single DBWR is used to allocate work to the I/O slaves. IO slaves I suspect will have a higher overhead
then multiple DBWRs since there is IPC communication between the Master DBWR and it's slaves which results in context switches.
Multi DBWR I believe divide the buffer cache into equal sized groups of buffers (working sets).
The working sets are assigned to the DBWRs in a round robin fashion which ensures each receives a share of the different pools such as keep, recycle default etc.
The number of working sets is defined by the number of LRU latches.
I have noticed that a recovery after a shutdown abort is faster with a single DBWR then with multiple DBWRs and I haven't worked out why yet. There is no appreciable
difference when starting the database with multi DBWR after normal or immediate shutdown.
Since I don't work for Oracle I could be completely wrong but hopefully Tom will comment on what I have said.
-------------
Synch I/O = Blocking I/O where a process waits (does not return) till the O/S completes the I/O
Asynch I/O = Non-Blocking I/O where a process does not wait for the O/S to complete the I/O, but rather continues with its processing and the O/s sends back a signal to the process to indicate the I/O completion.
No comments:
Post a Comment