Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

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

Re: Article about supposed "murky" future for Oracle

From: Serge Rielau <srielau_at_ca.eye-be-em.com>
Date: Tue, 30 Mar 2004 20:53:57 -0500
Message-ID: <c4d8cg$jdj$1@hanover.torolab.ibm.com>


Daniel Morgan wrote:
> Serge Rielau wrote:
>
>> Daniel Morgan wrote:
>>
>>>
>>>> Instead of SCROLL CURSOR, a TEMP TABLE can also be created for same.
>>>
>>>
>>>
>>>
>>> And what happens during the time the temp table is being loaded?
>>> Same thing that happens in SQL Server. Surely you are not advocating
>>> a full table lock for as long as it takes to load a temp table.
>>>
>> There is no such thing as a free lunch. The versioning comes at a cost
>> too. Pushing a version and managing the rollback segments is not for
>> free.
>
>
> Of course not. But please also acknowledge that even with that overhead
> the following is still possible:
> http://www.tpc.org/tpcc/results/tpcc_perf_results.asp?resulttype=all
Bad example......
Full disclousre report of the clustered Oracle benchmark: Grep for 'serializable"
#define SERIAL_TXT "alter session set isolation_level = serializable" The TPC-C benchmark _requires_ serializable. There is only one query that allows a lower isolation level....
>
>> You can look at it from another angle:
>> If I need to look at a row and it is currently being updated. How do I
>> gamble? If I presume the update will commit then looking at old data
>> will result in a decision being made on stale data. That can be bad.
>
>
> Depends on whether the architecture is such that you have minimized the
> possibility of multiple transactions attempting to update the same row
> at essentially the same time. We all design to maximize our strengths
> and to minimize our weaknesses: Or at least we should.
Bingo
>
>> On the flip side, I can read uncommited data in most RDBMS and go
>> wrong when the transaction on which's success I depend rolls back.
>> I wouldn't want to state one isolation level is better than the other.
>
>
> Unless you were trying to build other infrastructure on top of it such
> as that contained in DBMS_FLASHBACK and other things that Oracle has
> built on top of their concurrency model that so far are not found in any
> other commercial RDBMS.

That is true. You follow the DB2 and Informix newgroup, so you may have seen that while there are a lot of requests coming in through the newsgroup flashback query has never been mentioned, AFAIK. I'm not above recognizing a cool exploitation of a feature when I see one and I hope whoever came up with this likely dirt cheap to implement animal got some reward.

>One should note that a huge investment is taking
> place at Microsoft to duplicate Oracle's model with Yukon. As it is not
> being done for marketing purposes it is reasonable to assume it is so
> that they can recreate some of the same functionality.
Absolutely. Microsoft wants Oracle customers. Note that Yukon also gets exception handlers for T-SQL and "INSERT WITH RETURN"
In the current market the way to grow share is to steal someone elses. As you experienced, that banking customer of yours stuck with Oracle because of the isolation level.
Changing the isolation level of an app is a tough nut to crack once you depend on it.
Again it says nothing about good or bad. Microsoft is taking away excuses not to switch or enable to SQL Server.

Cheers
Serge

-- 
Serge Rielau
DB2 SQL Compiler Development
IBM Toronto Lab
Received on Tue Mar 30 2004 - 19:53:57 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US