Re: INITRANS and MAXTRANS are confusing me?

Are you referring to "Relativity: An Introduction to Space-Time Physics" by Steve Adams? ;)

http://www.amazon.com/exec/obidos/tg/detail/-/0748406212/qid=1047434614/sr=1-14/ref=sr_1_14/103-0398725-6193426?v=glance&s=books

Sometimes I feel like Oracle is this complicated.

Richard

Nuno Souto wrote:
>
> w.gamble_at_pentasafe.com (Wes Gamble) wrote in message news:<37fe2b65.0303111159.ca39183_at_posting.google.com>...
>
> >
> > I just learned about INITRANS and MAXTRANS and what their purpose is.
> > Why does information about the individual transactions have to be
> > stored in data blocks to achieve locking? Why can't you just keep
> > track of the number of transactions which are accessing data in the
> > block in order to manage locking?
>
> Just a few examples:
> What if the block is being shared across two disjoint and completely
> separate nodes, like in Parallel Server (or RAC)? Oracle still maintains
> row-level locking in such a situation, but this sort of thing is needed.
> What if the block has been written by a user a long time ago and been
> flushed, but the transaction is still active? Does one keep a list
> of all blocks changed in a transaction in memory, or does one mark the
> row as having a transaction active, in the block header?
>
> 6 of one, half a dozen of the other, you might say. But one enables
> efficient parallel server, the other doesn't. And the information is
> really very small and of little overhead. I believe with 9ir2 there are
> some minor changes, but haven't had the time to dwell on them.
> Might be worth a read of the relevant "manuels".
> BTW, it has its merits/disadvantages. It's just an algorithm which works.
> So please: let's not engage on a "that one is better" argument.
>
> > Do individual transactions have to
> > be included in the block in order to satisfy Oracle's read consistency
> > model?
>
> Only a marker. Not the "entire" transaction info.
>
> >
> > If it helps to understand my confusion, I am used to the Informix
> > world where lock data was centrally managed, not with the data.
> >
> > Pointers to relevant references are welcomed.
> >
>
> Get a hold of Steve Adam's book. It has a superb description
> on how Oracle achieves its row-level locking. It shows extremely
> well why Oracle doesn't ever need to escalate row locks to block
> or table locks. And it will help understand what all these things
> are for. BUT it can be a "dense" read, so only if you are *really*
> interested in learning this sort of detail.
> HTH
>
> Cheers
> Nuno Souto
> wizofoz2k_at_yahoo.com.au.nospam
Received on Tue Mar 11 2003 - 20:08:21 CST