 | |
#31
 
| |||
| |||
|
Re: Informix beats Oracle -
06-18-2007
, 11:39 PM
|
Dirk Moolman wrote: -----Original Message----- From: informix-list-bounces (AT) iiug (DOT) org [mailto:informix-list-bounces (AT) iiug (DOT) org] On Behalf Of Data Cruncher Sent: 17 June 2007 10:33 PM To: informix-list (AT) iiug (DOT) org Subject: Re: Informix beats Oracle No CTO has ever purchased an RDBMS based on efficient use of CPU. Instead of following the bouncing ball how about asking IBM to make the same changes to Informix they just made to Viper 2 so it will support major business applications? |
we Informix fans would be better off pleading for more ISV exposure than for
ever-greater tech features, and accepting the premise that it's either/or,
you may be right.
#32
| |||
| |||
|
|
Bottomline... benchmarks are very expensive to do. Do you want IBM to pour $$ into benchmarks, or pour $$ into making IDS even better? |
make a choice between marketing and promotion, and technical excellence.
And whilst you've asked the question in a rhetorical style, assuming that
the answer is obviously the latter, there's a balance to be struck
somewhere.
Ralph Waldo Emerson wrote: "Build a better mousetrap and the world will beat
a path to your door". And, of course, he wasn't an enterpreneur, and this
is bollocks. There is no point in having the best product in the world if
no-one knows about it.
#33
| |||
| |||
|
|
Not quite sure what the "bouncing ball" metaphor means but, if you're saying we Informix fans would be better off pleading for more ISV exposure than for ever-greater tech features, and accepting the premise that it's either/or, you may be right. |
WordPerfect folks ... having the better product is irrelevant.
It might interest some to look follow this link I found in the DB2
usenet group this morning.
http://www.gartner.com/it/page.jsp?id=507466
And then the comments of a member of the DB2 team that follow it at
comp.databases.ibm-db2.
--
Daniel A. Morgan
University of Washington
damorgan@x.washington.edu (replace x with u to respond)
#34
| |||
| |||
|
|
Neil Truby wrote: Not quite sure what the "bouncing ball" metaphor means but, if you're saying we Informix fans would be better off pleading for more ISV exposure than for ever-greater tech features, and accepting the premise that it's either/or, you may be right. My point is that if your marketshare becomes small enough ... ask the WordPerfect folks ... having the better product is irrelevant. It might interest some to look follow this link I found in the DB2 usenet group this morning. http://www.gartner.com/it/page.jsp?id=507466 And then the comments of a member of the DB2 team that follow it at comp.databases.ibm-db2. |
#35
| |||
| |||
|
|
Tool wrote: Serge, Got me to want to actually ask you a question. :-) You are aware that this thread may suddenly turn educational now...? ;-) It's my understanding that all other DBMS products are pessimistic-locking, ORACLE is optimistic-locking, Oracle being only one in this category of mainstream DBMS products to have optimistic locking. Does this mean Informix has both pessimistic _and_ optimistic locking? The language here is very confusing and I'm not sure whether there are true definitions. To me optimistic locking is an entirely different beast and Informix had support for it for years and DB2 Viper 2 is introducing it. Optimistic locking (as I understand it) is commonly used in three-tier architectures where the business transaction is much longer than the database transaction. Note that in that space all products are on an equal footing since no vendor can handle isolation across transactions. In fact I think SQL Server is the most aggressive user of optimistic locking for many years with deep support in .NET. Perhaps this is fueled by the default auto-commit behavior (??) Ticket purchase at an airline is a typical example for optimistic locking. You look for a seat going from A->B and you get a set of possibilities back. Having that information stashed away you check with your significant other if she agrees and eventually pick one of the option and hit "book". Two things can happen (actually make that three): 1. All is well you get the seat "confirmed!" 2. You get the seat but the price has changes "Confirmed?" 3. Oops, that seat is gone, try again. Why? There never was a reservation for any of the seats! IDS "natively" supports this sort of logic by supplying change timestamps. The app keeps these around and when update time comes around the change time stamp is compared to what's in the database. This approach is "optimistic" in the sense that it assumes that the stamps will match and you get that seat. Now, within a transaction a similar scheme can (but not must) be used in a multi version concurrency control situation. This would imply that a cursor for UPDATE does not acquire an intend-update lock and the UPDATE itself may fail if the row has changed between the FETCH and the UPDATE. To do this reliably a change time stamp must be available for each row in each table. To the best of my knowledge Oracle records these on a page level however (i.e. an undosegments have a page granularity, not a row granularity). But I'm sure Daniel or Mark T. would be more qualified to comment than I am. In IDS Cheetah READ COMMITTED is a variation on cursor stability and I do not think that it uses optimistic locking either. I'm sure Madison or Jonathan can confirm or dispel my assumption that an intent-update lock will be used since a very fast transaction could otherwise come in between the FETCH and UPDATE and COMMIT with no way of the cursor being notified. I can't say I'm an expert in locking and isolation level. But hey I tried :-) Cheers Serge |
is not optimistic locking. In my opinion it's a very nice feature (although,
surprisingly, I don't think it's one of the customers favorites by now...). But
it's pointed to one of IDS pain points: readers were too many times blocked by
writers. And it caused great anxiety to anyone porting an application from Oracle.
When we have access to the code it's relatively easy to solve these issues, but
in some applications it causes several problems. And the way it was implemented
is (I'm biased...) brilliant. By this I mean the control we can have on how to
use it.
Optimistic concurrency is by definition, and as far as I could search, what you
described, although I think I never saw any reference to support in any RDBMS.
We can implement it in the application code, but on the RDBMS i don't know...
Regards.
--
Fernando Nunes
Portugal
http://informix-technology.blogspot.com
My email works... but I don't check it frequently...
#36
| |||
| |||
|
|
Hi t, I'm not Serge, but the answer to that is yes. As of 11.10, you can have pessimistic-locking, or optimistic locking. Entirely configurable at the instance level. The onconfig parameter is USELASTCOMMITTED |
And we can configure it on instance level, session level, and depending on the
previous isolation level... An Informix DBA dream
Regards.
--
Fernando Nunes
Portugal
http://informix-technology.blogspot.com
My email works... but I don't check it frequently...
#37
| |||
| |||
|
|
Mark Jamison wrote: Hi t, I'm not Serge, but the answer to that is yes. As of 11.10, you can have pessimistic-locking, or optimistic locking. Entirely configurable at the instance level. The onconfig parameter is USELASTCOMMITTED As I wrote answering to Serge, I believe this is not optimistic locking. And we can configure it on instance level, session level, and depending on the previous isolation level... An Informix DBA dream Regards. |
#38
| |||
| |||
|
|
Fernando, thanks too for your response. I read your website article and it was good too. |
Quote:
|
I have been under the impression that this one feature is what Oracle sells to clients, that they have the best non-blocking database engine available. Perhaps this is a bit simplistic, but it is notable that applications and developers now have another choice of what engine to use if indeed this is similar to the Oracle implementation, and was not available in other products. |
In practice, I think this has the same results. Using this, you won't block
when trying to read a row that has a lock (not a shared one, but an
insert/update/delete lock). You will get whatever was there (or wasn't...)
before the operation holding the lock.
However, the underlying implementation is AFAIK (I'm not a developer...)
completely different. Oracle is a versioned RDBMS like Postgres and I believe
some engines used in mySQL. Informix is NOT. The Informix implementation is
simpler (quicker?). If it hits a lock, it fetches the value from logical logs.
SQL server has a similar implementation if I read and understood it's
documentation correctly (since v2005 if I recall correctly).
From my experience as DBA, this is THE feature that developers were wishing
for. From some talks with colleagues and some customers I don't find the degree
of enthusiasm I was expecting...
I'll be very happy if my daily customer migrates to IDS 11 and I can use this
feature. I'm "tired" of explaining the locking issues to developers that were
trained only in Oracle...
It will also make my daily discussions (friendly) with an Oracle DBA much less
boring, since we tend to fall in this specific difference
--
Fernando Nunes
Portugal
http://informix-technology.blogspot.com
My email works... but I don't check it frequently...
#39
| |||
| |||
|
|
Tool wrote: Fernando, thanks too for your response. I read your website article and it was good too. Thanks! I have been under the impression that this one feature is what Oracle sells to clients, that they have the best non-blocking database engine available. Perhaps this is a bit simplistic, but it is notable that applications and developers now have another choice of what engine to use if indeed this is similar to the Oracle implementation, and was not available in other products. I'm not speaking for IBM... standard disclaimer applies, but: In practice, I think this has the same results. Using this, you won't block when trying to read a row that has a lock (not a shared one, but an insert/update/delete lock). You will get whatever was there (or wasn't...) before the operation holding the lock. However, the underlying implementation is AFAIK (I'm not a developer...) completely different. Oracle is a versioned RDBMS like Postgres and I believe some engines used in mySQL. Informix is NOT. The Informix implementation is simpler (quicker?). If it hits a lock, it fetches the value from logical logs. SQL server has a similar implementation if I read and understood it's documentation correctly (since v2005 if I recall correctly). From my experience as DBA, this is THE feature that developers were wishing for. From some talks with colleagues and some customers I don't find the degree of enthusiasm I was expecting... I'll be very happy if my daily customer migrates to IDS 11 and I can use this feature. I'm "tired" of explaining the locking issues to developers that were trained only in Oracle... It will also make my daily discussions (friendly) with an Oracle DBA much less boring, since we tend to fall in this specific difference |
#40
| |||
| |||
|
|
Well I guess I was thinking this was a bit more than "SET ISOLATION TO DIRTY READ". What's the difference between that and this new feature? Now I'm totally bamboozled. Does this mean that in IDS you could not read a locked row at all before this new feature? |
Or is this just a global dirty-read setting?
No
Dirty Read could return a row which is part of a current transaction and
which might be rolled back. Last committed read will only return
committed rows. The row might be in the process of being updated or
deleted, but the transaction will be returned the last committed version
of the row. However, it is always a version of the row which was committed.
M.P.
Quote:
|
-t- Fernando Nunes wrote: Tool wrote: Fernando, thanks too for your response. I read your website article and it was good too. Thanks! I have been under the impression that this one feature is what Oracle sells to clients, that they have the best non-blocking database engine available. Perhaps this is a bit simplistic, but it is notable that applications and developers now have another choice of what engine to use if indeed this is similar to the Oracle implementation, and was not available in other products. I'm not speaking for IBM... standard disclaimer applies, but: In practice, I think this has the same results. Using this, you won't block when trying to read a row that has a lock (not a shared one, but an insert/update/delete lock). You will get whatever was there (or wasn't...) before the operation holding the lock. However, the underlying implementation is AFAIK (I'm not a developer...) completely different. Oracle is a versioned RDBMS like Postgres and I believe some engines used in mySQL. Informix is NOT. The Informix implementation is simpler (quicker?). If it hits a lock, it fetches the value from logical logs. SQL server has a similar implementation if I read and understood it's documentation correctly (since v2005 if I recall correctly). From my experience as DBA, this is THE feature that developers were wishing for. From some talks with colleagues and some customers I don't find the degree of enthusiasm I was expecting... I'll be very happy if my daily customer migrates to IDS 11 and I can use this feature. I'm "tired" of explaining the locking issues to developers that were trained only in Oracle... It will also make my daily discussions (friendly) with an Oracle DBA much less boring, since we tend to fall in this specific difference |
 |
« Previous Thread
|
Next Thread »
| Thread Tools | Search this Thread |
| Display Modes | |
Linear Mode
| |
Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2009, Jelsoft Enterprises Ltd.
Copyright ©2000 - 2009, Jelsoft Enterprises Ltd.