Re: Locks rows

From: Jonathan Lewis <jonathan_at_jlcomp.demon.co.uk>
Date: Tue, 21 Jan 2003 09:38:54 -0000
Message-ID: <b0j4uc$kjb$1$830fa7b3@news.demon.co.uk>

If you select for update, Oracle has to take an ITL entry in the block header, and copy the index of that ITL into the lock byte for the row so that other processes know that the row is locked and can discover who is locking it.

Since this is a change to the block, it has to generate undo and redo. In high concurrency, high throughput, such pessimistic locking should be avoided unless it is really needed, as it could be the difference between scalability or failure.

--
Regards

Jonathan Lewis
http://www.jlcomp.demon.co.uk

Coming soon a new one-day tutorial:
Cost Based Optimisation
(see http://www.jlcomp.demon.co.uk/tutorial.html )

Next Seminar dates:
(see http://www.jlcomp.demon.co.uk/seminar.html )

____England______January 21/23
____USA_(CA, TX)_August


The Co-operative Oracle Users' FAQ
http://www.jlcomp.demon.co.uk/faq/ind_faq.html





Howard J. Rogers wrote in message ...


>

>"Pablo Sanchez" <pablo_at_dev.null> wrote in message

>news:Xns930996FBEE82Cpingottpingottbah_at_216.166.71.233...





>> I'll run it by ya .. Oracle is tracking the 'select for update' in

the


>> data block (INIT TRANS right?).  Is that information actually

flushed


>> to the redo log or are INIT TRANS in-memory buckets set aside to

track


>> the select for updates?

>

>Damn good question. Let me slightly re-phrase it this way: does a

'select


>for update' generate redo?

>

>My best guess is that no it doesn't, since after an instance recovery

you


>would not expect certain rows to be locked. But, how to prove this?

As I


>say, good question, and a test will be forthcoming.... tomorrow.

>

Received on Tue Jan 21 2003 - 03:38:54 CST