Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

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

Re: oracle - mysql comparison

From: Dan <guntermannxxx_at_verizon.com>
Date: Wed, 21 Jul 2004 03:38:22 GMT
Message-ID: <OylLc.33042$lz2.13858@nwrddc03.gnilink.net>

"Daniel Morgan" <damorgan_at_x.washington.edu> wrote in message news:1090378179.508307_at_yasure...
> VC wrote:
>
> > As I've already mentioned several times, no one disputes the fact that
in
> > certain cases Oracle provides higher concurrency due to MVCC.
>
> Agreed.
>
> > I also said that there are several solutions to the reporting problem in
> > locking databases, such as a replicated or stand-by database.
>
> Many believe this but it is patently false. What do you do about
> transactions that take place while you are replicating the database?
>
> You either lock the table while replicating or the replication is also
> not consistent to a point-in-time. You can not have it both ways.
>
> There is
> > another solution, namely triple mirroring of the OLTP database. SAN
vendor
> > harware can "split off" the third mirrored drive set creating almost
> > instantaneously a clone of the original database (e.g. EMC BCV) at a
given
> > point in time. It's interesting to notice, that the same technique is
> > widely used for Oracle databases as well in order to off-load the main
> > instance. The clone is used both for reporting and backups.
>
> Almost instantly means ALMOST consistent to a point-in-time. But now you
> are talking about data consistency by hardware intervention which is
> just as valid if we were talking about 3x5 cards and a photocopier.
>
> >>Serialize to your hearts content ... you aren't going to do it without
> >>a full table lock ...
> >

> > As I've demonstrated, only a subset of rows involved in the transaction
has
> > to be locked which naturally can be the whole table.
>
> Patently false. You can not lock rows that have not yet been inserted
> while the transaction is taking place. And you have no means of keeping
> them out of your result set except a full table lock.
>

Absolutely not true.

There is a critical difference between the notion of 'serialized' and the term 'serializable'. Perhaps you could look it up? If not, Phil Bernstein, the guy that literally wrote the book on the subject is a real professor at the University of Washington. You might be able to catch a class...

Once you understand the difference in terminology, then perhaps you'll understand why you don't need a full table lock to ensure a serializable schedule even when a concurrent transaction inserts a row (again! in contrast to serialized).

> Daniel Morgan
>

- Dan Received on Tue Jul 20 2004 - 22:38:22 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US