Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Usenet -> c.d.o.server -> Re: Article about supposed "murky" future for Oracle

Re: Article about supposed "murky" future for Oracle

From: Thomas Kyte <>
Date: 1 Apr 2004 13:42:10 -0800
Message-ID: <>

"rkusenet" <> wrote in message news:<c4h9kp$2hc7c0$>...
> "Thomas Kyte" <> 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 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

Original text of this message