Re: Article about supposed "murky" future for Oracle

"Thomas Kyte" <thomas.kyte_at_oracle.com> wrote

> > 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:
>
> a) use read committed and get the wrong answer
> b) use repeatable read/serializable and either
> 1) deadlock with an update transaction, one of you loses
> 2) block the update for a period of time or get blocked and get the
> right
> answer
>
> three rows.

The point I am referring is not what u have described above. What u have mentioned above only proves that a query with an incorrect isolation level will give incorrect result, something which is too obvious to even mention, let alone harp.
What I meant was that, in Informix unless the query involves a huge set of rows, the limitations of locking (R blocking W and W blocking R) does not become an impediment in day to day operation. I don't know at what level SQLServer croaks as I haven't worked with SQLS to that extent. It is only now we are moving towards SS.

I believe that in any properly designed application using Informix, a good designer will incorporate features to minimize such problems. Everyone does it. Not too long ago, Oracle developers and DBAs use to solve "snapshot too old" problem thru application design only. Just search on that problem in this newsgroup.

Admitted Oracle is idiot-proof when it comes to isolation level, fine - more power to oracle. To me it doesn't matter. Why? Bcos everything comes with a price. To give a simple example. Java is much more idiot proof than C/C++, as in array bounds check. We all know where they stand in performance :-)

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

many. but informix does not have problem with this. the problem comes only when the set of rows is huge and that's where a proper design comes into question to minimize or even eliminate this.

> 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")

I prefer fool-proof product to idiot-proof product. If an idiot writes or designs an application, don't blame the product for it.

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

isn't this true for all products. I mean, how many of users actually verify that a report from a complex report involving multi table join, correlated sub queries and partitioning is actually correct. What if Oracle's engine has a rare bug under these conditions. We all take for granted that an enterprise product like Oracle/Informix/SS will not have such bugs, right? If Oracle was so perfect, then the perhaps the need of Metalink (or whatever bug tracking site) will not arise at all.

I repeat don't blame the product for bad coding.

> 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.

true. so is the need for read consistent queries. As a matter of fact, from my experience, few queries require that level of consistency. The reason why I like Informix's approach is that isolation level is provided for every type of scenario. And so does SS and DB2. Use it appropriately. Received on Fri Apr 02 2004 - 21:23:51 CST