Hi!
Well, if the commit is not too frequent, one natural way
of generating primary key would be select max(last_change#) from
v$datafile;
No, you definitely don't want to do that!!!
v$datafile uses x$kccf% tables which cause several physical reads into
controlfiles and x$kcvfh which shows
Dangerous. The UPDATE is not the same as
a SELECT with lock. It has a read component
that won't lock and a write component that
WILL lock at write time. That is not what
you want.
Cheers
Nuno Souto
[EMAIL PROTECTED]
- Original Message -
What about doing it in one step?
Declare
What about doing it in one step?
Declare lCounter int;
Begin
UPDATE counter_table
SET counter := counter+1
WHERE counter_name = 'table name'
RETURNING counter INTO lCounter;
End;
/
Igor Neyman, OCP DBA
[EMAIL PROTECTED]
-Original Message-
Jonathan Gennick
Sent: Thursday, November 06,
The implementations I've seen all did SELECT...FOR UPDATE.
Works.
Doesn't scale.
Cary Millsap
Hotsos Enterprises, Ltd.
http://www.hotsos.com
Upcoming events:
- Performance Diagnosis 101: 11/19 Sydney
- SQL Optimization 101: 12/8-12 Dallas
- Hotsos Symposium 2004: March 7-10 Dallas
- Visit
Well, if the commit is not too frequent, one natural way
of generating primary key would be select max(last_change#) from v$datafile;
These numbers are guaranteed to be unique. As DBWR wakes up every 3 seconds,
the intervals between commit should be at least 3 seconds. As you're very well
aware,
Jonathan Gennick [EMAIL PROTECTED] wrote:
My concurrency issues probably boil down to the locking
business.
Purrcisely.
because they would both issue the SELECT before either one
got around to the UPDATE. I couldn't screw things up
There you go. You are supposed to LOCK the row on
the
Mladen,
If the session doesn't start a transaction, I don't see how this can work.
First, multiple sessions can find the same SCN, no matter what kind of SCN
you're talking about. Secondly, v$datafile.last_change# is set to null unless
the datafile is offline.
If each session has its own
