Re: DBWR slave process

"Howard J. Rogers" <dba_at_hjrdba.com> wrote in message news:<aer16q$141$1_at_lust.ihug.co.nz>...
> [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

Hi Howard,

 Thanks you very much for explanation.

 It is really helpful understanding Oracle internal.

 Thanks,
 Gaurang Patel Received on Thu Jun 20 2002 - 06:56:11 CDT