Советую загрузить IBM DB2 Migration Toolkit for Oracle 8

http://www14.software.ibm.com/webapp/download/preconfig.jsp?id=2002-12-22+21%3A27%3A34.466517R&cat=&fam=&s=z&S_TACT=&S_CMP

Эта штука облегчает миграцию с Oracle 8. Сильно ли поможет с Oracle 9, я не знаю, но, по крайней мере, посмотрите доки - на одной из страниц перечислены многие грабли, на которые можете натолкнуться.

Migration toolkit помогает с NULL'ами, которые у Oracle равны пустым строкам, со значениями переменных по умолчанию, с обработкой исключений, с переводом запросов на выборку и т.п.

Но с частью проблем MTK не справляется. Процедурная часть у DB2 даже версии 8 сделана заметно хуже, чем у Oracle, хотя выпутаться из положения обычно можно.

Пакетов в стиле Oracle, а потому и переменных, констант и исключений уровня пакетов у DB2 нет. Требуется ручной перевод. Переменные, по-видимому, можно эмулировать только через временные таблицы.

Конструкции типа
begin
exception
when ....
begin
exception
,,,

не поддерживаются.

Хранимые процедуры из триггеров вызвать нельзя!!! Я в такой ситуации просто впендюрил само тело хранимой процедуры в триггер.

Язык внутри триггеров и SQL-функций намного более убог, чем внутри SQL-процедур, нет обработки исключений. Нередко потому MTK переводит функции в процедуры, но "зато" они не после этого не могут быть вызваны из SELECT-ов.

Вложенные процедуры тоже не поддерживаются.

Настоящую панику у меня вызвали массивы и записи, когда я их впервые увиделв PL/SQL. На самом деле это нестрашно, но вновь требует ручной обработки. Есть такие возможности:

1. массив записей -> временная таблица с соответствующими полями
2. массив записей -> SQL-функция, возвращающая таблицу
3. Использование более выразительного языка, напр. Java (там можно и массив записей соорудить, и даже вложенную процедуру - через анонимный класс).

"Переводчика" также "порадуют" LIKE и функция POSSTR, где по немыслимой мудрости ibm-еров вторым параметром может быть только константа. Ошеломила меня и работа с sequences -

SQL0348N sequence-expression cannot be specified in this context.

Explanation: The statement contains a NEXTVAL expression or PREVVAL expression in an invalid context. NEXTVAL expressions and PREVVAL expressions cannot be specified in the following contexts:

join condition of a full outer join
DEFAULT value for a column in a CREATE TABLE or ALTER TABLE statement
generated column definition in a CREATE TABLE or ALTER TABLE statement
condition of a CHECK constraint
CREATE TRIGGER statement (a NEXTVAL expression may be specified, but a PREVVAL expression cannot be specified)
CREATE VIEW statement, CREATE METHOD statement or CREATE FUNCTION statement
NEXTVAL expressions cannot be specified in the following contexts:

CASE expression
parameter list of an aggregate function
subquery except in the fullselect of an INSERT, UPDATE or VALUES INTO statement
SELECT statement for which the outer SELECT contains a DISTINCT operator
SELECT statement for which the outer SELECT contains a GROUP BY clause
join condition of a join
SELECT statement for which the outer SELECT is combined with another SELECT statement using the UNION, INTERSECT or EXCEPT set operator
nested table expression
parameter list of a table function
WHERE clause of the outer-most SELECT statement, DELETE or UPDATE statement
ORDER BY clause of the outer-most SELECT statement
select-cause of the fullselect of an expression, in the SET clause of an UPDATE statement
IF, WHILE, DO...UNTIL, or CASE statement in an SQL routine
The statement cannot be executed.

User Response: Remove the reference to the sequence expression and resubmit the statement.

sqlcode: -348

sqlstate: 428F9

Производительность "автомигрированных" запросов в DB2 может упасть.

Это связано

1) с тем, что у Oracle пустая строка и NULL одно и то же, и адекватный перевод условия на DB2 его усложняет;
2) если программисты PL/SQL злоупотребляли типом NUMBER без ограничений по размеру и точности, он будет переведен в какой-нибудь неэффективный тип (напр., FLOAT, когда по смыслу достаточно INTEGER).

Вот если разрабатывать новую систему под Oracle либо модифицировать старую, имея в виду миграцию в DB2 и строго придерживаясь определенных правил и ограничений, миграция будет проходить блестяще.

Что еще хотелось бы для облегчения конвертации, так это более "правильную" поддержку Java. Сейчас там хранимые процедуры - это static-методы, а неплохо бы, чтобы каждому коннекту соответствовал экземпляр Java-класса, который возникал бы при первом обращении пользователем (т.е. коннектом) к хранимой процедуре и умирал бы только при разрыве коннекта, и мог иметь свои instance variables. Тогда это стало бы по возможностям ничуть не хуже и не слабее PL/SQL-пакетов.

Я еще (когда увидел переменные уровня пакета) задумался о хранимых процедурах на VA Smalltalk. Если для каждого коннекта грузить свою виртуальную машину... По памяти это может оказаться не так уж ужасно, учитывая, что IC грузятся в Shared Memory, а минуту-другую при коннекте пользователь подождет. Т.е. для небольшой системы с парой десятков пользователей решение могло оказаться приемлемым. Нам надо fenced no threadsafe DLL, которая держится в памяти и удерживает handle от smalltalk'чьей VM (свой для каждого коннекта), при завершении работы освобождает.

Однако в руководствах к 8-ке такие вещи, как

#define SQLZ_DISCONNECT_PROC 1 /* Unload Progam */
#define SQLZ_HOLD_PROC 2 /* Keep program loaded */

даже не упоминаются.

;-(