As far as I can tell, unless you are using advanced datatypes (geospatial, XML, BLOBs) you can run the same SQL DML and PL/SQL on Oracle and DB2.

I’m interested in seeing the TPC numbers with the new index and tempspace compression as well.

As far as growth is concerned, at my current client site, they went from 0 to over 70 DB2 instances in 1 year. They are a DB2/z and Oracle shop, but the price/performance/ease of use on DB2/LUW has swayed management.

We’ll see how many ISV’s take the bait.

Norm

Moreover, what’s with MySql on the iSeries? Is this another foot in the door to replace real DB2 with something else? Job boards are showing up with install MySql on iSeries listings. Huh?

Finally, all the talk about DB2 increasing market share generally (but not every year; I see the Gartner PR version only) skips the “fact” that these increases have been mostly in mainframe installs, which is to say COBOL/VSAM systems turned into COBOL/VSAM systems with a SQL layer.

IBM has been chary about breaking out the revenue sources with good reason: market penetration is not necessarily the same thing as gross market share in revenue.

What’s regrettable is that DB2/LUW is the best locker database out there.

As regards market share, DB2 has enjoyed strong levels of growth in recent years. As you know, IBM does not report revenues at the product level. However, on occasion, IBM will highlight strong performers in its official Earnings Calls. DB2 has actually featured quite a bit on recent calls. For instance, distributed relational database was called out as having 30% growth in both the Q2 and Q4 2008 IBM earnings calls (and Q4 was during a time of economic uncertainty). All things considered, I think its fair to say that these levels of growth for such a huge revenue stream are quite impressive.

As regards the comments about not caring about costs, all I can say is that, over time, we will see if the market cares about costs

We did NOT implement an emulation layer.
When I add e.g. MINUS as a synonym for EXCEPT.
Or when I add associative arrays to DB2. Does that make associate arrays and emulation layer? Not at all.

D we claim 100% support for everything Oracle? Absolutely not. But the ISVs do not require that.
What they do require is an overlap that is:
a) Big enough that an existing app can be modified easily and in place so it works against both Oracle and DB2
b) Allows them to keep the app working against both products without having to constrain fucntion

EnterpriseDB calls this “one source”.

I invite you to sign up for the beta and simply try it out. We know this is hard to swallow, trying it out seems to be the only way to prove it. And we have done this by now hundreds of times.

Serge

Emulation layers have a bad history of biting you when transparency fails, as it almost inevitably in any non-trivial application. Even moving from one version of Oracle to the next is not always fully transparent. In any case the major RDBMS have slightly different ways of doing things, and clinging to the Oracle way will yield sub-par performance on DB2.

The best target is to port to straight PostgreSQL (not the EnterpriseDB fork). If you haven’t bought into the Java-in-database bandwagon from Oracle and are not using the advanced functionality too much, porting is actually not that hard. I did it for my company’s enterprise marketing automation app in about a month.