Re: IBM Debunks Oracle's MultiVersion Read Consistency ?

Galen Boyer <galenboyer_at_hotpop.com> wrote in message news:<uznmjdpyd.fsf_at_hotpop.com>...
> On Sun, 20 Apr 2003, rallen_at_NOSPAMOKhgi.com wrote:
>
> > They raise some good points. Is it really as efficient as IBM
> > suggests? What are the advantages that MVRC provide?
>
> The thing that struck me as silly is that they crow about supporting
> ReadUncommitted. Why is this ever a good thing (except when you might
> be blocking and need some way to move one, ala SQLServer and it sounds
> like DB2) If you read any uncommitted data and then after you've read it
> the writer of that data rollsback, then what good was the read?

Well, a minor point, but since you ask, SEQUENCE. You might want to have, say, order numbers in a growing sequence, and not allow the reuse or skipping of order numbers. Of course, you can NOCACHE, but doesn't everyone wind up not using SEQUENCE if they have these requirements? In other words, you want to read an order number which may or may not ever be committed. I agree that MVRC is generally better despite this little weirdness, which to me seems a common situation. Of course, asktom has more in depth examples on such things as autonomous transactions and mutating tables.

>
> I like the fact that Oracle says, whatever is committed is boss, period.

I think all us control freaks like this! :-)

>
> Others?
>
> Even committed transactions are not seen by the reader if the reading
> statement started before the updating statement.
>
> I think Oracle chose the correct way to go. If a row you already read
> gets updated before you are done with your full read, what should your
> answer contain?

I also agree with Oracle in general, but specific business requirements may transcend, particularly in an OLTP. But as we all know, the limitations of other db's has all too often pushed the requirements.

>
> To get around this well known Oracle problem, application developers
> will write their applications and commit as infrequently as
> possible.
>
> Eh? Oracle allows us to commit when the business logic says so, period.

Ermmmm, ORA-155%. Allowance and reality may not intersect. :-)

>
> Oracle's concurrency model is page based.
>
> So. The problem there is they try to say that both transactions can't
> proceed when they are blocking different rows on the same page. All
> this says to me is that Oracle only writes out pages, therefore it will
> have multiple versions of the same pages based on the concurrency
> needs. Lumping it together to try and imply Oracle's transactions block
> readers is just devious.

Not to mention wrong. So you spend some time buffer-scrubbing, big whoop.

jg

--
@home.com is bogus.
So, is Rdb mutating Oracle?