Clarification about Database_Buffer_cache workings

Question

Hi All,
Clarification about Database_Buffer_cache workings:(This statement from my course material)
*1.The information read from disk is read a block at a time,not a row at a time,because a database block*
is the smallest addressable storage space on disk.
Before answering, my please check whether my above statement is correct or not,becoz i get this from My course material.
If i am querying ,
select * from emp;
Whether server_process bring the whole block belongs to EMP table right or it just bring the table itself?
Thank you,
Regards,
DB
Edited by: DB on May 30, 2013 3:19 PM
Edited by: DB on May 30, 2013 4:35 PM

Answer 1

Both happens, the LGWR may call the DBWR to write dirty blocks from the buffer cache to disk. Dirty in this context means, that the blocks in the buffer cache have been modified and not yet written to disk, i.e. their content differs from the on disk image. Conversely the DBWR can also call LGWR to write redo records from the redo log buffers (in memory) to the redo log files on disk.
To understand why both is possible, you need to understand the mechanics how Oracle does recovery, in particular REDO and UNDO and how they play together. The excellent book "Oracle Core" from Jonathan Lewis describes this in detail.
I'll try to sketch each of the two cases. I am aware that this is only an overview which leaves out many details. For a complete description please look at the various Oracle books and documentation that cover this topic.
1. LGWR posts DBWR to write blocks to disk
As you probably know, any modifications done by DML (which modify data blocks) are recorded in the redo. In case of recovery this redo can be used to bring the data blocks to the last committed stated before failure by re-applying modifications that are recorded in the redo. Redo is written into redo log files and the redo log files are used in a round robin fashion. As the log files are used in a round robin fashion, old redo data is overwritten at some point in time - thus the corresponding redo records are not longer available in a recovery scenario (they may be in the archived redo logs, which may however not exist if your database runs in NOARCHIVELOG mode and even if your database runs in ARCHIVELOG mode, the archived redo log files may not be accessible to the instance without manual intervention by the DBA).
So before overwriting a redo log file, the Oracle instance must ensure, that the redo records being overwritten will not be used in a potential instance recovery (which the instance is supposed to do automatically, without any action by the DBA, after instance failure, e.g. due to a power outage). The way to ensure this is to have the DBWR write all modifications to disk that are protected by the redo records being overwritten (i.e. all data blocks where the first modification that has not yet been written to disk is older than a certain time) - this is called a "Thread checkpoint".
2. DBWR posts LGWR to write redo records to disk
Oracle uses a write ahead protocol (see http://en.wikipedia.org/wiki/Write-ahead_logging and Write Ahead Logging.... This means, that for any modification the corresponding redo records must been written to disk before the actual modification to the data blocks is written to disk (into the data files). The purpose of this I believe is, to ensure that for any data block modification that makes it to disk, the corresponding UNDO information can be restored (from redo) in case of recovery, in order to reverse uncommitted changes in a recovery scenario.
Before writing a data block to disk, the DBWR must thus make sure, that all redo for modifications affecting this block has already been written to disk by the LGWR. If this is not the case, the DBWR will post the LGWR and only write the data block to the datafile once the redo has been written to the redo log file by LGWR.