Oracle and DB2, Comparison and Compatibility/Introduction

Many of Oracle's most important De Facto PL/SQL standards have now been implemented by IBM. IBM is aiming to compete on performance, usability, high end features and (of course) price. This Wikibook compares and contrasts Oracle (v9i, 10g or 11g) with DB2 (v9.7 for Linux, UNIX, and Windows). Oracle and DB2 are both enterprise-class databases worthy of consideration for the most demanding tasks and this book aims to be factual and impartial in helping the user to compare and contrast them.

- How similar architecture is implemented in each DBMS
- What Oracle compatibility is implemented in DB2

Generally, anyone who has knowledge of one of these databases will see how equivalent core functionality is implemented in the other. Specifically, you will see how DB2 implements Oracle compatibility and how Oracle data and applications written against this data work in DB2. It is important to note that while it is possible to replace an Oracle implementation, it is also possible to develop heterogeneous systems, the so-called ‘Sidecar Strategy’. Examples of this are master slave replication where an Oracle master is replicated to DB2 slaves. As an example, both databases work in shared memory and use data caching for speed, they also have the following similar functionality:

- SQL Syntax
- Built-In Functions and Packages
- Transaction Management
- Packages, Procedures and Triggers
- Indexes
- Data Caching
- Database Maintenance Tools
- Cursor handling
- Replication
- High Availability
- Bulk Loading
- Disaster Recovery

While there is similarity in these areas, the underlying implementation is different. This list is a standard requirement for most commercial DBMSs, but in addition Oracle has its own set of specific features. Anyone considering Oracle compatibility needs to know how features that they have taken advantage of in their existing implementation are handled in their target implementation.

Database migration is relatively straightforward, it happens every day, however the devil is in the details. When specific implementation differences are known, there are known solutions. Problems arise when differences are ‘discovered’ once a migration strategy has been embarked on. An understanding of Oracle compatibility is the first step. The practical implementation of a successful strategy is outside the scope of this document and is something that should involve the experienced.