Notes in-line.
--
Regards
Jonathan Lewis
http://www.jlcomp.demon.co.uk
http://www.jlcomp.demon.co.uk/faq/ind_faq.html
The Co-operative Oracle Users' FAQ
http://www.jlcomp.demon.co.uk/seminar.html
Optimising Oracle Seminar - schedule updated May 1st
"Joe Weinstein" <joeNOSPAM_at_bea.com> wrote in message
news:40D66B30.8060803_at_bea.com...
>
>
> Jonathan Lewis wrote:
>
> > Apparently, this one will be fixed in Oracle 11
> > (yes, really, that wasn't a joke).
> >
> >
> > Could you clarify what environment or feature
> > you are thinking of when you comment on the
> > "per-table configured memory " and the need
> > to configure more of it.
>
> inittrans
>
I did wonder if that's what you meant.
Have you actually seen this have any effect ?
I know that the manuals have some comment
about 'oracle needs an extra ITL entry for serializable
transactions' but in the past when I have tried to test
the claim, I have never seen any evidence of an extra
ITL enty coming into play. No clues in block-dumps,
and no errors when blocks and their ITLs were full.
> >
> >
> > Regarding:
> >
> >>Any data that is read by a serializable tx can be altered and committed
by
> >
> > another
> >
> >>tx before the first one completes, and if the first tx rereads the
changed
> >>data it will still see the old values, even though the real data has
been
> >>changed.
> >
> > I think that's what most people would expect of serializable.
>
> What most people expect is that when their query reads data, that it is
> the real data. Many people assume that the data they read will not/must
> not change until the end of their transaction. Ultimately oracle
implemented
> select FOR UPDATE to provide this functionality for those that demamded
it.
>
I think there are probably lots of things in the various
versions of the SQL standard where what people expect
and what is actually defined diverge.
The select for update doesn't help in the circumstance you
describe. It doesn't stop another transaction from inserting
and committing a new row that falls into scope of one of
your prior queries.
The only way to serialize to your requirements would be for
the transaction to lock every table it was going to query.
> > I believe the intent of serializability is that the result of running
> > the transactions concurrently should be equivalent to at least
> > one order for running the transaction serially.
>
> true.
>
> > So a transaction
> > should never see changes made by any other transaction or there
> > will never be a serial order that could get the same result.
>
> True, but 'should never see' is not what some people want or expect.
> They want 'should never happen'.
I think that what you're saying is that you want is Oracle to have lots
more cases where the 'cannot serialize' error appears. Which is a
perfectly reasonable requirement - though might require a significant
level of added contention. You can always set 'serializable = true' of
course - that works, but I wouldn't want to do it to a production
system.
> Joe
> >
> >
>
Received on Wed Jun 23 2004 - 03:40:19 CDT
