You can use the DB_BLOCK_MAX_DIRTY_TARGET parameter to place an upper limit on the number of dirty buffers in the database buffer cache. You set this parameter in your initialization file, like this:

db_block_max_dirty_target=200

The example above limits the maximum number of dirty blocks to 200. The default behavior is to have no upper limit at all.
In this context, blocks and buffers are interchangeable. Strictly speaking, a buffer is an area in memory, a block is a piece of data from disk. However, Oracle always sizes the buffers in the buffer cache to match the block size. 200 dirty blocks is equal to 200 dirty buffers.

The number of dirty buffers has a direct impact on the amount of time needed for crash recovery.
That is because when the server crashes, it's the buffered data that you lose. When you restart the instance, those lost changes need to be reconstructed based on information in the redo logs. The more dirty buffers that are lost, the longer recovery will take.

If you are in a time-sensitive environment, you might use the DB_BLOCK_MAX_DIRTY_TARGET parameter to keep the number of dirty blocks, and thus the recovery time, low. Of course this comes at a cost. Performance might suffer somewhat during periods of high activity, because Oracle will occasionally need to wait for the database writer to lower the dirty block count (by writing buffers back to the datafiles).

Click the Quiz link below to test what you have learned about the DBWR and database buffers.
DBwriter Process -Quiz