Re: INITRANS and MAXTRANS are confusing me?

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 - 18:29:31 CST