Re: oracle - mysql comparison

From: Daniel Morgan <damorgan_at_x.washington.edu>
Date: Tue, 20 Jul 2004 22:20:59 -0700
Message-ID: <1090387282.280301@yasure>

Dan wrote:
> "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

No doubt you thought you understood what I intended. I did not once mention serialized or serializable did I?

Daniel Morgan Received on Wed Jul 21 2004 - 00:20:59 CDT