Re: Article about supposed "murky" future for Oracle

"rkusenet" <rkusenet_at_sympatico.ca> wrote in message news:<c4h9kp$2hc7c0$1_at_ID-75254.news.uni-berlin.de>...
> "Thomas Kyte" <thomas.kyte_at_oracle.com> wrote
>
> > so your recent posting in another newsgroup trying to figure out why a
> > simple query in read committed isolation is deadlocking with other
> > statements was due to an improperly designed system?
>
> If you are referring to this post http://tinyurl.com/2rtx7 then this is
> the answer. The customer did not have the index at all. I was preplexed
> with the deadlock because I thought they had the necessary index. After
> all we control the schema by which the database was created at
> the customer site and was running fine for many months.
> Only when I looked at the schema at the customer site, I found the index missing.
> Without the index, SQLServer resorted to table lock leading to deadlock. Once
> the index was created, the problem went away for good, as it was in the
> past. The customer hasn't still given an answer on how the index disappeared.
> Now please don't tell me that Oracle customers don't goof up. Recently I read
> here how Orbitz DBAs deleted some important Oracle configuration files,
> which lead to that infamous crash in Aug 2003.
>
> > or that you must commit really frequently (like row by row) when doing
> > a mass purge to avoid the "long transaction problem" is good design?
> > -- another posting of your recently.
>
> This problem was also solved. What is a good design differs from product
> to product. Oracle must be having its own quirks which other RDBMS may
> not find it bit odd. I don't understand what u are trying to prove?

that in a database that uses read locks -- you are designing around the system constantly.

to add an index to prevent queries from deadlocking -- who'd have thunk it. and what if the query plan decides for whatever reason "index isn't the right thing". And this in read committed - a non-consistent level of isolation in those databases.

thats all. with multi-versioning, we just don't even think about that. Received on Thu Apr 01 2004 - 15:42:10 CST