Re: Article about supposed "murky" future for Oracle

"rkusenet" <rkusenet_at_sympatico.ca> wrote in message news:<c4hb6k$2gi5gl$1_at_ID-75254.news.uni-berlin.de>...
> "Daniel Morgan" <damorgan_at_x.washington.edu> wrote in message news:1080798723.472164_at_yasure...> > One thing I have noticed is that all examples given by Oracle folks> here to prove their point involves taking a rare case like humungous query.

not so. my example used 3 rows - 3 rows.

Your choices in read lock databases:

use read committed and get the wrong answer

use repeatable read/serializable and either

deadlock with an update transaction, one of you loses

block the update for a period of time or get blocked and get the
right
answer

three rows.

> How many of us would be issuing update command involving thousands of> rows during peak production hours to a heavily used table. In case of

how many of us run reports on a system that aggregates data whilst
others are modifying it?

How many of the developers understand they are getting results that
never existed in the database at any point in time (they would not use
RR or Serializable -- they experienced those deadlocks and figured
"bad idea")

Worse yet, how many end users understand that what they are seeing
could be something that never existed.

These are not made up, these are reasons I've worked with people to
port from database A to database B.

> Oracle, since it has to write twice to the block, once for lock and> once for the data update, I am not sure how much performance impact

only if you select for update -- which if you want to not have "lost
updates", you might consider doing in some but not all cases. Like
you say -- it depends.
Received on Fri Apr 02 2004 - 15:03:28 CST