There are three rough areas that I like to divide DB2’s compatibility features into:
1) Syntactic Differences such as (+) vs. LEFT OUTER JOIN, or MINUS vs. EXCEPT
2) Impedance mismatch
E.g. Oracle’s PL/SQL was without a doubt more expressive than DB2’s SQL PL.
Therefore any mapping has to use workarounds and these workarounds are slow. I think of that as “emulation”
Think associative arrays vs declared global temporary tables here.
3) Semantic clashes
The two just can’t talk to each other because the same word means a completely different think
This is teh case with DATE or VARCHAR for Oracle vs. DB2.

DB2 9.7 attacks all three of these fronts.
For a business partner it is very intersting to not have to maintain two or more code bases to offer their customers their choice of DBMS or to negotiate teh best OEM price for themselves.
In the past you either had to choose an abstraction layer (make the problem a Java problem instead of a DBMS problem) with the obvious loss of performance, or you had to just pay th price of dual maintenance.

Business partners are thrilled that they can now support DB2 and Oracle with the same source code without having to restrict them selves to teh equivalent to SQL baby talk.

Cheers
Serge Rielau
SQL Architect, DB2 for LUW

Obviously, third-party software commonly supports multiple DBMS. I don’t even know what point you’re making by pointing that out.

There also are tons of cases in which, when it’s time to rewrite something, the newer version winds up on a different DBMS (MySQL to Oracle, Oracle to an analytic DBMS, legacy DBMS to enterprise standard, whatever).

What I’m saying is that if an application works well enough to not be rewritten, it usually also works well enough not to bother porting from one underlying DBMS to another.

Indeed, I’d have replaced “DBMS” with “platform technologies” in that before the virtualization movement, except in the case of routine upgrades.

The most obvious thing is the use of PL/SQL procedures inside the database system. There are other things, though: suppose you’re depending on Oracle RAC for high availability? Suppose you’re using datatypes that aren’t available on the other DBMS? Suppose you’re using Oracle Dataguard for disaster recovery?

I can see it being relatively easy to port low-end applications, that don’t happen to need Oracle-only features, or which were carefully built to avoid Oracle-only features specifically to aid porting in the future. When you say that it’s been rare to see ports from one RDBMS to another, I presume you are talking mainly about large, high-performance applications. I believe (someone correct me if I’m wrong) that Drupal is capable of running on more than one RDBMS; MySQL is used on most Drupal installations, but not on all (source: a top engineer at Acquia).

people say that it can happen and that their ORM is the tool that will let them do it, but inevitably there are things which don’t go through that ORM, or people punch holes straight through it to take advantage of db-specific features.

if people were serious about being able to be abstract, there would be a least-common-denominator software layer that could pretend to be a unified db, but be run on top of any other db engine as the back-end. of course, this would suck in all sorts of fun ways so nobody does it.

I think that’s almost a distinction w/o a difference, because the problem rarely is performance loss due to translation/interpretation/whatever. Much more often it’s either a missing feature, or else one that just inherently performs slowly due to some architectural difference. An extreme case of the latter would be SQL layered on top of IMS and other hierarchical/CODASYL/whatever systems, which took many years to be respectable.

I have seen this work in a few cases. But I think enterprise projects where there is a need to change databases are fairly rare. It’s not always worth building the necessary infrastructure for database transparency.

The “You Ain’t Gonna Need It” principle is a compelling one and it can be a losing game to try to predict where flexibility will be needed. I think in many situations where one would need the kind of flexibility a transparency layer offers, the overall situation has changed and you are going to be reworking all the layers anyway.

Most of the above could apply to off-the-shelf software or built-in features that offer db transparency. All in all, it seems to me like a solution to a problem that customers might have later, not a problem they have now.

I agree with you that transparency layers do not work well, BUT DB2 does not have an Oracle transparency layer (and neither does EnterpriseDB as far as I know).
What DB2 has is native support for PL/SQL and the Oracle SQL dialect.
When you pitch a PL/SQL and and SQL PL against each other on a DB2 system you will find that they perform equally fast by design.
There is no simulation translation adding latency or emulation hurting performance.
Think of PL/SQL as another “skin” to the DB2 engine not an additional outer layer of clothing.

Also in the cost of an application the DBMS licensing cost is only one part.
Storage savings alone can be significant.

Cheers
Serge