Re: Db2, Oracle, SQL Server

"Noons" <wizofoz2k_at_yahoo.com.au> wrote in message news:4206966A.4040300_at_yahoo.com.au...
>
> > In Oracle, Read consistency is a mantra. When transaction A updates a
> > row, noone will ever be allowed to see the new values before
> > committed. Period. You either see the old values before Transaction A
> > or nothing.
>
> as it should be. It's been a mantra of good database design - not just
> Oracle - since the days of old Codasyl and network model databases:
> if it ain't committed it ain't there, period.
>

Good database design for OLTP would suggest that if someone is in the middle of an update to a row, you should not see the old or current data until the work in progress work is committed or rolled back.

> > In DB2, it's the opposite, so to speak.
>
> Ye Gawds! That was such a surprise.
>
> > You can either choose to see the new uncommitted values by specifying
> > "uncommitted read" in your quer or nothing at all. But there is no way
> > to see the old values.
>
> You see: this is where all this rigmarole of TPC benchmarks
> and other similar crap becomes totally useless. Something as
> fundamental as this is not even addressed or tested or stretched
> in all of those. They all work around the issue. It says lots for
> the kind of people who come up with the specs for these "standard
> benchmarks".
>

The TPC-C benchmark has very strict and specific rules about data concurency and data consistancy. In an OLTP applciation (TPC-C) you don't want anyone reading data that is in the process of being updated by another application thread. You don't want anyone selling an item that is already promised to someone else (indicated by that someone else having a lock on that row while in the process of updating it). The TPC-C rules on this subject are very well thought out.

For the TPC-H benchmark (Data Warehouse), this is a complete non-issue becasue there only selects.

http://www.tpc.org Received on Sun Feb 06 2005 - 16:40:25 CST