Re: DBWR slave process

[Snip]
> Hi Howard,
>
> It is now becoming clearer to me about this.
>
> Another question.
>
> so far What i understood about DB_BLOCK_LUR_LATCHES is
>
> It(LATCH) prevent concurrent access to db buffer (protect shared
> data structure)
>

Not really, I think -though your use of the term 'db buffer is potentially ambiguous. Suppose you do an 'update emp set sal=900 where ename='Bob'. That means you must read a block from the EMP table into the buffer cache. You therefore need to find a space in the cache where your buffer/block can live. To find that space, your server process inspects the LRU List, which is a list that contains pointers to every buffer in the cache, and some information about what state each buffer is in (dirty, clean, empty etc). As you walk down the list, your server process is scanning for a clean or empty buffer (because you mustn't be permitted to overwrite a dirty buffer). When it finds one, it marks it as reserved for your use, transfers the pointer to the Most Recently Used end of the LRU list, and then fetches the block from EMP, and places it into the buffer it had already reserved.

(That's a slightly simplified version, because your server process also transfers details of dirty buffers it notices onto a dirty list, or -as it is more formally known in 9i- the 'checkpoint queue').

Anyway, the point is: the LRU list is used by your server process to find a home for the block(s) you want to read or modify. The LRU *latch* merely protects the list from being accessed simultaneously by multiple server processes. Like any latch, it *serializes* access to the list. That's to prevent two people simultaneously deciding that buffer 883 is where they'd like to house their data in the cache.

Now, once the EMP block is resident in memory, it is perfectly possible that whilst you are updating Bob's salary, I can update Sue's telephone number -both records are in the one block, and my server process didn't need to inspect the LRU List in order to find a home for a data block, since you had already caused the data block to be stored in the buffer cache. Simultaneous access to a buffer once it has been housed in the cache is not an issue -provided we don't try and lock the same record, of course. And provided there are enough transaction slots in the block to accommodate all the users that want to access it (and Oracle deals with that issue by creating new transaction slots as needed up to the limit specified by MAXTRANS when you created the table (and the default for MAXTRANS is a healthy 255), or until the block header has no room to accommodate new slots).

So the LRU latch is only involved when reading data from disk into memory. And it's to stop a single buffer being the target home for multiple blocks read by multiple concurrent users. Once a block is in memory, it has no further role to play.

> You are telling server process use LATCHE in order to write block
> from disk to buffer
>

Yup. Sort of. I don't like the use of the word 'write' there, but yes... the latch protects the mechanism that determines where a block from disk can be read into memory. It protects it from simultaneous access by users that might cause two different blocks to be read into the same buffer.

Regards
HJR
> Can you explain this
>
> Thanks,
>
> Gaurang
>
>
> >
> > Regards
> > HJR
> >
> > > Can you explain that
> > > Thanks,
> > >
> > > -Gaurang
Received on Wed Jun 19 2002 - 17:38:53 CDT