Dirty Buffers

Question

Hi All,
Can anyone please clear my doubt. The data which is uncommitted in the database buffer cache are called dirty buffers or data which are both uncommmitted and committed in the buffer cache are called dirty buffers.
Thanks

Answer 1

Yes We talk about LRU list but Do pointers arrange in
any kind of a list.?
In reality there is no list. LRU list is a well defined mathematical structure known as "linked list". The actual
mechanism is based on the touch count. Are linked lists used in the buffer management?
Of course they are! Is the page replacement process based on the linked list? No, it's
based on something called "touch count".
>
>
It's very simple, actually.
Terms "dirty" and "free"
are buffer management expressions. Buffer is"dirty"
if it doesn't have a valid backup on disk. Bufferis
"free" if it has a valid
backup and is not in use ("pinned"). Sorry didn't get this.
Whats a buffer has to do with backup.
Oracle copies data from/to disk.It never transfers
it.First of all, "backup" is "a copy". If there is a copy of the buffer on the disk, the buffer is not "dirty". The data itself doesn't have to be modified. Locking the table " will "dirty" a buffer but will not modify the data. You can verify that easily:
1 select file_id,block_id,blocks from dba_extents
2* where owner='SCOTT' and segment_name='EMP'
SQL> /
FILE_ID BLOCK_ID BLOCKS
4 25 8
Elapsed: 00:00:00.40
SQL> select dirty from v$bh where file#=4 and block# between 25 and 33;
D
N
N
N
N
N
N
N
7 rows selected.
Elapsed: 00:00:00.05
SQL>
SQL> lock table scott.emp in exclusive mode;
Table(s) Locked.
Elapsed: 00:00:00.01
1* select block#,dirty from v$bh where file#=4 and block# between 25 and 33
SQL> /
BLOCK# D
29 N
32 N
27 N
30 N
28 N
31 N
31 N
31 Y
8 rows selected.
Elapsed: 00:00:00.02
Voila! We've got a modified copy (XCUR) for the block 31. We can clear the modification in a very simple way:
SQL> commit;
Commit complete.
Elapsed: 00:00:00.01
SQL> alter system checkpoint;
System altered.
Elapsed: 00:00:00.11
SQL> select block#,dirty from v$bh where file#=4 and block# between 25 and 33
2 /
BLOCK# D
29 N
32 N
27 N
30 N
28 N
31 N
31 N
31 N
8 rows selected.
Elapsed: 00:00:00.02
SQL>
We released the lock, forced the DBWR process to write out the "changes" and the block
status was cleared. I am woking on 11.1.0.6 test database, with July patch app.lied, and
ass managed tablespaces (ASSM). In this instance, block was modified while no data was
modified. Dirty data is the data of the sordid nature.