Re: Oracle read consistency *inside*a transaction

vc wrote:
> 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, decribes the table
> along with the "timestamps" and steps Oracle takes to solve the
problem
> I described earlier ?
>
> Thanks.

Internal workings of transaction management is not published by Oracle. You can't access internal transaction tables, Oracle does not publish algorithms it uses for transaction management. Concepts Manual references transaction tables here:

http://download-west.oracle.com/docs/cd/B14117_01/server.101/b10743/transact.htm#sthref613

and here:

http://download-west.oracle.com/docs/cd/B14117_01/server.101/b10743/process.htm#sthref1576 Received on Tue Dec 07 2004 - 17:35:22 CST