Re: Oracle read consistency *inside*a transaction

From: vc <boston103_at_hotmail.com>
Date: 7 Dec 2004 13:07:49 -0800
Message-ID: <1102453669.425341.9630@f14g2000cwb.googlegroups.com>

Please see inside:

afilonov_at_yahoo.com wrote:
> VC wrote:
> > Please see below:
> >
> > [AF]
> > <afilonov_at_yahoo.com> wrote in message
> > news:1102377411.931512.29600_at_f14g2000cwb.googlegroups.com...
> > > True, but irrelevant for the transaction itself. It doesn't do
> > > consistent
> > > read in this case. It would if other transactions modified the
> block,
> > > but
> > > you said it's not the case. For the session in which transaction
> > > happened, all changes done by this transaction are visible, i.e.
> there
> > > is no need for rollback.
> >
> > [VC]
> > Oracle performs intra-transactional 'mini'-rollbacks aka
'consistent
> reads'
> > in several cases:
> >
> > 1. A failed update/delete/insert statement.
> > 2. savepoint ... rollback to.
> > 3. apparently in the case I described in my original message.
> >
> > It's sort of obvious that no other transaction is involved during
> those
> > 'consistent reads' in order for them to qualify as such.
> >
> > [VC]
> > >
> > >> The rest of your response is skipped as irrelevant.
> > >>
> > >
> >
> > [AF]
> > > Well, why are you asking then?
> > >
> >
> > [VC]
> > I asked hoping to get some insight into how Oracle distinguishes
> between
> > two different changes in the same transaction. My assumption was
> that
> > Oracle performed a mini-rollback in order to get the previous row
> value.
> > What I do not understand is how exactly it's implemented since an
SCN
> can
> > not be used as a 'timestamp' inside the same transaction.
> >
> > Unfortunately, your remarks were, as said, largely irrelevant.
In
> case I
> > missed something of value in your response, I apologize.
> >

>

> OK.

>

> "Timestamps" for uncommitted transaction, as well as any other
> transactional information, is stored in internal transaction tables
> (that's why I referred you to Concepts Manual, it's all described
> there).

1. What specific "internal transaction table" stores information about the "timestamps" for uncommitted transactions ?
2. Assuming there is an internal table with the "timestamps", how exactly does Oracle use the "timestamps" to solve the problem I've described in my original message ?
3. What page of the Concepts, say version 10g, describes the table along with the "timestamps" and steps Oracle takes to avoid creating duplicate rows ?

Thanks. Received on Tue Dec 07 2004 - 15:07:49 CST