Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Usenet -> c.d.o.server -> Re: oracle - mysql comparison

Re: oracle - mysql comparison

From: VC <>
Date: Tue, 20 Jul 2004 18:12:01 GMT
Message-ID: <RfdLc.109372$WX.92600@attbi_s51>

"Alex Filonov" <> wrote in message
> "VC" <> wrote in message
> >
> You mean, this discussion:
> 6dq%3D%26hl%3Den%26lr%3D%26ie%3DUTF-8%26selm%3DKAnf3.108267%2524_m4.1357169%

Yes, that's the one.

> Well, serializability in ANSI92 definition is probably impossible for
> a
> big database with big number of concurrent sessions (and airline
> reservation
> system is a good example).

As I showed in another posting, any locking database handles the reservation example OK, without locking the entire table.

>As for example of overbooking, it's total
> crap.
> Good design for airline reservation system would just have additional
> table for each seat on each flight, and reserve seats (as in real
> life),
> not pieces of an airplane. No need for serializability at all here. No
> problem
> with overbooking.

Your appeal to design aspect is disingenuous but irrelevant. The point is that a certain class of transaction histories similar to the reservation example cannot be handled *correctly* in Oracle's 'SERIALIZABLE', contrary to what you claimed elsewhere (" As for correct concurrency model, I remember one project").

Here's another textbook example for you: ==
There are two linked accounts (id=1 and id=2) in a bank. A transaction might look as follows:

Any commercial locking scheduler will handle the scenario correctly. Oracle won't.

> > What's wrong with those solutions for long running reports, quick
> > not being a problem ? Besides, the situation is not very much
> > from running a long report under Oracle where the results won't be
> > due to the very nature of the beast -- 'read consistency'.
> >
> What do you mean, not actual? They are actual for the point of time.

Sorry, an unfortunate choice of words. I used 'actual' in the sense of 'current'. A 15 minute long Oracle report is 15 minutes out of date whilst a locking scheduler report result is current for the moment the query ended.

> As for real situation, reports didn't run very long time, just
> something
> between 5 and 15 minutes. You wouldn't notice those if running on
> Oracle.

Those are *long* reports. Besides, for the last time I am repeating myself, no one is disputing Oracle concurrecy being better in this situation. .

> And quick queries on read-locking databases is a big problem, if they
> need to lock significant number of rows (especially when locks are
> escalated).

Somehow TPC-C results ( ) do not bear you out.

> > There is no argument that a multiversioning scheduler provides higher
> > concurrency in many cases, after all that's its raison d'etre, but one
> > should not forget about trade-offs/pitfalls and think that alternative,
> > locking, approaches won't work.
> >
> > >
> > > > VC
Received on Tue Jul 20 2004 - 13:12:01 CDT

Original text of this message