The Itanium Processor and DB2: A secret that shouldn’t be so secret

The dust continues to get stirred up following Oracle's announcement regarding plans for the Itanium processor and HP-UX.  Plenty of authors have been commenting on the subject of late, often concluding that the announcement has negative consequences for HP customers who've been relying on Itanium and HP-UX to run their Oracle-based mission-critical database workloads.

Far from being on the verge of falling, however, the sky is actually very bright for those customers.

That's because, for pretty much the first time in the history of the enterprise relational database market, those customers have a perfectly viable alternative readily available.

That option is IBM DB2.

"Why is DB2 a more viable option for an existing Oracle customer today than in the past?" You might well ask - To answer that question, a bit of history is in order.

E.F. Codd published his seminal paper - "A Relational Model of Data for Large-Scale Data Banks", in 1970.  I was only 9 at the time, so it wasn't on my reading list.  Which proved to be OK, since it took until I had graduated college, some twelve years later, for computers to become powerful enough to handle the compute requirements of processing SQL. Codd worked for IBM at the time his paper was published.  Oracle beat IBM to market with the first SQL database by a small interval, but Oracle and DB2 have been competing with one another basically since DB2's introduction in 1983.

I first installed DB2, on an IBM MVS mainframe, in 1985.  My first Oracle experience was a few years later - ironically enough using OS/2 running on one of the first Compaq SystemPro servers to come off the line.  So I've been watching this competition play out for some time.

SQL wasn't standardized at the beginning, so different implementations had different 'dialects'.  The first ANSI SQL specification came out in 1986.  It has served as the standard definition of what constitutes the SQL language itself ever since, with multiple revisions published over the years. The idea behind a standard definition of the language was to allow for easy portability of applications and database definitions between DBMS's that implemented the standard.  As long as the applications and database definitions adhered to the standard, went the theory, portability would be preserved.

From the very beginning, however, commercial SQL DBMS vendors have provided proprietary 'extensions' to their implementations that tempted programmers and DBA's to sacrifice portability in favor of optimized performance and functionality.

The inevitable result was effective lock-in to a particular DBMS.

Once programmers and DBAs started down the slippery slope of using proprietary in-database stored procedure languages and SQL semantic extensions, migration between DBMS's required source-level changes that could be time-consuming, risky, and costly. That was the case until May 19, 2009, when IBM delivered its Oracle compatibilty extensions with DB2 9.7.

DB2 9.7, for the first time in the history of Database Management System's , fully supported almost the entire collection of proprietary extensions to the SQL standard that Oracle's DBMS provides.  So instead of requiring a complete re-coding and re-testing of applications in order to migrate from Oracle to DB2, customers who wish to migrate from any Oracle database to DB2 merely have to unload their database contents and re-load them into DB2 9.7 - no source code changes or DDL changes required.  It isn't entirely seamless, since an unload/reload is still required, but the process is vastly less daunting than it ever was before, and much less intrusive than an entire platform change.

So if, like tens of thousands of your peers, you're running the core of your enterprise on HP-UX and Itanium and you'd like to keep doing just that for the foreseeable future, rest assured that you have a viable alternative available - one that's fully the equal of Oracle's in terms of suitability for mission-critical workloads.

The analyst community has been taking note of the arrival of this new capability.  George Weiss of Gartner Group, commenting on the subject of Oracle's announcement and its impact on end users, said:

"For Oracle applications written internally, you can move to IBM's DB2 9.7 (and future releases), which contains the Oracle database compatibility feature. This enables Oracle code to run on DB2 unchanged (with about a 97% compatibility as reported by references and Gartner clients)." 

(Source: Q&A: The User Impact of Oracle Ceasing Itanium Development; April 5, 2011; George J. Weiss, Andrew Butler, Donald Feinberg)

They say that imitation is the sincerest form of flattery.  If so, Oracle should be feeling very flattered at the moment.  And customers who are currently running Oracle databases on the Itanium processor and HP-UX should feel reassured.

The next time your Oracle sales rep shows up to talk about plans for migrating your Oracle databases to a SPARC platform, be sure to have a DB2 9.7 coffee cup prominently positioned on your desk.  Have a chat about your success in moving your Oracle databases and applications to DB2 without any need to change platforms.  Be sure to mention that your modern Itanium-based platforms already significantly outperform anything available using SPARC, and you're looking forward to the next decade's worth of continuing improvements from HP and Intel.

Should make for an interesting conversation!